users October 2017

users@lists.genode.org

18 participants
23 discussions

Sd_card Driver Sabrelite : Command Timed out
by George Joseph 28 Oct '17

28 Oct '17

I was trying genode 17.05 on sabrelite board. The sd_card bench application gave these errors. [init -> sd_card_bench] Error: command timed out [init -> sd_card_bench] Error: prefix command timed out [init -> sd_card_bench] Error: Sd_send_op_cond command failed [init -> sd_card_bench] Error: Uncaught exception of type 'Sd_card::Host_controller::Detection_failed' [init -> sd_card_bench] Warning: abort called - thread: ep [init] child "sd_card_bench" exited with exit value 1 But go_idle command is the successfully send. The card is working fine from the uboot mmc commands. I cant find any reason. I have checked the registers in the usdhc controller the register values seems fine. What can be the possible reasons?.

2 2

compile port into noux-pkg and native library
by Nobody III 27 Oct '17

27 Oct '17

I have successfully compiled liblzma as a native Genode library, and I've compiled xz-utils as a noux package, but given that the two are in the same source tree, how do I compile xz-utils for noux using the native liblzma library? I'm not seeing any configure options that would allow building xz-utils for a precompiled liblzma rather than building the two together. Is there a good way to do this? I recognize that what I'm trying to do isn't really necessary, but it still would be nice to get this to work. Aside from reducing compile time, if I understand correctly, this should allow for multithreading, as that's all handled in the liblzma library, rather than in the command-line xz utility itself. Am I correct here?

1 0

Qt5: Signals and QApplications inside Threads
by Boris Mulder 26 Oct '17

26 Oct '17

Dear Genode folks, I have built an application with Qt5. I want it to also be able to read ROM modules from a report_rom server and to be able to handle updates to that ROM using signals. When I run QApplication::exec() however, it does not return and the entrypoint cannot listen to signals, causing them to be ignored. So I created another QThread and run my QApplication in there. Now I get the following error: WARNING: QApplication was not created in the main() thread. And the application does not do anything and does not react to events. What can I do to be able to run both the qt event loop and the genode event loop? regards, Boris -- Met vriendelijke groet / kind regards, Boris Mulder Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)

2 3

Base-hw kernel GIC issue with a Cortex--A7 processor.
by Bob Stewart 19 Oct '17

19 Oct '17

Hi, I'm bringing up the 17.08 base-hw kernel/core on an NXP IMX6ULL SoC, which uses a Cortex A7 single core processor, and am having issues creating the singleton instance of the GIC after kernel initialization. In short the attempt to create the singleton causing the processor to die! The PIC code is all existing ARM code, I supply the addresses of the GIC-400 interrupt distributor and its cpu interface from the NXP documentation. Using the u-boot command line I see that the GIC register addresses in memory agree with the documentation. The physical addresses are 0x00A01000 and 0x00A02000 which are translated to virtual addresses 0xF0001000 and 0xF002000. The core initialization code in ../base-hw/src/core/kernel/init.cc first creates a cpu pool object then creates a cpu object in the pool passing to it the address of the unmanaged singleton object for the PIC.The cpu initialization code would use this object to unmask an interrupt for a timer, if it ever got that far! It appears to die in the execution of the placement new operator in ../base/src/include/base/internal/unmanaged_singleton.h: template <typename T, typename... ARGS> static void call(char * const dst, ARGS &&... args) { new (dst) T(args...); } (Where T would be Kernel::Pic) The Pic constructor is never called when the new executes. I was testing using the log run script which does not need a timer to execute the test, so I removed the creation of the Pic object and its use in the cpu object initialization. The test ran successfully to completion and provided the memory allocator outputs and the print test output: Bytes transferred = 686398 (a793e hex) ## Booting kernel from Legacy Image at 82000000 ... Image Name: Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 686334 Bytes = 670.2 KiB Load Address: 81000000 Entry Point: 81000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... kernel initialized In cpu timer irq is 87 :virt_alloc: Allocator 0x910cc2bc dump: Block: [00001000,80000000) size=2097148K avail=2097148K max_avail=2097148K Block: [80105000,81000000) size=15340K avail=15340K max_avail=2097148K Block: [811a0000,91000000) size=260480K avail=260480K max_avail=2097148K Block: [912a2000,912a3000) size=4K avail=0 max_avail=0 Block: [912a3000,d0000000) size=1029492K avail=1029492K max_avail=1029492K Block: [e0000000,e0001000) size=4K avail=0 max_avail=0 Block: [e0001000,f0000000) size=262140K avail=262140K max_avail=1029492K Block: [f0002000,f0003000) size=4K avail=0 max_avail=0 Block: [f0007000,f0008000) size=4K avail=0 max_avail=262028K Block: [f000c000,fffef000) size=262028K avail=262028K max_avail=262028K => mem_size=4020883456 (3834 MB) / mem_avail=4020867072 (3834 MB) :phys_alloc: Allocator 0x910cb250 dump: Block: [80106000,80107000) size=4K avail=0 max_avail=0 Block: [80107000,80108000) size=4K avail=0 max_avail=32K Block: [80108000,80110000) size=32K avail=32K max_avail=32K Block: [8025b000,8025c000) size=4K avail=0 max_avail=506240K Block: [8025c000,8025d000) size=4K avail=0 max_avail=0 Block: [8025d000,81000000) size=13964K avail=13964K max_avail=506240K Block: [811a0000,a0000000) size=506240K avail=506240K max_avail=506240K => mem_size=532738048 (508 MB) / mem_avail=532721664 (508 MB) :io_mem_alloc: Allocator 0x910cd334 dump: Block: [00000000,80106000) size=2098200K avail=2098200K max_avail=2098200K Block: [80110000,8025b000) size=1324K avail=1324K max_avail=2098200K Block: [81000000,811a0000) size=1664K avail=1664K max_avail=1610612735 Block: [a0000000,ffffffff) size=1610612735 avail=1610612735 max_avail=161061273 5 => mem_size=3762229247 (3587 MB) / mem_avail=3762229247 (3587 MB) :io_port_alloc: Allocator 0x910ce3a0 dump: => mem_size=0 (0 MB) / mem_avail=0 (0 MB) :irq_alloc: Allocator 0x910cf40c dump: Block: [00000000,00000001) size=1 avail=1 max_avail=1 Block: [00000002,00000057) size=85 avail=85 max_avail=936 Block: [00000058,00000400) size=936 avail=936 max_avail=936 => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB) :rom_fs: ROM modules: ROM: [810e2000,810e2156) config ROM: [810e3000,811133c4) init ROM: [81114000,8119b470) ld.lib.so<http://ld.lib.so> ROM: [8119c000,8119f58c) test-log Genode 17.08 <local changes> 507 MiB RAM and 64535 caps assigned to init [init -> test-log] hex range: [0e00,1680) [init -> test-log] empty hex range: [0abc0000,0abc0000) (empty!) [init -> test-log] hex range to limit: [f8,ff] [init -> test-log] invalid hex range: [f8,08) (overflow!) [init -> test-log] negative hex char: 0xfe [init -> test-log] positive hex char: 0x02 [init -> test-log] multiarg string: "parent -> child.7" [init -> test-log] String(Hex(3)): 0x3 [init -> test-log] Test done. I guess I don't understand the allocator outputs as I would have expected the two pages at address 0xA01000 for the GIC-400 to show up in the io_mem_alloc allocator output with zero availability. I hope that has something to do with this problem as don't see a good way of debugging the placement new operation. As an aside, I noticed a lurking bug in the Pic cpu interface register definitions in ...base-hw/src/lib/hw/arm/pic.h: The struct Irq_id inside both struct Iar and struct Eoir are sized as struct Irq_id : Bitfield<0:10> { }; . They both should be { struct Irq_id : Bitfield<0:9> { }; struct Cpu_id : Bitfield<10:12> { }; }; Thanks in advance for any help. Bob Stewart Get Outlook for Android<https://aka.ms/ghei36>

3 8

thread cancel_blocking usage, kernels
by Steven Harp 18 Oct '17

18 Oct '17

The Genode book suggests that an RPC caller can protect itself from blocking in a stalled server by creating a watchdog thread to monitor the process of the call, and cancel it if it takes too long. Is there a robust/canonical example of using cancel_blocking in this way? My experiment with this (Genode 17.08, x86_32) seems to work as expected--but, only with the OKL4 kernel!? With nova, hw, and seL4, the cancel_blocking() method executes but seemingly to no effect: the thread continues to wait on the (contrived) very slow RPC call, which eventually completes. Suggestions? // Steve Harp

2 3

additional base linux core
by Johannes Kliemann 18 Oct '17

18 Oct '17

Hi, I want to create a base-linux core that is able to run on a bare linux kernel to use it such as any other microkernel in Genode. Since base-linux already implements some of the required interfaces I'd like to reuse the already existing components as much as possible. Yet I'm not sure what the way to go is: - Copying the contents of base-linux into a new repository would probably make an easy start but lead to code duplication (and I would probably have to port all updates of base-linux). - I already tried to reinclude the contents of base-linux (my repository currently only consists of Makefile fragments). Even though it builds it's often quite hacky to relocate some of the $(REP_DIR) entries to base-linux without breaking $(REP_DIR) itself. Also external libs sometimes don't seem to find the correct headers. - Directly extending base-linux would avoid these problems but this would require either a switch to choose between the original and the new functionality of this core or even better a "hybrid" core that is able to run in both environments. Also this change would probably need to get upstream (I don't know if this kind of change would be a problem generally). What is the recommended way to do this? Regards, Johannes

2 1

vbox4_ubuntu_16_04_64.run recipe
by Chris Rothrock 16 Oct '17

16 Oct '17

I am trying to get a working virtual machine in Genode with the recipe vbox4_ubuntu_16_04_64.run but I am unsure where the virtual disk image file (.vdi) should reside so that the VirtualBox module loads it properly. I am able to get a good compile and it seems to boot to Genode just fine and I even see the CPU status meter but I don't get the virtual machine booting up. I created a VirtualBox VM with this same name with a VDI and completed a full install of Ubuntu 16.04 64 bit and am trying to use this image file. As far as I can tell, the VDI meets all the parameters and works fine with using both Linux and Windows VirtualBox to run. Any instructions on getting this (and possibly Windows VMs to work) would be greatly appreciated. Thanks in advance, Chris Rothrock

3 2

Provide session from libc code
by Johannes Kliemann 16 Oct '17

16 Oct '17

Hi, I tried to create a provide an input session from a libc (in this case an Qt application). If I just run it from the Main struct it will correctly announce the session but since Main never returns, no client will be able to use it. I tried to circumvent this by putting the application into a separate thread but this led to the following error: > Error: void Libc::Kernel::run(Libc::Application_code&) called from non-kernel context Running this Qt application without wrapping it into with_libc makes it segfault on initialization. What is the correct way to do this? My current main is at [1]. Regards, Johannes [1]: https://github.com/jklmnn/componolit/blob/478490f05f23ce4c64b4a386377a1212c…

2 1

default-route config
by Johannes Kliemann 13 Oct '17

13 Oct '17

Hi, I tried to completely remove the default-route with any-service/any-child from my runfile and only explicitly allow services to components. I have created a minimal example with only the timer driver [1] but I wasn't able to explicitly grant service access to the timer driver. When I prepend <any-service> with an explicit > <service name="PD">> <child name="timer"/> > </service> the timer driver fails with a denied PD environment session. What is the correct approach to do this? Regards, Johannes

2 2

[FWD] FOSDEM 2018 - Microkernels developer room - CfP
by Josef Söntgen 09 Oct '17

09 Oct '17

----- Forwarded message from Jakub Jermář <jakub@...85...> ----- FOSDEM 2018 - Microkernels developer room CALL FOR PARTICIPATION The developers of several free and open-source microkernel-based operating systems will meet at FOSDEM 2018 [1] in Brussels, Belgium and will share a developer room on Saturday of February 3, 2018 [2]. The devroom is currently looking for content in the form of talks and activities related to the area of microkernel-based operating systems. Possible topics include, but are not limited to: * Introduction of a specific OS or framework * Design of subsystems and the general architecture of an OS * Enabling support for hardware (architectures, device drivers) * Used languages and tools * Maintenance and testing * Security and robustness * Trends and challenges * Use cases, experiences, lessons learned and demos Please use the Pentabarf [3] system to submit your proposals and file it under the track “Microkernels devroom”. You do not need to create a new account if you already have one. When in doubt, please use the devroom mailing list [4]. If you do not want to give a talk yourself, you may still send suggestions for what else you would like to see, or do in the devroom. Please send your suggestions to the mailing list. The deadline for your proposal is on December 8. Make sure to include the following in your proposal: * Title of your talk (will be printed in the FOSDEM booklet) * Your full name (will be printed in the FOSDEM booklet) * A short abstract (one or two paragraphs) * Duration of your talk (please, at least 25 and no longer than 45 min) The official devroom schedule (along with the accepted talks) will be announced on December the 15th on the devroom's mailing list and the speakers will be notified via e-mail. The schedule will also be published on the FOSDEM website. About FOSDEM FOSDEM is a two-day event organised by volunteers to promote the widespread use of free and open source software. Taking place in the beautiful city of Brussels (Belgium), FOSDEM is widely recognised as the best such conference in Europe. FOSDEM covers a wide spectrum of free and open source software projects, and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) with network/internet connectivity and projectors where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present latest directions, lightning talks, news and discussions. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. Every year, FOSDEM hosts more than 5000 developers at the ULB Solbosch campus. Participation and attendance is totally free, though the organisers gratefully accept donations and sponsorship. No registration necessary. About the devroom Since the first Microkernel devroom in 2012 this devroom has been part of each following FOSDEM. By now it has become a somewhat institutionalized tradition for the microkernel community to meet there; to this date over a dozen projects have participated in one way or another. Each of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the Microkernel devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. Social events It also has become a habit that the microkernel projects dine together somewhere in downtown Brussels after the devroom closes. The year 2018 will not be any different, so there is going to be a microkernel family dinner on Saturday night. The exact location and time will be specified later. Consult the FOSDEM web and other projects for additional social events such as the famous FOSDEM-organized Friday Beer Event and the FOSDEM-arranged free sightseeing tours for spouses. Important dates recap * 08.12.2017: Deadline for submissions * 15.12.2017: Schedule published and speakers notified of acceptance * 03.02.2018: The devroom takes places Links [1] http://fosdem.org/ [2] https://fosdem.org/2018/practical/transportation/ [3] https://penta.fosdem.org/submission/FOSDEM18 [4] https://lists.fosdem.org/listinfo/microkernel-devroom See you all at FOSDEM! _______________________________________________ microkernel-devroom mailing list microkernel-devroom@...86... https://lists.fosdem.org/listinfo/microkernel-devroom ----- End forwarded message -----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users October 2017