Hi, Alex
Yes, default_log.cc is listed in core-sel4.mk file. However, I've recently noticed that not all of the components listed in SRC_CC actually get to compile (including default_log.cc), which results in incomplete core-sel4 library. After taking a closer look, it turned out that io_port_session_support.cc and io_port_session_component.cc are the source of this problem. I had them out commented for my sabre_lite build as you've previously suggested. Removing them from core-sel4.mk for seL4_x86_32 build gave me the same results as for sabre_lite: incomplete core-seL4 library
Library core-sel4 COMPILE cpu_session_component.o COMPILE cpu_session_support.o COMPILE cpu_thread_component.o COMPILE io_mem_session_component.o COMPILE io_mem_session_support.o COMPILE main.o COMPILE pd_assign_pci.o COMPILE pd_session_component.o COMPILE pd_upgrade_ram_quota.o COMPILE ram_session_component.o COMPILE ram_session_support.o COMPILE rom_session_component.o COMPILE rpc_cap_factory.o COMPILE version.o MERGE core-sel4.lib.a
and the same "undefined reference" errors at the end. Now that I know where the problem is: what can I do from here?
Please check that you compile and link the file to core. Check that the symbol actually shows up as symbol in core.o, e.g. by examining the output of "readelf -s build/<arch>/core/sel4/core.o".
Not sure what you mean by the symbol. "readelf -s core.o | grep -i log" gave me the following output: 10311: 00000000 0 FILE LOCAL DEFAULT ABS log.cc
Comparing to successful build for x86_32: 8733: 00000000 0 FILE LOCAL DEFAULT ABS log.cc 9028: 00000000 0 FILE LOCAL DEFAULT ABS core_log.cc 9175: 00000000 0 FILE LOCAL DEFAULT ABS default_log.cc
Thanks
Hi,
On 21.06.2017 21:41, lavrovyn@...145... wrote:
Yes, default_log.cc is listed in core-sel4.mk file. However, I've recently noticed that not all of the components listed in SRC_CC actually get to compile (including default_log.cc), which results in incomplete core-sel4 library. After taking a closer look, it turned out that io_port_session_support.cc and io_port_session_component.cc are the source of this problem. I had them out commented for my sabre_lite build as you've previously suggested. Removing them from core-sel4.mk for seL4_x86_32 build gave me the same results as for sabre_lite: incomplete core-seL4 library
now I get the same error. You can't just uncomment it with '#', because all followed files will _not_ be added anymore. Just remove the lines completely. The issue here is that all files are concatenated by the '' at the end of each line. If you uncomment one in between, all lines (and therefore files) below will not be compiled anymore.
Library core-sel4 COMPILE cpu_session_component.o COMPILE cpu_session_support.o COMPILE cpu_thread_component.o COMPILE io_mem_session_component.o COMPILE io_mem_session_support.o COMPILE main.o COMPILE pd_assign_pci.o COMPILE pd_session_component.o COMPILE pd_upgrade_ram_quota.o COMPILE ram_session_component.o COMPILE ram_session_support.o COMPILE rom_session_component.o COMPILE rpc_cap_factory.o COMPILE version.o MERGE core-sel4.lib.a
and the same "undefined reference" errors at the end. Now that I know where the problem is: what can I do from here?
Please check that you compile and link the file to core. Check that the symbol actually shows up as symbol in core.o, e.g. by examining the output of "readelf -s build/<arch>/core/sel4/core.o".
In case it is successful, on x86 I get:
readelf -s build/x86_32/core/sel4/core-sel4.o | grep log | grep Log
7729: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZN6Genode3Log3logEv
Here you see the symbol part of core.o.
Hi, Alex
Thanks a lot for the hint. Got it all fixed. Now I can get image.elf to compile and readelf -s returns: 22790: 00000000 112 FUNC GLOBAL DEFAULT 3735 _ZN6Genode3Log3logEv
Ran into "undefined reference" again with io_port* files but was able to fix by changing vpath for platform_services.cc from: $(GEN_CORE_DIR)/spec/x86 to $(GEN_CORE_DIR).
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
Is it possible that I might be missing some i.MX6 platform specific files in my build? Like those that can be found in /base-hw/src/core/spec and /base-hw/src/core/include/spec
On Thu, Jun 22, 2017 at 9:14 AM, Alexander Boettcher < alexander.boettcher@...1...> wrote:
Hi,
On 21.06.2017 21:41, lavrovyn@...145... wrote:
Yes, default_log.cc is listed in core-sel4.mk file. However, I've
recently
noticed that not all of the components listed in SRC_CC actually get to compile (including default_log.cc), which results in incomplete core-sel4 library. After taking a closer look, it turned out that io_port_session_support.cc and io_port_session_component.cc are the
source
of this problem. I had them out commented for my sabre_lite build as you've previously suggested. Removing them from core-sel4.mk for seL4_x86_32 build gave me the same results as for sabre_lite: incomplete core-seL4 library
now I get the same error. You can't just uncomment it with '#', because all followed files will _not_ be added anymore. Just remove the lines completely. The issue here is that all files are concatenated by the '' at the end of each line. If you uncomment one in between, all lines (and therefore files) below will not be compiled anymore.
Library core-sel4 COMPILE cpu_session_component.o COMPILE cpu_session_support.o COMPILE cpu_thread_component.o COMPILE io_mem_session_component.o COMPILE io_mem_session_support.o COMPILE main.o COMPILE pd_assign_pci.o COMPILE pd_session_component.o COMPILE pd_upgrade_ram_quota.o COMPILE ram_session_component.o COMPILE ram_session_support.o COMPILE rom_session_component.o COMPILE rpc_cap_factory.o COMPILE version.o MERGE core-sel4.lib.a
and the same "undefined reference" errors at the end. Now that I know where the problem is: what can I do from here?
Please check that you compile and link the file to core. Check that the symbol actually shows up as symbol in core.o, e.g. by examining the output of "readelf -s build/<arch>/core/sel4/core.o".
In case it is successful, on x86 I get:
readelf -s build/x86_32/core/sel4/core-sel4.o | grep log | grep Log
7729: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZN6Genode3Log3logEv
Here you see the symbol part of core.o.
-- Alexander Boettcher Genode Labs
http://www.genode-labs.com - http://www.genode.org
Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Yevgeny,
On 23.06.2017 05:31, Yevgeny Lavrov wrote:
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
I wonder, how exactly are you running the image on the board? In particular, how is the image created?
I am asking because the boot procedure on ARM is different from x86/multiboot. On x86, the kernel and the Genode ELF image are loaded by the boot loader (e.g., Grub) as separate boot modules. The kernel is started by the boot loader. At the startup of the kernel, the kernel finds the physical memory location of the Genode ELF image in the multiboot information and ELF-loads core by using this information. In contrast, on ARM, everything (seL4 kernel + Genode) must be contained in a single image. The details of how such an image is assembled is kernel-specific. Consequently, there must exist a seL4-specific tool for creating it. Can you please elaborate, which tool you use and which particular steps you take?
Another potential pitfall would be the use of the wrong UART or the use of a kernel configuration without debug support. The latter is needed for the kernel-provided UART driver. Have you tried to run a non-Genode-based seL4 image on the hardware? I would not try to run Genode on the device before running a simple seL4 example first.
Cheers Norman
On Fri, Jun 23, 2017 at 12:00:42PM +0200, Norman Feske wrote:
Hello Yevgeny,
On 23.06.2017 05:31, Yevgeny Lavrov wrote:
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
I wonder, how exactly are you running the image on the board? In particular, how is the image created?
I am asking because the boot procedure on ARM is different from x86/multiboot. On x86, the kernel and the Genode ELF image are loaded by the boot loader (e.g., Grub) as separate boot modules. The kernel is started by the boot loader. At the startup of the kernel, the kernel finds the physical memory location of the Genode ELF image in the multiboot information and ELF-loads core by using this information. In contrast, on ARM, everything (seL4 kernel + Genode) must be contained in a single image. The details of how such an image is assembled is kernel-specific. Consequently, there must exist a seL4-specific tool for creating it. Can you please elaborate, which tool you use and which particular steps you take?
Another potential pitfall would be the use of the wrong UART or the use of a kernel configuration without debug support. The latter is needed for the kernel-provided UART driver. Have you tried to run a non-Genode-based seL4 image on the hardware? I would not try to run Genode on the device before running a simple seL4 example first.
Hi,
I'm using a fork of seL4's elfloader-tool that I've hacked together to create an image that acutally boots (at least it gets into the genode userland image where it is failing). To be clear: I need to add calls to kernel_debugger_outstring as I get a data fault before the logging infrastructure works (I guess due to exception handling not being initialized before the fail occurs).
I'm using an am335x based board so I can't test if this works for other hardware, but if anyone is interested you can find my elfloader fork at https://github.com/N8Fear/elfloader-tool
The bootable image is then created by running the script from the elfloader dir TOOLPREFIX=arm-none-eabi- PLAT=am335x ./gen_boot_image.sh <path to genode>/build/wega_am335x/var/run/log/sel4 <path to genode>/build/wega_am335x/var/run/log/image.elf /tmp/out.elf
PLAT and TOOLPREFIX need to be changed accordingly and when building the prelinked elfloader binary PLAT and ARMV needs to be adjusted as well (take a look at the Makefile).
I guess for your board you should try PLAT=imx6 for building and for creating the image.
I guess I should do some cleanup if anyone else wants to use the stuff...
With kind regards, Hinnerk
Hi, Norman
I wonder, how exactly are you running the image on the board?
I normally just copy created image over to SD card and then run it via bootelf command.
In contrast, on ARM, everything (seL4 kernel + Genode) must be contained
in a single image. The details of how such an image is assembled is kernel-specific This might explain why the image didn't give me any output. I ended up with two images: image.elf & sel4.elf instead of just image.elf in my <sabre_lite>/var/run/log/
Consequently, there must exist a seL4-specific tool for creating it. Can
you please elaborate, which tool you use and which particular steps you take? Didn't think of any tool for combining image.elf & sel4.elf together until I got your reply. Only thought of modifying /tool/run/boot_dir/sel4 file. I'll give Hinnerks elfloader-tool a try today.
Have you tried to run a non-Genode-based seL4 image on the hardware? I
would not try to run
Genode on the device before running a simple seL4 example first.
Yes, this was my starting point. All seL4 apps ran w/o any problems.
Thanks
On Fri, Jun 23, 2017 at 7:20 PM, Hinnerk van Bruinehsen < h.v.bruinehsen@...491...> wrote:
On Fri, Jun 23, 2017 at 12:00:42PM +0200, Norman Feske wrote:
Hello Yevgeny,
On 23.06.2017 05:31, Yevgeny Lavrov wrote:
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
I wonder, how exactly are you running the image on the board? In particular, how is the image created?
I am asking because the boot procedure on ARM is different from x86/multiboot. On x86, the kernel and the Genode ELF image are loaded by the boot loader (e.g., Grub) as separate boot modules. The kernel is started by the boot loader. At the startup of the kernel, the kernel finds the physical memory location of the Genode ELF image in the multiboot information and ELF-loads core by using this information. In contrast, on ARM, everything (seL4 kernel + Genode) must be contained in a single image. The details of how such an image is assembled is kernel-specific. Consequently, there must exist a seL4-specific tool for creating it. Can you please elaborate, which tool you use and which particular steps you take?
Another potential pitfall would be the use of the wrong UART or the use of a kernel configuration without debug support. The latter is needed for the kernel-provided UART driver. Have you tried to run a non-Genode-based seL4 image on the hardware? I would not try to run Genode on the device before running a simple seL4 example first.
Hi,
I'm using a fork of seL4's elfloader-tool that I've hacked together to create an image that acutally boots (at least it gets into the genode userland image where it is failing). To be clear: I need to add calls to kernel_debugger_outstring as I get a data fault before the logging infrastructure works (I guess due to exception handling not being initialized before the fail occurs).
I'm using an am335x based board so I can't test if this works for other hardware, but if anyone is interested you can find my elfloader fork at https://github.com/N8Fear/elfloader-tool
The bootable image is then created by running the script from the elfloader dir TOOLPREFIX=arm-none-eabi- PLAT=am335x ./gen_boot_image.sh <path to genode>/build/wega_am335x/var/run/log/sel4 <path to genode>/build/wega_am335x/var/run/log/image.elf /tmp/out.elf
PLAT and TOOLPREFIX need to be changed accordingly and when building the prelinked elfloader binary PLAT and ARMV needs to be adjusted as well (take a look at the Makefile).
I guess for your board you should try PLAT=imx6 for building and for creating the image.
I guess I should do some cleanup if anyone else wants to use the stuff...
With kind regards, Hinnerk
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Hinnerk,
On 24.06.2017 01:20, Hinnerk van Bruinehsen wrote:
I'm using a fork of seL4's elfloader-tool that I've hacked together to create an image that acutally boots (at least it gets into the genode userland image where it is failing). To be clear: I need to add calls to kernel_debugger_outstring as I get a data fault before the logging infrastructure works (I guess due to exception handling not being initialized before the fail occurs).
I'm using an am335x based board so I can't test if this works for other hardware, but if anyone is interested you can find my elfloader fork at https://github.com/N8Fear/elfloader-tool
The bootable image is then created by running the script from the elfloader dir TOOLPREFIX=arm-none-eabi- PLAT=am335x ./gen_boot_image.sh <path to genode>/build/wega_am335x/var/run/log/sel4 <path to genode>/build/wega_am335x/var/run/log/image.elf /tmp/out.elf
PLAT and TOOLPREFIX need to be changed accordingly and when building the prelinked elfloader binary PLAT and ARMV needs to be adjusted as well (take a look at the Makefile).
just wanted to say, thanks for your seL4 elfloader tool adaptations to make it usable standalone (so - no need to dissect Camkes for it, like getting cpio lib and common.mk mainly).
Thanks to your work I could get the tool integrated into the run tool infrastructure of Genode in within one day. And the best, it boots and I get the serial life sign of Genode/seL4 on ARM.
Great !
Hi,
With Genode 17.08 released, what is the current level of support for Genode/seL4 on i.MX6 platform? I've applied my previous changes to Genode to enable it on Sabre Lite platform, and currently I have no problems running test scenarios under default hw kernel. But when attempting to run Genode with seL4, the boot process hangs up once it reaches "Jumping to kernel-image entry point..."
ELF-loader started on CPU: ARM Ltd. Cortex-A9 r2p10 paddr=[20000000..201bc01f] ELF-loading image 'kernel' paddr=[10000000..10039fff] vaddr=[e0000000..e0039fff] virt_entry=e0000000 ELF-loading image 'genode.elf' paddr=[1003a000..10261fff] vaddr=[2000000..2227fff] virt_entry=2000000 Enabling MMU and paging Jumping to kernel-image entry point...
I've tried to introduce debug statements like Genode's log( ) for core component and kernel_debugger_outstring( ) for seL4 side, but it never reaches any of them. Is it even possible to run a simple Genode scenario (e.g., run/log or run/init) on seL4 on ARM at the moment?
Thank you
On Mon, Jun 26, 2017 at 12:14 AM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Hi, Norman
I wonder, how exactly are you running the image on the board?
I normally just copy created image over to SD card and then run it via bootelf command.
In contrast, on ARM, everything (seL4 kernel + Genode) must be contained
in a single image. The details of how such an image is assembled is kernel-specific This might explain why the image didn't give me any output. I ended up with two images: image.elf & sel4.elf instead of just image.elf in my <sabre_lite>/var/run/log/
Consequently, there must exist a seL4-specific tool for creating it. Can
you please elaborate, which tool you use and which particular steps you take? Didn't think of any tool for combining image.elf & sel4.elf together until I got your reply. Only thought of modifying /tool/run/boot_dir/sel4 file. I'll give Hinnerks elfloader-tool a try today.
Have you tried to run a non-Genode-based seL4 image on the hardware? I
would not try to run
Genode on the device before running a simple seL4 example first.
Yes, this was my starting point. All seL4 apps ran w/o any problems.
Thanks
On Fri, Jun 23, 2017 at 7:20 PM, Hinnerk van Bruinehsen < h.v.bruinehsen@...491...> wrote:
On Fri, Jun 23, 2017 at 12:00:42PM +0200, Norman Feske wrote:
Hello Yevgeny,
On 23.06.2017 05:31, Yevgeny Lavrov wrote:
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
I wonder, how exactly are you running the image on the board? In particular, how is the image created?
I am asking because the boot procedure on ARM is different from x86/multiboot. On x86, the kernel and the Genode ELF image are loaded by the boot loader (e.g., Grub) as separate boot modules. The kernel is started by the boot loader. At the startup of the kernel, the kernel finds the physical memory location of the Genode ELF image in the multiboot information and ELF-loads core by using this information. In contrast, on ARM, everything (seL4 kernel + Genode) must be contained in a single image. The details of how such an image is assembled is kernel-specific. Consequently, there must exist a seL4-specific tool for creating it. Can you please elaborate, which tool you use and which particular steps you take?
Another potential pitfall would be the use of the wrong UART or the use of a kernel configuration without debug support. The latter is needed for the kernel-provided UART driver. Have you tried to run a non-Genode-based seL4 image on the hardware? I would not try to run Genode on the device before running a simple seL4 example first.
Hi,
I'm using a fork of seL4's elfloader-tool that I've hacked together to create an image that acutally boots (at least it gets into the genode userland image where it is failing). To be clear: I need to add calls to kernel_debugger_outstring as I get a data fault before the logging infrastructure works (I guess due to exception handling not being initialized before the fail occurs).
I'm using an am335x based board so I can't test if this works for other hardware, but if anyone is interested you can find my elfloader fork at https://github.com/N8Fear/elfloader-tool
The bootable image is then created by running the script from the elfloader dir TOOLPREFIX=arm-none-eabi- PLAT=am335x ./gen_boot_image.sh <path to genode>/build/wega_am335x/var/run/log/sel4 <path to genode>/build/wega_am335x/var/run/log/image.elf /tmp/out.elf
PLAT and TOOLPREFIX need to be changed accordingly and when building the prelinked elfloader binary PLAT and ARMV needs to be adjusted as well (take a look at the Makefile).
I guess for your board you should try PLAT=imx6 for building and for creating the image.
I guess I should do some cleanup if anyone else wants to use the stuff...
With kind regards, Hinnerk
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
On 13.09.2017 00:31, Yevgeny Lavrov wrote:
With Genode 17.08 released, what is the current level of support for Genode/seL4 on i.MX6 platform? I've applied my previous changes to Genode
as written in the release notes, we support out-of-the-box the i.MX6 based Wand-Quad board.
to enable it on Sabre Lite platform, and currently I have no problems running test scenarios under default hw kernel. But when attempting to run Genode with seL4, the boot process hangs up once it reaches "Jumping to kernel-image entry point..."
ELF-loader started on CPU: ARM Ltd. Cortex-A9 r2p10 paddr=[20000000..201bc01f] ELF-loading image 'kernel' paddr=[10000000..10039fff] vaddr=[e0000000..e0039fff] virt_entry=e0000000 ELF-loading image 'genode.elf' paddr=[1003a000..10261fff] vaddr=[2000000..2227fff] virt_entry=2000000 Enabling MMU and paging Jumping to kernel-image entry point...
The UART for Sabre Lite and Wand Quad are not the same, as far as I know.
If you have based your modifications on
repos/base-sel4/lib/mk/spec/wand_quad/kernel-sel4.mk
make sure that the line with the "sed" is dropped/removed, because this line changes the UART "#define" to match the Wand_Quad board (and not the Sabre Lite) for the elfloader of seL4 (elfloader/src/arch-arm/plat-imx6/platform.h) in the build directory.
Also, the seL4 kernel configuration (autoconf.h) is adjusted to match the Wand Quad board, and not the Sabre Lite board, see
repos/base-sel4/patches/wand_quad.config repos/base-sel4/ports/sel4.port
I've tried to introduce debug statements like Genode's log( ) for core component and kernel_debugger_outstring( ) for seL4 side, but it never
You don't get a sign of life of the kernel, so you will not get any sign from Genode either. Genode uses the debug facility of the seL4 kernel to print messages, so you have to have to set the right board (autoconf.h) and UART configuration for the seL4 elfloader (elfloader/src/arch-arm/plat-imx6/platform.h).
reaches any of them. Is it even possible to run a simple Genode scenario (e.g., run/log or run/init) on seL4 on ARM at the moment?
Sure, on the Wand Quad board all tests of tool/autopilot.list for Genode/seL4 are executed every night and the results look fine.
Cheers.
Thank you
On Mon, Jun 26, 2017 at 12:14 AM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Hi, Norman
I wonder, how exactly are you running the image on the board?
I normally just copy created image over to SD card and then run it via bootelf command.
In contrast, on ARM, everything (seL4 kernel + Genode) must be contained
in a single image. The details of how such an image is assembled is kernel-specific This might explain why the image didn't give me any output. I ended up with two images: image.elf & sel4.elf instead of just image.elf in my <sabre_lite>/var/run/log/
Consequently, there must exist a seL4-specific tool for creating it. Can
you please elaborate, which tool you use and which particular steps you take? Didn't think of any tool for combining image.elf & sel4.elf together until I got your reply. Only thought of modifying /tool/run/boot_dir/sel4 file. I'll give Hinnerks elfloader-tool a try today.
Have you tried to run a non-Genode-based seL4 image on the hardware? I
would not try to run
Genode on the device before running a simple seL4 example first.
Yes, this was my starting point. All seL4 apps ran w/o any problems.
Thanks
On Fri, Jun 23, 2017 at 7:20 PM, Hinnerk van Bruinehsen < h.v.bruinehsen@...491...> wrote:
On Fri, Jun 23, 2017 at 12:00:42PM +0200, Norman Feske wrote:
Hello Yevgeny,
On 23.06.2017 05:31, Yevgeny Lavrov wrote:
Running the image on board gave no result, apart from msg: ## Starting application at 0x10001000 ...
I wonder, how exactly are you running the image on the board? In particular, how is the image created?
I am asking because the boot procedure on ARM is different from x86/multiboot. On x86, the kernel and the Genode ELF image are loaded by the boot loader (e.g., Grub) as separate boot modules. The kernel is started by the boot loader. At the startup of the kernel, the kernel finds the physical memory location of the Genode ELF image in the multiboot information and ELF-loads core by using this information. In contrast, on ARM, everything (seL4 kernel + Genode) must be contained in a single image. The details of how such an image is assembled is kernel-specific. Consequently, there must exist a seL4-specific tool for creating it. Can you please elaborate, which tool you use and which particular steps you take?
Another potential pitfall would be the use of the wrong UART or the use of a kernel configuration without debug support. The latter is needed for the kernel-provided UART driver. Have you tried to run a non-Genode-based seL4 image on the hardware? I would not try to run Genode on the device before running a simple seL4 example first.
Hi,
I'm using a fork of seL4's elfloader-tool that I've hacked together to create an image that acutally boots (at least it gets into the genode userland image where it is failing). To be clear: I need to add calls to kernel_debugger_outstring as I get a data fault before the logging infrastructure works (I guess due to exception handling not being initialized before the fail occurs).
I'm using an am335x based board so I can't test if this works for other hardware, but if anyone is interested you can find my elfloader fork at https://github.com/N8Fear/elfloader-tool
The bootable image is then created by running the script from the elfloader dir TOOLPREFIX=arm-none-eabi- PLAT=am335x ./gen_boot_image.sh <path to genode>/build/wega_am335x/var/run/log/sel4 <path to genode>/build/wega_am335x/var/run/log/image.elf /tmp/out.elf
PLAT and TOOLPREFIX need to be changed accordingly and when building the prelinked elfloader binary PLAT and ARMV needs to be adjusted as well (take a look at the Makefile).
I guess for your board you should try PLAT=imx6 for building and for creating the image.
I guess I should do some cleanup if anyone else wants to use the stuff...
With kind regards, Hinnerk
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
On 13.09.2017 08:48, Alexander Boettcher wrote:
to enable it on Sabre Lite platform, and currently I have no problems running test scenarios under default hw kernel. But when attempting to run Genode with seL4, the boot process hangs up once it reaches "Jumping to kernel-image entry point..."
ELF-loader started on CPU: ARM Ltd. Cortex-A9 r2p10 paddr=[20000000..201bc01f] ELF-loading image 'kernel' paddr=[10000000..10039fff] vaddr=[e0000000..e0039fff] virt_entry=e0000000 ELF-loading image 'genode.elf' paddr=[1003a000..10261fff] vaddr=[2000000..2227fff] virt_entry=2000000 Enabling MMU and paging Jumping to kernel-image entry point...
The UART for Sabre Lite and Wand Quad are not the same, as far as I know.
Sorry, my assumption seems to be wrong, since the messages above are from the seL4 elfloader already.
So I presume you have just to adjust the seL4 kernel autoconf.h to match the Sabre lite board.
Also, the seL4 kernel configuration (autoconf.h) is adjusted to match the Wand Quad board, and not the Sabre Lite board, see
repos/base-sel4/patches/wand_quad.config repos/base-sel4/ports/sel4.port
On Wed, Sep 13, 2017 at 12:44:11PM +0200, Alexander Boettcher wrote:
On 13.09.2017 08:48, Alexander Boettcher wrote:
The UART for Sabre Lite and Wand Quad are not the same, as far as I know.
Sorry, my assumption seems to be wrong, since the messages above are from the seL4 elfloader already.
So I presume you have just to adjust the seL4 kernel autoconf.h to match the Sabre lite board.
The kernel differentiates Sabre Lite and Wandboard regarding UART config and available RAM.
$ grep -rnA2 'CONFIG_PLAT_SABRE|CONFIG_PLAT_WANDQ' . ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h:75:#define CONFIG_PLAT_WANDQ 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-76-#define CONFIG_HAVE_LIB_PLATSUPPORT 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-77-#define CONFIG_NUM_DOMAINS 16 -- ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:55:#if defined(CONFIG_PLAT_SABRE) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-56- /* Sabre has 1 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-57- { /* .start = */ 0x10000000, /* .end = */ 0x50000000 } ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:58:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-59- /* Wandboard Quad: 2 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-60- { /* .start = */ 0x10000000, /* .end = */ 0x90000000 } -- ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:15:#ifdef CONFIG_PLAT_SABRE ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-16-#define UART_PADDR UART2_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:17:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-18-#define UART_PADDR UART1_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-19-#else
Greets
Thank you for quick reply.
It was very helpful, and pointed me in the right direction. The answer was hiding within repos/base-sel4/patches/wand_quad.config, I somehow overlooked this directory while looking for answers. It turned out to be a one line fix in <genode_dir>/contrib/sel4-<SHA>/src/kernel/sel4/configs/imx6/sabre_lite/autoconf.h file. Changing #define CONFIG_PLAT_WANDQ 1 to #define CONFIG_PLAT_SABRE 1 did the trick. Now I can observe outputs from elf-loader tool, seL4 and Genode.
Cheers
On Wed, Sep 13, 2017 at 8:30 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
On Wed, Sep 13, 2017 at 12:44:11PM +0200, Alexander Boettcher wrote:
On 13.09.2017 08:48, Alexander Boettcher wrote:
The UART for Sabre Lite and Wand Quad are not the same, as far as I
know.
Sorry, my assumption seems to be wrong, since the messages above are from the seL4 elfloader already.
So I presume you have just to adjust the seL4 kernel autoconf.h to match the Sabre lite board.
The kernel differentiates Sabre Lite and Wandboard regarding UART config and available RAM.
$ grep -rnA2 'CONFIG_PLAT_SABRE|CONFIG_PLAT_WANDQ' . ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h:75:#define CONFIG_PLAT_WANDQ 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-76-#define CONFIG_HAVE_LIB_PLATSUPPORT 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-77-#define CONFIG_NUM_DOMAINS 16 -- ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:55:#if defined(CONFIG_PLAT_SABRE) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-56- /* Sabre has 1 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-57- { /* .start = */ 0x10000000, /* .end = */ 0x50000000 } ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:58:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-59- /* Wandboard Quad: 2 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-60- { /* .start = */ 0x10000000, /* .end = */ 0x90000000 } -- ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:15:#ifdef CONFIG_PLAT_SABRE ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-16-#define UART_PADDR UART2_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:17:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-18-#define UART_PADDR UART1_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-19-#else
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi
Now that I have Genode running on i.MX6 under both kernels, hw and seL4, I want to move to my next objective, which is to bring up Linux on top of Genode/hw on ARM. Is there any already existing run script that I may use (as a reference) to achieve that on i.MX6 platform? Do I need virtualization for this?
Cheers
On Wed, Sep 13, 2017 at 4:45 PM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Thank you for quick reply.
It was very helpful, and pointed me in the right direction. The answer was hiding within repos/base-sel4/patches/wand_quad.config, I somehow overlooked this directory while looking for answers. It turned out to be a one line fix in <genode_dir>/contrib/sel4-< SHA>/src/kernel/sel4/configs/imx6/sabre_lite/autoconf.h file. Changing #define CONFIG_PLAT_WANDQ 1 to #define CONFIG_PLAT_SABRE 1 did the trick. Now I can observe outputs from elf-loader tool, seL4 and Genode.
Cheers
On Wed, Sep 13, 2017 at 8:30 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
On Wed, Sep 13, 2017 at 12:44:11PM +0200, Alexander Boettcher wrote:
On 13.09.2017 08:48, Alexander Boettcher wrote:
The UART for Sabre Lite and Wand Quad are not the same, as far as I
know.
Sorry, my assumption seems to be wrong, since the messages above are from the seL4 elfloader already.
So I presume you have just to adjust the seL4 kernel autoconf.h to match the Sabre lite board.
The kernel differentiates Sabre Lite and Wandboard regarding UART config and available RAM.
$ grep -rnA2 'CONFIG_PLAT_SABRE|CONFIG_PLAT_WANDQ' . ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h:75:#define CONFIG_PLAT_WANDQ 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-76-#define CONFIG_HAVE_LIB_PLATSUPPORT 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-77-#define CONFIG_NUM_DOMAINS 16 -- ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:55:#if defined(CONFIG_PLAT_SABRE) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-56- /* Sabre has 1 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-57- { /* .start = */ 0x10000000, /* .end = */ 0x50000000 } ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:58:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-59- /* Wandboard Quad: 2 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-60- { /* .start = */ 0x10000000, /* .end = */ 0x90000000 } -- ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:15:#ifdef CONFIG_PLAT_SABRE ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-16-#define UART_PADDR UART2_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:17:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-18-#define UART_PADDR UART1_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-19-#else
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi
When trying various test scripts, I ran into the following problem while executing "run/init" script on Sabre Lite .... [init -> test-init] step 32 (init_config) [init -> test-init] step 33 (expect_log) [init -> test-init] [init -> log] config 3: became unavailable (ignored) no RM attachment (READ pf_addr=0x5f75c pf_ip=0x5f75c from pager_object: pd='init -> init -> log' thread='ep')
Are there any suggestions on what might be causing it?
And, is it possible to reproduce the USB Armory's "run/tz_vmm" scenario on i.MX6 platform?
Thanks
On Fri, Sep 29, 2017 at 2:07 AM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Hi
Now that I have Genode running on i.MX6 under both kernels, hw and seL4, I want to move to my next objective, which is to bring up Linux on top of Genode/hw on ARM. Is there any already existing run script that I may use (as a reference) to achieve that on i.MX6 platform? Do I need virtualization for this?
Cheers
On Wed, Sep 13, 2017 at 4:45 PM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Thank you for quick reply.
It was very helpful, and pointed me in the right direction. The answer was hiding within repos/base-sel4/patches/wand_quad.config, I somehow overlooked this directory while looking for answers. It turned out to be a one line fix in <genode_dir>/contrib/sel4-<SHA
/src/kernel/sel4/configs/imx6/sabre_lite/autoconf.h file.
Changing #define CONFIG_PLAT_WANDQ 1 to #define CONFIG_PLAT_SABRE 1 did the trick. Now I can observe outputs from elf-loader tool, seL4 and Genode.
Cheers
On Wed, Sep 13, 2017 at 8:30 AM, Christian Helmuth < christian.helmuth@...1...> wrote:
On Wed, Sep 13, 2017 at 12:44:11PM +0200, Alexander Boettcher wrote:
On 13.09.2017 08:48, Alexander Boettcher wrote:
The UART for Sabre Lite and Wand Quad are not the same, as far as I
know.
Sorry, my assumption seems to be wrong, since the messages above are from the seL4 elfloader already.
So I presume you have just to adjust the seL4 kernel autoconf.h to
match
the Sabre lite board.
The kernel differentiates Sabre Lite and Wandboard regarding UART config and available RAM.
$ grep -rnA2 'CONFIG_PLAT_SABRE|CONFIG_PLAT_WANDQ' . ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h:75:#define CONFIG_PLAT_WANDQ 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-76-#define CONFIG_HAVE_LIB_PLATSUPPORT 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-77-#define CONFIG_NUM_DOMAINS 16 -- ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:55:#if defined(CONFIG_PLAT_SABRE) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-56- /* Sabre has 1 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-57- { /* .start = */ 0x10000000, /* .end = */ 0x50000000 } ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:58:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-59- /* Wandboard Quad: 2 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-60- { /* .start = */ 0x10000000, /* .end = */ 0x90000000 } -- ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:15:#ifdef CONFIG_PLAT_SABRE ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-16-#define UART_PADDR UART2_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:17:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-18-#define UART_PADDR UART1_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-19-#else
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On 10/06/2017 06:09 AM, Yevgeny Lavrov wrote:
Hi
When trying various test scripts, I ran into the following problem while executing "run/init" script on Sabre Lite .... [init -> test-init] step 32 (init_config) [init -> test-init] step 33 (expect_log) [init -> test-init] [init -> log] config 3: became unavailable (ignored) no RM attachment (READ pf_addr=0x5f75c pf_ip=0x5f75c from pager_object: pd='init -> init -> log' thread='ep')
Are there any suggestions on what might be causing it?
well, it is not strange that non-cooperatively killed programs are triggering last page-faults, because during their destruction several resources are hardly withdrawn. The init.run test script repeatedly spawns components and removes them again. Therefore, above log messages are nothing worrying but normal. The question is, whether you get "Run script execution successful." in the end.
And, is it possible to reproduce the USB Armory's "run/tz_vmm" scenario on i.MX6 platform?
This cannot be done out of the box. The most easy part would be to add support to the hw kernel to execute i.MX6 in the secure world, provide the TrustZone specific VM interface to the user-land, and to partition the memory into secure and normal one. The next probably more time-consuming step is the para-virtualization of the i.MX6 specific Linux Kernel that is run as "guest" in the tz_vmm.run scenario.
Regards Stefan
Thanks
On Fri, Sep 29, 2017 at 2:07 AM, Yevgeny Lavrov <ylavrov13@...9... mailto:ylavrov13@...9...> wrote:
Hi Now that I have Genode running on i.MX6 under both kernels, hw and seL4, I want to move to my next objective, which is to bring up Linux on top of Genode/hw on ARM. Is there any already existing run script that I may use (as a reference) to achieve that on i.MX6 platform? Do I need virtualization for this? Cheers On Wed, Sep 13, 2017 at 4:45 PM, Yevgeny Lavrov <ylavrov13@...9... <mailto:ylavrov13@...9...>> wrote: Thank you for quick reply. It was very helpful, and pointed me in the right direction.The answer was hiding within repos/base-sel4/patches/wand_quad.config, I somehow overlooked this directory while looking for answers. It turned out to be a one line fix in <genode_dir>/contrib/sel4-<SHA>/src/kernel/sel4/configs/imx6/sabre_lite/autoconf.h file. Changing#define CONFIG_PLAT_WANDQ 1 to #define CONFIG_PLAT_SABRE 1 did the trick. Now I can observe outputs from elf-loader tool, seL4 and Genode. Cheers On Wed, Sep 13, 2017 at 8:30 AM, Christian Helmuth <christian.helmuth@...1... <mailto:christian.helmuth@...1...>> wrote: On Wed, Sep 13, 2017 at 12:44:11PM +0200, Alexander Boettcher wrote: > On 13.09.2017 08:48, Alexander Boettcher wrote: > > The UART for Sabre Lite and Wand Quad are not the same, as far as I know. > > Sorry, my assumption seems to be wrong, since the messages above are > from the seL4 elfloader already. > > So I presume you have just to adjust the seL4 kernel autoconf.h to match > the Sabre lite board. The kernel differentiates Sabre Lite and Wandboard regarding UART config and available RAM. $ grep -rnA2 'CONFIG_PLAT_SABRE\|CONFIG_PLAT_WANDQ' . ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h:75:#define CONFIG_PLAT_WANDQ 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-76-#define CONFIG_HAVE_LIB_PLATSUPPORT 1 ./src/kernel/sel4/configs/imx6/wand_quad/autoconf.h-77-#define CONFIG_NUM_DOMAINS 16 -- ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:55:#if defined(CONFIG_PLAT_SABRE) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-56- /* Sabre has 1 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-57- { /* .start = */ 0x10000000, /* .end = */ 0x50000000 } ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h:58:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-59- /* Wandboard Quad: 2 GiB */ ./src/kernel/sel4/include/plat/imx6/plat/machine/hardware.h-60- { /* .start = */ 0x10000000, /* .end = */ 0x90000000 } -- ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:15:#ifdef CONFIG_PLAT_SABRE ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-16-#define UART_PADDR UART2_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h:17:#elif defined(CONFIG_PLAT_WANDQ) ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-18-#define UART_PADDR UART1_PADDR ./src/kernel/sel4/include/plat/imx6/plat/machine/devices.h-19-#else Greets -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main <https://lists.sourceforge.net/lists/listinfo/genode-main>
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Yevgeni, Stefan,
Am 19.10.2017 um 13:05 schrieb Stefan Kalkowski:
And, is it possible to reproduce the USB Armory's "run/tz_vmm" scenario on i.MX6 platform?
This cannot be done out of the box. The most easy part would be to add support to the hw kernel to execute i.MX6 in the secure world, provide the TrustZone specific VM interface to the user-land, and to partition the memory into secure and normal one. The next probably more time-consuming step is the para-virtualization of the i.MX6 specific Linux Kernel that is run as "guest" in the tz_vmm.run scenario.
Let me add that the USB-Armory branch on my Linux fork [1] might serve as template for para-virtualization. The youngest commit adds a para-virtualized block driver and serial driver to a 4.2.3 Linux.
Cheers, Martin
[1] branch https://github.com/m-stein/linux/commits/genode_hw_usb_armory_tz_vmm
Hi,
Unfortunately, it never gets to the point where it says "Run script execution successful", everything breaks once it reaches step 33 of the init.run script. I've also given a try to Genode/seL4 on Wandboard Quad, but ended up with the same result. Other scripts (except bomb, part_blk and resource_request) ran w/o any problems. Fresh, out of the box copy of Genode 17.08 breaks in the same spot when executed on Wandboard Quad, so I'm including complete serial output to this e-mail for you to take a look.
Another issue with Wandboard Quad that I've encountered is: when compiling Genode with hw kernel, for some reason, I can't observe any output over the serial.
Hit any key to stop autoboot: 0 => fatload mmc 0 0x30000000 image.elf reading image.elf 1897104 bytes read in 109 ms (16.6 MiB/s) => bootelf 0x30000000 ## Starting application at 0x10001000 ...
Nothing after this point. However, when compiled with seL4 kernel instead of default hw, this problem goes away. Any suggestions on what might be causing it?
Serial Output: Fresh copy of Genode 17.08/seL4 on Wandboard Quad
Hit any key to stop autoboot: 0
=> fatload mmc 0 0x30000000 image.elf
reading image.elf
2195928 bytes read in 123 ms (17 MiB/s)
=> bootelf 0x30000000
## Starting application at 0x20000000 ...
ELF-loader started on CPU: ARM Ltd. Cortex-A9 r2p10
paddr=[20000000..2020801f]
ELF-loading image 'kernel'
paddr=[10000000..10039fff]
vaddr=[e0000000..e0039fff]
virt_entry=e0000000
ELF-loading image 'genode.elf'
paddr=[1003a000..10320fff]
vaddr=[2000000..22e6fff]
virt_entry=2000000
Enabling MMU and paging
Jumping to kernel-image entry point...
Bootstrapping kernel
Booting all finished, dropped to user space
<<seL4(CPU 0) [decodeCNodeInvocation/106 T0xffe7cd00 "rootserver" @202b124]: CNode Copy/Mint/Move/Mutate: Source slot invalid or empty.>> Warning: copy: seL4_CNode_Copy (0x7) returned 6
:phys_mem_16k: Allocator 0x21d2058 dump:
Block: [10000000,10010000) size=64K avail=64K max_avail=448K
Block: [10324000,10394000) size=448K avail=448K max_avail=448K
=> mem_size=524288 (0 MB) / mem_avail=524288 (0 MB)
virtual address layout of core:
overall [00002000,c0000000)
core image [02000000,022e7000)
ipc buffer [022e7000,022e8000)
boot_info [022e8000,022e9000)
stack area [40000000,50000000)
Warning: need physical memory, but Platform object not constructed yet
Warning: need physical memory, but Platform object not constructed yet
:phys_alloc: Allocator 0x219f11c dump:
Block: [10321000,10324000) size=12K avail=12K max_avail=12K
Block: [10394000,11000000) size=12720K avail=12720K max_avail=425980K
Block: [12000000,12001000) size=4K avail=0 max_avail=0
Block: [12001000,2c000000) size=425980K avail=425980K max_avail=425980K
Block: [2d000000,2d001000) size=4K avail=0 max_avail=425980K
Block: [2d001000,2d002000) size=4K avail=0 max_avail=0
Block: [2d002000,2e000000) size=16376K avail=16376K max_avail=16376K
Block: [2f106000,2f107000) size=4K avail=0 max_avail=0
Block: [2f107000,2f180000) size=484K avail=484K max_avail=484K
Block: [2f200000,2f201000) size=4K avail=0 max_avail=425980K
Block: [2f201000,2f202000) size=4K avail=0 max_avail=0
Block: [2f202000,2f203000) size=4K avail=0 max_avail=0
Block: [2f203000,2f204000) size=4K avail=0 max_avail=0
Block: [2f204000,2f205000) size=4K avail=0 max_avail=0
Block: [2f205000,2f206000) size=4K avail=0 max_avail=0
Block: [2f206000,2f207000) size=4K avail=0 max_avail=0
Block: [2f207000,2f208000) size=4K avail=0 max_avail=0
Block: [2f208000,2f209000) size=4K avail=0 max_avail=0
Block: [2f209000,2f20a000) size=4K avail=0 max_avail=0
Block: [2f20a000,2f20b000) size=4K avail=0 max_avail=0
Block: [2f20b000,2f20c000) size=4K avail=0 max_avail=0
Block: [2f20c000,2f20d000) size=4K avail=0 max_avail=425980K
Block: [2f20d000,2f20e000) size=4K avail=0 max_avail=0
Block: [2f20e000,2f20f000) size=4K avail=0 max_avail=0
Block: [2f20f000,2f210000) size=4K avail=0 max_avail=0
Block: [2f210000,2f211000) size=4K avail=0 max_avail=0
Block: [2f211000,2f212000) size=4K avail=0 max_avail=0
Block: [2f212000,2f213000) size=4K avail=0 max_avail=0
Block: [2f213000,2f214000) size=4K avail=0 max_avail=0
Block: [2f214000,2f215000) size=4K avail=0 max_avail=0
Block: [2f215000,2f216000) size=4K avail=0 max_avail=0
Block: [2f216000,2f217000) size=4K avail=0 max_avail=0
Block: [2f217000,2f218000) size=4K avail=0 max_avail=0
Block: [2f218000,2f219000) size=4K avail=0 max_avail=0
Block: [2f219000,2f21a000) size=4K avail=0 max_avail=0
Block: [2f21a000,2f21b000) size=4K avail=0 max_avail=0
Block: [2f21b000,2f21c000) size=4K avail=0 max_avail=0
Block: [2f21c000,2f21d000) size=4K avail=0 max_avail=0
Block: [2f21d000,2f21e000) size=4K avail=0 max_avail=0
Block: [2f21e000,2f21f000) size=4K avail=0 max_avail=0
Block: [2f21f000,2f220000) size=4K avail=0 max_avail=0
Block: [2f220000,2f221000) size=4K avail=0 max_avail=0
Block: [2f221000,2f222000) size=4K avail=0 max_avail=0
Block: [2f222000,2f223000) size=4K avail=0 max_avail=0
Block: [2f223000,2f224000) size=4K avail=0 max_avail=0
Block: [2f224000,2f225000) size=4K avail=0 max_avail=425980K
Block: [2f225000,2f226000) size=4K avail=0 max_avail=0
Block: [2f226000,2f227000) size=4K avail=0 max_avail=0
Block: [2f227000,2f228000) size=4K avail=0 max_avail=0
Block: [2f228000,2f229000) size=4K avail=0 max_avail=0
Block: [2f229000,2f22a000) size=4K avail=0 max_avail=0
Block: [2f22a000,2f22b000) size=4K avail=0 max_avail=0
Block: [2f22b000,2f22c000) size=4K avail=0 max_avail=0
Block: [2f22c000,2f22d000) size=4K avail=0 max_avail=0
Block: [2f22d000,2f22e000) size=4K avail=0 max_avail=0
Block: [2f22e000,2f22f000) size=4K avail=0 max_avail=0
Block: [2f22f000,2f230000) size=4K avail=0 max_avail=0
Block: [2f230000,2f231000) size=4K avail=0 max_avail=0
Block: [2f231000,2f232000) size=4K avail=0 max_avail=0
Block: [2f232000,2f233000) size=4K avail=0 max_avail=0
Block: [2f233000,2f234000) size=4K avail=0 max_avail=0
Block: [2f234000,2f235000) size=4K avail=0 max_avail=0
Block: [2f235000,2f236000) size=4K avail=0 max_avail=0
Block: [2f236000,2f237000) size=4K avail=0 max_avail=0
Block: [2f237000,2f238000) size=4K avail=0 max_avail=0
Block: [2f238000,2f239000) size=4K avail=0 max_avail=0
Block: [2f239000,2f23a000) size=4K avail=0 max_avail=0
Block: [2f23a000,2f23b000) size=4K avail=0 max_avail=0
Block: [2f23b000,2f23c000) size=4K avail=0 max_avail=0
Block: [2f23c000,2f23d000) size=4K avail=0 max_avail=0
Block: [2f23d000,2f23e000) size=4K avail=0 max_avail=0
Block: [2f23e000,2f23f000) size=4K avail=0 max_avail=0
Block: [2f23f000,2f240000) size=4K avail=0 max_avail=0
Block: [2f240000,2f241000) size=4K avail=0 max_avail=0
Block: [2f241000,2f242000) size=4K avail=0 max_avail=0
Block: [2f242000,2f243000) size=4K avail=0 max_avail=0
Block: [2f243000,2f244000) size=4K avail=0 max_avail=0
Block: [2f244000,2f245000) size=4K avail=0 max_avail=0
Block: [2f245000,2f246000) size=4K avail=0 max_avail=0
Block: [2f246000,2f247000) size=4K avail=0 max_avail=0
Block: [2f247000,2f248000) size=4K avail=0 max_avail=0
Block: [2f248000,2f249000) size=4K avail=0 max_avail=0
Block: [2f249000,2f24a000) size=4K avail=0 max_avail=0
Block: [2f24a000,2f24b000) size=4K avail=0 max_avail=0
Block: [2f24b000,2f24c000) size=4K avail=0 max_avail=0
Block: [2f24c000,2f24d000) size=4K avail=0 max_avail=0
Block: [2f24d000,2f24e000) size=4K avail=0 max_avail=0
Block: [2f24e000,2f24f000) size=4K avail=0 max_avail=0
Block: [2f24f000,2f250000) size=4K avail=0 max_avail=0
Block: [2f250000,2f251000) size=4K avail=0 max_avail=0
Block: [2f251000,2f252000) size=4K avail=0 max_avail=0
Block: [2f252000,2f253000) size=4K avail=0 max_avail=0
Block: [2f253000,2f254000) size=4K avail=0 max_avail=0
Block: [2f254000,2f255000) size=4K avail=0 max_avail=12152K
Block: [2f255000,2f256000) size=4K avail=0 max_avail=0
Block: [2f256000,2f257000) size=4K avail=0 max_avail=0
Block: [2f257000,2f258000) size=4K avail=0 max_avail=0
Block: [2f258000,2f259000) size=4K avail=0 max_avail=0
Block: [2f259000,2f25a000) size=4K avail=0 max_avail=0
Block: [2f25a000,2f25b000) size=4K avail=0 max_avail=0
Block: [2f25b000,2f25c000) size=4K avail=0 max_avail=0
Block: [2f25c000,2f25d000) size=4K avail=0 max_avail=0
Block: [2f25d000,2f25e000) size=4K avail=0 max_avail=0
Block: [2f25e000,2f25f000) size=4K avail=0 max_avail=0
Block: [2f25f000,2f260000) size=4K avail=0 max_avail=0
Block: [2f260000,2f261000) size=4K avail=0 max_avail=0
Block: [2f261000,2f262000) size=4K avail=0 max_avail=0
Block: [2f262000,2f263000) size=4K avail=0 max_avail=0
Block: [2f263000,2f264000) size=4K avail=0 max_avail=0
Block: [2f264000,2f265000) size=4K avail=0 max_avail=0
Block: [2f265000,2f266000) size=4K avail=0 max_avail=0
Block: [2f266000,2f267000) size=4K avail=0 max_avail=0
Block: [2f267000,2f268000) size=4K avail=0 max_avail=0
Block: [2f268000,2f269000) size=4K avail=0 max_avail=0
Block: [2f269000,2f26a000) size=4K avail=0 max_avail=0
Block: [2f26a000,2f26b000) size=4K avail=0 max_avail=0
Block: [2f26b000,2f26c000) size=4K avail=0 max_avail=0
Block: [2f26c000,2f26d000) size=4K avail=0 max_avail=12152K
Block: [2f26d000,2f26e000) size=4K avail=0 max_avail=0
Block: [2f26e000,2f26f000) size=4K avail=0 max_avail=0
Block: [2f26f000,2f270000) size=4K avail=0 max_avail=0
Block: [2f270000,2f271000) size=4K avail=0 max_avail=0
Block: [2f271000,2f272000) size=4K avail=0 max_avail=0
Block: [2f272000,2f273000) size=4K avail=0 max_avail=0
Block: [2f273000,2f274000) size=4K avail=0 max_avail=0
Block: [2f274000,2f275000) size=4K avail=0 max_avail=0
Block: [2f275000,2f276000) size=4K avail=0 max_avail=0
Block: [2f276000,2f277000) size=4K avail=0 max_avail=0
Block: [2f277000,2f278000) size=4K avail=0 max_avail=0
Block: [2f278000,2f279000) size=4K avail=0 max_avail=12152K
Block: [2f279000,2f27a000) size=4K avail=0 max_avail=0
Block: [2f27a000,2f27b000) size=4K avail=0 max_avail=0
Block: [2f27b000,2f27c000) size=4K avail=0 max_avail=0
Block: [2f27c000,2f27d000) size=4K avail=0 max_avail=0
Block: [2f27d000,2f27e000) size=4K avail=0 max_avail=0
Block: [2f27e000,2f27f000) size=4K avail=0 max_avail=12152K
Block: [2f27f000,2f280000) size=4K avail=0 max_avail=0
Block: [2f280000,2f281000) size=4K avail=0 max_avail=12152K
Block: [2f281000,2f282000) size=4K avail=0 max_avail=0
Block: [2f282000,2fe60000) size=12152K avail=12152K max_avail=12152K
Block: [2fe70000,2fe7c000) size=48K avail=48K max_avail=48K
=> mem_size=479547392 (457 MB) / mem_avail=478998528 (456 MB)
:unused_phys_alloc:Allocator 0x21a45dc dump:
Block: [00104000,00110000) size=48K avail=48K max_avail=48K
Block: [00118000,00120000) size=32K avail=32K max_avail=48K
Block: [00129000,00130000) size=28K avail=28K max_avail=784K
Block: [0013c000,00200000) size=784K avail=784K max_avail=784K
Block: [00400000,00800000) size=4M avail=4M max_avail=4M
Block: [00a00000,00b00000) size=1M avail=1M max_avail=1M
Block: [00d00000,01000000) size=3M avail=3M max_avail=3M
Block: [01f00000,01ffc000) size=1008K avail=1008K max_avail=1008K
Block: [02000000,02004000) size=16K avail=16K max_avail=4M
Block: [0201c000,02020000) size=16K avail=16K max_avail=16K
Block: [02038000,0203c000) size=16K avail=16K max_avail=16K
Block: [020cb000,020cc000) size=4K avail=4K max_avail=4K
Block: [020dd000,020e0000) size=12K avail=12K max_avail=192K
Block: [020f0000,02100000) size=64K avail=64K max_avail=64K
Block: [02110000,02140000) size=192K avail=192K max_avail=192K
Block: [02145000,0214f000) size=40K avail=40K max_avail=40K
Block: [02161000,0217c000) size=108K avail=108K max_avail=3409424K
Block: [02180000,02184000) size=16K avail=16K max_avail=16K
Block: [021c4000,021d0000) size=48K avail=48K max_avail=48K
Block: [021f8000,02200000) size=32K avail=32K max_avail=32K
Block: [0220c000,02400000) size=2000K avail=2000K max_avail=212M
Block: [02c00000,10000000) size=212M avail=212M max_avail=212M
Block: [10010000,10321000) size=3140K avail=3140K max_avail=212M
Block: [11000000,12000000) size=16M avail=16M max_avail=16M
Block: [2c000000,2d000000) size=16M avail=16M max_avail=3409424K
Block: [2e000000,2f106000) size=17432K avail=17432K max_avail=17432K
Block: [2f180000,2f200000) size=512K avail=512K max_avail=3409424K
Block: [2fe60000,2fe70000) size=64K avail=64K max_avail=3409424K
Block: [2fe7c000,ffffffff] size=3409424K avail=3409424K max_avail=3409424K
=> mem_size=3781718016 (3606 MB) / mem_avail=3781718016 (3606 MB)
:unused_virt_alloc:Allocator 0x21a5648 dump:
Block: [00002000,02000000) size=32760K avail=32760K max_avail=32760K
Block: [022e9000,042e9000) size=32M avail=0 max_avail=0
Block: [042e9000,40000000) size=980060K avail=980060K max_avail=1792M
Block: [50000000,c0000000) size=1792M avail=1792M max_avail=1792M
=> mem_size=2949730304 (2813 MB) / mem_avail=2916175872 (2781 MB)
:virt_alloc: Allocator 0x21a0188 dump:
Block: [021d8000,021d9000) size=4K avail=0 max_avail=0
Block: [021d9000,021da000) size=4K avail=0 max_avail=0
Block: [021da000,022e7000) size=1076K avail=1076K max_avail=32M
Block: [022e9000,042e9000) size=32M avail=32M max_avail=32M
=> mem_size=34664448 (33 MB) / mem_avail=34656256 (33 MB)
:io_mem_alloc: Allocator 0x21a1200 dump:
Block: [00100000,00104000) size=16K avail=16K max_avail=16K
Block: [00110000,00118000) size=32K avail=32K max_avail=32K
Block: [00120000,00129000) size=36K avail=36K max_avail=2M
Block: [00130000,0013c000) size=48K avail=48K max_avail=48K
Block: [00200000,00400000) size=2M avail=2M max_avail=2M
Block: [00800000,00a00000) size=2M avail=2M max_avail=2M
Block: [00b00000,00d00000) size=2M avail=2M max_avail=15M
Block: [01000000,01f00000) size=15M avail=15M max_avail=15M
Block: [01ffc000,02000000) size=16K avail=16K max_avail=15M
Block: [02004000,0201c000) size=96K avail=96K max_avail=96K
Block: [02020000,02038000) size=96K avail=96K max_avail=15M
Block: [0203c000,020cb000) size=572K avail=572K max_avail=572K
Block: [020cc000,020dd000) size=68K avail=68K max_avail=572K
Block: [020e0000,020f0000) size=64K avail=64K max_avail=64K
Block: [02100000,02110000) size=64K avail=64K max_avail=15M
Block: [02140000,02145000) size=20K avail=20K max_avail=20K
Block: [0214f000,02161000) size=72K avail=72K max_avail=72K
Block: [0217c000,02180000) size=16K avail=16K max_avail=16K
Block: [02184000,021c4000) size=256K avail=256K max_avail=8M
Block: [021d0000,021f8000) size=160K avail=160K max_avail=160K
Block: [02200000,0220c000) size=48K avail=48K max_avail=8M
Block: [02400000,02c00000) size=8M avail=8M max_avail=8M
=> mem_size=32129024 (30 MB) / mem_avail=32129024 (30 MB)
boot module 'ld.lib.so' (562908 bytes)
boot module 'dummy' (77416 bytes)
boot module 'report_rom' (73960 bytes)
boot module 'timer' (68436 bytes)
boot module 'init' (201760 bytes)
boot module 'config' (33724 bytes)
boot module 'test-init' (76840 bytes)
Warning: need physical memory, but Platform object not constructed yet
Genode 17.08-177-g30948a4
456 MiB RAM and 31767 caps assigned to init
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x1 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x2 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x4 [init] child "report_rom" announces service "Report"
[init] child "report_rom" announces service "ROM"
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x8 [init] child "timer" announces service "Timer"
[init -> test-init] step 0 (sleep)
[init] child "test-init" announces service "LOG"
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10 [init -> test-init] step 0 (sleep)
[init -> test-init] step 1 (message)
[init -> test-init]
[init -> test-init] --- test state reporting ---
[init -> test-init] step 2 (init_config)
[init -> test-init] step 3 (expect_log)
[init -> test-init] [init] Error: RAM preservation exceeds available memory (ignored) [init -> test-init] [init] Warning: application: assigned RAM exceeds available RAM (ignored) [init -> test-init] step 3 (expect_log)
[init -> test-init] step 4 (sleep)
[init -> test-init] [init -> application] started (expected)
[init -> test-init] step 4 (sleep)
[init -> test-init] step 5 (expect_init_state)
[init -> test-init] step 6 (message)
[init -> test-init]
[init -> test-init] --- routing to custom log service ---
[init -> test-init] step 7 (init_config)
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x20 [init -> test-init] step 8 (expect_log)
Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x40 [init -> test-init] step 8 (expect_log)
[init -> test-init] [init] child "server" announces service "LOG" (ignored)
[init -> test-init] [init -> server] created LOG service (ignored)
[init -> test-init] step 8 (expect_log)
[init -> test-init] [init] child "indirect_server" announces service "LOG" (ignored) [init -> test-init] [init -> server] [indirect_server] created LOG service (ignored) [init -> test-init] step 8 (expect_log)
[init -> test-init] step 9 (sleep)
[init -> test-init] [init -> server] [indirect_server] [client] client started (expected) [init -> test-init] step 9 (sleep)
[init -> test-init] [init -> server] [indirect_server] [client] going to create 1 LOG connections (ignored) [init -> test-init] [init -> server] [indirect_server] [client] created all LOG connections (ignored) [init -> test-init] step 9 (sleep)
[init -> test-init] step 10 (expect_init_state)
[init -> test-init] step 11 (sleep)
[init -> test-init] step 12 (message)
[init -> test-init]
[init -> test-init] --- changing route of indirect server ---
[init -> test-init] step 13 (init_config)
[init -> test-init] step 14 (expect_log)
[init -> test-init] [init] Warning: client: lookup for service "LOG" failed (ignored) [init -> test-init] [init] Warning: client: lookup for service "LOG" failed (ignored) Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x80 Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
[init -> test-init] [init] child "indirect_server" announces service "LOG" (ignored) [init -> test-init] step 14 (expect_log)
[init -> test-init] [init -> indirect_server] created LOG service (ignored)
[init -> test-init] step 14 (expect_log)
[init -> test-init] step 15 (sleep)
[init -> test-init] [init -> indirect_server] [client] client started (expected)
[init -> test-init] step 15 (sleep)
[init -> test-init] [init -> indirect_server] [client] going to create 1 LOG connections (ignored) [init -> test-init] [init -> indirect_server] [client] created all LOG connections (ignored) [init -> test-init] step 16 (expect_init_state)
[init -> test-init] step 17 (sleep)
[init -> test-init] step 17 (sleep)
[init -> test-init] step 18 (init_config)
Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
[init -> test-init] step 19 (sleep)
[init -> test-init] step 19 (sleep)
[init -> test-init] step 20 (expect_init_state)
[init -> test-init] step 21 (message)
[init -> test-init]
[init -> test-init] --- test changing provided services ---
[init -> test-init] step 22 (init_config)
[init -> test-init] step 23 (sleep)
Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x100 Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored) [init -> test-init] [init] Error: dummy: LOG environment session denied (ignored) [init -> test-init] step 23 (sleep)
[init -> test-init] step 23 (sleep)
[init -> test-init] step 24 (expect_init_state)
[init -> test-init] step 25 (init_config)
[init -> test-init] step 26 (expect_log)
[init -> test-init] step 27 (expect_log)
[init -> test-init] [init -> log] config 2: providing service (expected)
[init -> test-init] [init] child "log" announces service "LOG" (ignored)
[init -> test-init] [init -> log] created LOG service (ignored)
[init -> test-init] step 28 (init_config)
[init -> test-init] step 29 (sleep)
[init -> test-init] [init -> log] [dummy] started (expected)
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored) Warning: unmapping of managed dataspaces not yet supported
Warning: unmapping of managed dataspaces not yet supported
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
Error: attempt to replenish more quota than withdrawn
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored) [init -> test-init] [init] Error: dummy: LOG environment session denied (ignored) [init -> test-init] step 30 (expect_init_state)
[init -> test-init] step 31 (message)
[init -> test-init]
[init -> test-init] --- update child config ---
[init -> test-init] step 32 (init_config)
[init -> test-init] step 33 (expect_log)
[init -> test-init] [init -> log] config 3: became unavailable (ignored)
no RM attachment (READ pf_addr=0x5f868 pf_ip=0x5f868 from pager_object: pd='init -> init -> log' thread='ep')
On x86_64, run/init occasionally fails with the same "no RM attachment" error, but unlike on Sabre Lite or Wandboard, this error does not occur every time, but if it does, it usually occurs in different places. On my yesterday run, 3 out of 10 trials resulted in "no RM attachment" error.
On Thu, Oct 19, 2017 at 9:20 AM, Martin Stein <martin.stein@...1...> wrote:
Hi Yevgeni, Stefan,
Am 19.10.2017 um 13:05 schrieb Stefan Kalkowski:
And, is it possible to reproduce the USB Armory's "run/tz_vmm" scenario on i.MX6 platform?
This cannot be done out of the box. The most easy part would be to add support to the hw kernel to execute i.MX6 in the secure world, provide the TrustZone specific VM interface to the user-land, and to partition the memory into secure and normal one. The next probably more time-consuming step is the para-virtualization of the i.MX6 specific Linux Kernel that is run as "guest" in the tz_vmm.run scenario.
Let me add that the USB-Armory branch on my Linux fork [1] might serve as template for para-virtualization. The youngest commit adds a para-virtualized block driver and serial driver to a 4.2.3 Linux.
Cheers, Martin
[1] branch https://github.com/m-stein/linux/commits/genode_hw_usb_ armory_tz_vmm
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Yevgeny,
no RM attachment (READ pf_addr=0x5f868 pf_ip=0x5f868 from pager_object: pd='init -> init -> log' thread='ep')
On x86_64, run/init occasionally fails with the same "no RM attachment" error, but unlike on Sabre Lite or Wandboard, this error does not occur every time, but if it does, it usually occurs in different places. On my yesterday run, 3 out of 10 trials resulted in "no RM attachment" error.Â
for the record, I am able to reproduce the problem with the current version on Qemu/x86_64. Unfortunately, I cannot look into it right now.
Regards Norman
Hi Yevgeny,
On 11/08/2017 08:40 AM, Yevgeny Lavrov wrote:
Hi,
Unfortunately, it never gets to the point where it says "Run script execution successful", everything breaks once it reaches step 33 of the init.run script. I've also given a try to Genode/seL4 on Wandboard Quad, but ended up with the same result. Other scripts (except bomb, part_blk and resource_request) ran w/o any problems. Fresh, out of the box copy of Genode 17.08 breaks in the same spot when executed on Wandboard Quad, so I'm including complete serial output to this e-mail for you to take a look.
Another issue with Wandboard Quad that I've encountered is: when compiling Genode with hw kernel, for some reason, I can't observe any output over the serial. Â Â
Hit any key to stop autoboot: 0 => fatload mmc 0 0x30000000 image.elf reading image.elf 1897104 bytes read in 109 ms (16.6 MiB/s) => bootelf 0x30000000 ## Starting application at 0x10001000 ...
Nothing after this point. However, when compiled with seL4 kernel instead of default hw, this problem goes away. Any suggestions on what might be causing it?
Actually, I have no idea why the HW kernel should not work for you. We test it all night, and currently _all_ tests for HW on Wandboard are green. I can confirm the trouble you experience with init.run and bomb.run on top of sel4. I think there exist resource limitations regarding Genode/Sel4 that lead to those problems.
The only difference in between your setup, and our nightly test scenario is that we use u-boot's "uImage" format and the "bootm" command instead of the "bootelf" command, because the latter is not enabled in most pre-installed u-boot variants. You can produce a ready to use uImage when adding the following run-tool option to your "etc/build.conf":
RUN_OPT += --include image/uboot
I should wonder if it makes any difference to boot the uImage instead of the ELF image, but maybe you can give it a try.
Regards Stefan
Serial Output: Fresh copy of Genode 17.08/seL4 on Wandboard Quad
Hit any key to stop autoboot:Â 0Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
=> fatload mmc 0 0x30000000 image.elf                                                                                                            Â
reading image.elf                                                                                                                                Â
2195928 bytes read in 123 ms (17 MiB/s)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
=> bootelf 0x30000000Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
## Starting application at 0x20000000 ...                                                                                                        Â
                                                                                                                                                 Â
ELF-loader started on CPU: ARM Ltd. Cortex-A9 r2p10Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 paddr=[20000000..2020801f]                                                                                                                     Â
ELF-loading image 'kernel'Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 paddr=[10000000..10039fff]                                                                                                                     Â
 vaddr=[e0000000..e0039fff]                                                                                                                     Â
 virt_entry=e0000000                                                                                                                            Â
ELF-loading image 'genode.elf'Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 paddr=[1003a000..10320fff]                                                                                                                     Â
 vaddr=[2000000..22e6fff]                                                                                                                       Â
 virt_entry=2000000                                                                                                                             Â
Enabling MMU and paging                                                                                                                          Â
Jumping to kernel-image entry point...                                                                                                           Â
                                                                                                                                                 Â
Bootstrapping kernel                                                                                                                             Â
Booting all finished, dropped to user space                                                                                                      Â
<<seL4(CPU 0) [decodeCNodeInvocation/106 T0xffe7cd00 "rootserver" @202b124]: CNode Copy/Mint/Move/Mutate: Source slot invalid or empty.>>Â Â Â Â Â Â Â Â Â Warning: copy: seL4_CNode_Copy (0x7) returned 6Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
:phys_mem_16k:Â Â Â Â Allocator 0x21d2058 dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [10000000,10010000) size=64K avail=64K max_avail=448K                                                                                    Â
 Block: [10324000,10394000) size=448K avail=448K max_avail=448K                                                                                  Â
 => mem_size=524288 (0 MB) / mem_avail=524288 (0 MB)                                                                                             Â
                                                                                                                                                 Â
virtual address layout of core:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 overall   [00002000,c0000000)                                                                                                                  Â
 core image [02000000,022e7000)                                                                                                                  Â
 ipc buffer [022e7000,022e8000)                                                                                                                  Â
 boot_info [022e8000,022e9000)                                                                                                                  Â
 stack area [40000000,50000000)                                                                                                                  Â
Warning: need physical memory, but Platform object not constructed yet                                                                           Â
Warning: need physical memory, but Platform object not constructed yet                                                                           Â
:phys_alloc:Â Â Â Â Â Â Allocator 0x219f11c dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [10321000,10324000) size=12K avail=12K max_avail=12K                                                                                     Â
 Block: [10394000,11000000) size=12720K avail=12720K max_avail=425980K                                                                           Â
 Block: [12000000,12001000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [12001000,2c000000) size=425980K avail=425980K max_avail=425980K                                                                         Â
 Block: [2d000000,2d001000) size=4K avail=0 max_avail=425980K                                                                                    Â
 Block: [2d001000,2d002000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2d002000,2e000000) size=16376K avail=16376K max_avail=16376K                                                                            Â
 Block: [2f106000,2f107000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f107000,2f180000) size=484K avail=484K max_avail=484K                                                                                  Â
 Block: [2f200000,2f201000) size=4K avail=0 max_avail=425980K                                                                                    Â
 Block: [2f201000,2f202000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f202000,2f203000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f203000,2f204000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f204000,2f205000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f205000,2f206000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f206000,2f207000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f207000,2f208000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f208000,2f209000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f209000,2f20a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f20a000,2f20b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f20b000,2f20c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f20c000,2f20d000) size=4K avail=0 max_avail=425980K                                                                                    Â
 Block: [2f20d000,2f20e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f20e000,2f20f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f20f000,2f210000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f210000,2f211000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f211000,2f212000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f212000,2f213000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f213000,2f214000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f214000,2f215000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f215000,2f216000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f216000,2f217000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f217000,2f218000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f218000,2f219000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f219000,2f21a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21a000,2f21b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21b000,2f21c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21c000,2f21d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21d000,2f21e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21e000,2f21f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f21f000,2f220000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f220000,2f221000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f221000,2f222000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f222000,2f223000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f223000,2f224000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f224000,2f225000) size=4K avail=0 max_avail=425980K                                                                                    Â
 Block: [2f225000,2f226000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f226000,2f227000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f227000,2f228000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f228000,2f229000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f229000,2f22a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22a000,2f22b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22b000,2f22c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22c000,2f22d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22d000,2f22e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22e000,2f22f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f22f000,2f230000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f230000,2f231000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f231000,2f232000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f232000,2f233000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f233000,2f234000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f234000,2f235000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f235000,2f236000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f236000,2f237000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f237000,2f238000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f238000,2f239000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f239000,2f23a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23a000,2f23b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23b000,2f23c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23c000,2f23d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23d000,2f23e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23e000,2f23f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f23f000,2f240000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f240000,2f241000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f241000,2f242000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f242000,2f243000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f243000,2f244000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f244000,2f245000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f245000,2f246000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f246000,2f247000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f247000,2f248000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f248000,2f249000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f249000,2f24a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24a000,2f24b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24b000,2f24c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24c000,2f24d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24d000,2f24e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24e000,2f24f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f24f000,2f250000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f250000,2f251000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f251000,2f252000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f252000,2f253000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f253000,2f254000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f254000,2f255000) size=4K avail=0 max_avail=12152K                                                                                     Â
 Block: [2f255000,2f256000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f256000,2f257000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f257000,2f258000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f258000,2f259000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f259000,2f25a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25a000,2f25b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25b000,2f25c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25c000,2f25d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25d000,2f25e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25e000,2f25f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f25f000,2f260000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f260000,2f261000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f261000,2f262000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f262000,2f263000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f263000,2f264000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f264000,2f265000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f265000,2f266000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f266000,2f267000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f267000,2f268000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f268000,2f269000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f269000,2f26a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f26a000,2f26b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f26b000,2f26c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f26c000,2f26d000) size=4K avail=0 max_avail=12152K                                                                                     Â
 Block: [2f26d000,2f26e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f26e000,2f26f000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f26f000,2f270000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f270000,2f271000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f271000,2f272000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f272000,2f273000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f273000,2f274000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f274000,2f275000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f275000,2f276000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f276000,2f277000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f277000,2f278000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f278000,2f279000) size=4K avail=0 max_avail=12152K                                                                                     Â
 Block: [2f279000,2f27a000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f27a000,2f27b000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f27b000,2f27c000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f27c000,2f27d000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f27d000,2f27e000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f27e000,2f27f000) size=4K avail=0 max_avail=12152K                                                                                     Â
 Block: [2f27f000,2f280000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f280000,2f281000) size=4K avail=0 max_avail=12152K                                                                                     Â
 Block: [2f281000,2f282000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [2f282000,2fe60000) size=12152K avail=12152K max_avail=12152K                                                                            Â
 Block: [2fe70000,2fe7c000) size=48K avail=48K max_avail=48K                                                                                     Â
 => mem_size=479547392 (457 MB) / mem_avail=478998528 (456 MB)                                                                                   Â
                                                                                                                                                 Â
:unused_phys_alloc:Allocator 0x21a45dc dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [00104000,00110000) size=48K avail=48K max_avail=48K                                                                                     Â
 Block: [00118000,00120000) size=32K avail=32K max_avail=48K                                                                                     Â
 Block: [00129000,00130000) size=28K avail=28K max_avail=784K                                                                                    Â
 Block: [0013c000,00200000) size=784K avail=784K max_avail=784K                                                                                  Â
 Block: [00400000,00800000) size=4M avail=4M max_avail=4M                                                                                        Â
 Block: [00a00000,00b00000) size=1M avail=1M max_avail=1M                                                                                        Â
 Block: [00d00000,01000000) size=3M avail=3M max_avail=3M                                                                                        Â
 Block: [01f00000,01ffc000) size=1008K avail=1008K max_avail=1008K                                                                               Â
 Block: [02000000,02004000) size=16K avail=16K max_avail=4M                                                                                      Â
 Block: [0201c000,02020000) size=16K avail=16K max_avail=16K                                                                                     Â
 Block: [02038000,0203c000) size=16K avail=16K max_avail=16K                                                                                     Â
 Block: [020cb000,020cc000) size=4K avail=4K max_avail=4K                                                                                        Â
 Block: [020dd000,020e0000) size=12K avail=12K max_avail=192K                                                                                    Â
 Block: [020f0000,02100000) size=64K avail=64K max_avail=64K                                                                                     Â
 Block: [02110000,02140000) size=192K avail=192K max_avail=192K                                                                                  Â
 Block: [02145000,0214f000) size=40K avail=40K max_avail=40K                                                                                     Â
 Block: [02161000,0217c000) size=108K avail=108K max_avail=3409424K                                                                              Â
 Block: [02180000,02184000) size=16K avail=16K max_avail=16K                                                                                     Â
 Block: [021c4000,021d0000) size=48K avail=48K max_avail=48K                                                                                     Â
 Block: [021f8000,02200000) size=32K avail=32K max_avail=32K                                                                                     Â
 Block: [0220c000,02400000) size=2000K avail=2000K max_avail=212M                                                                                Â
 Block: [02c00000,10000000) size=212M avail=212M max_avail=212M                                                                                  Â
 Block: [10010000,10321000) size=3140K avail=3140K max_avail=212M                                                                                Â
 Block: [11000000,12000000) size=16M avail=16M max_avail=16M                                                                                     Â
 Block: [2c000000,2d000000) size=16M avail=16M max_avail=3409424K                                                                                Â
 Block: [2e000000,2f106000) size=17432K avail=17432K max_avail=17432K                                                                            Â
 Block: [2f180000,2f200000) size=512K avail=512K max_avail=3409424K                                                                              Â
 Block: [2fe60000,2fe70000) size=64K avail=64K max_avail=3409424K                                                                                Â
 Block: [2fe7c000,ffffffff] size=3409424K avail=3409424K max_avail=3409424K                                                                      Â
 => mem_size=3781718016 (3606 MB) / mem_avail=3781718016 (3606 MB)                                                                               Â
                                                                                                                                                 Â
:unused_virt_alloc:Allocator 0x21a5648 dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [00002000,02000000) size=32760K avail=32760K max_avail=32760K                                                                            Â
 Block: [022e9000,042e9000) size=32M avail=0 max_avail=0                                                                                         Â
 Block: [042e9000,40000000) size=980060K avail=980060K max_avail=1792M                                                                           Â
 Block: [50000000,c0000000) size=1792M avail=1792M max_avail=1792M                                                                               Â
 => mem_size=2949730304 (2813 MB) / mem_avail=2916175872 (2781 MB)                                                                               Â
                                                                                                                                                 Â
:virt_alloc:Â Â Â Â Â Â Allocator 0x21a0188 dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [021d8000,021d9000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [021d9000,021da000) size=4K avail=0 max_avail=0                                                                                          Â
 Block: [021da000,022e7000) size=1076K avail=1076K max_avail=32M                                                                                 Â
 Block: [022e9000,042e9000) size=32M avail=32M max_avail=32M                                                                                     Â
 => mem_size=34664448 (33 MB) / mem_avail=34656256 (33 MB)                                                                                       Â
                                                                                                                                                 Â
:io_mem_alloc:Â Â Â Â Allocator 0x21a1200 dump:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
 Block: [00100000,00104000) size=16K avail=16K max_avail=16K                                                                                     Â
 Block: [00110000,00118000) size=32K avail=32K max_avail=32K                                                                                     Â
 Block: [00120000,00129000) size=36K avail=36K max_avail=2M                                                                                      Â
 Block: [00130000,0013c000) size=48K avail=48K max_avail=48K                                                                                     Â
 Block: [00200000,00400000) size=2M avail=2M max_avail=2M                                                                                        Â
 Block: [00800000,00a00000) size=2M avail=2M max_avail=2M                                                                                        Â
 Block: [00b00000,00d00000) size=2M avail=2M max_avail=15M                                                                                       Â
 Block: [01000000,01f00000) size=15M avail=15M max_avail=15M                                                                                     Â
 Block: [01ffc000,02000000) size=16K avail=16K max_avail=15M                                                                                     Â
 Block: [02004000,0201c000) size=96K avail=96K max_avail=96K                                                                                     Â
 Block: [02020000,02038000) size=96K avail=96K max_avail=15M                                                                                     Â
 Block: [0203c000,020cb000) size=572K avail=572K max_avail=572K                                                                                  Â
 Block: [020cc000,020dd000) size=68K avail=68K max_avail=572K                                                                                    Â
 Block: [020e0000,020f0000) size=64K avail=64K max_avail=64K                                                                                     Â
 Block: [02100000,02110000) size=64K avail=64K max_avail=15M                                                                                     Â
 Block: [02140000,02145000) size=20K avail=20K max_avail=20K                                                                                     Â
 Block: [0214f000,02161000) size=72K avail=72K max_avail=72K                                                                                     Â
 Block: [0217c000,02180000) size=16K avail=16K max_avail=16K                                                                                     Â
 Block: [02184000,021c4000) size=256K avail=256K max_avail=8M                                                                                    Â
 Block: [021d0000,021f8000) size=160K avail=160K max_avail=160K                                                                                  Â
 Block: [02200000,0220c000) size=48K avail=48K max_avail=8M                                                                                      Â
 Block: [02400000,02c00000) size=8M avail=8M max_avail=8M                                                                                        Â
 => mem_size=32129024 (30 MB) / mem_avail=32129024 (30 MB)                                                                                       Â
                                                                                                                                                 Â
boot module 'ld.lib.so http://ld.lib.so' (562908 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'dummy' (77416 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'report_rom' (73960 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'timer' (68436 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'init' (201760 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'config' (33724 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
boot module 'test-init' (76840 bytes)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: need physical memory, but Platform object not constructed yet                                                                           Â
Genode 17.08-177-g30948a4Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
456 MiB RAM and 31767 caps assigned to init                                                                                                      Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x2Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x4Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init] child "report_rom" announces service "Report"Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init] child "report_rom" announces service "ROM"Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x8Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init] child "timer" announces service "Timer"Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 0 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init] child "test-init" announces service "LOG"Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 0 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 1 (message)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init]Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] --- test state reporting ---Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 2 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 3 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] Error: RAM preservation exceeds available memory (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init] Warning: application: assigned RAM exceeds available RAM (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 3 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 4 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> application] started (expected)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 4 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 5 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 6 (message)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init]Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] --- routing to custom log service ---Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 7 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x20Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 8 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x40Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 8 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] child "server" announces service "LOG" (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> server] created LOG service (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 8 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] child "indirect_server" announces service "LOG" (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init -> server] [indirect_server] created LOG service (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 8 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 9 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> server] [indirect_server] [client] client started (expected)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 9 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> server] [indirect_server] [client] going to create 1 LOG connections (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init -> server] [indirect_server] [client] created all LOG connections (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 9 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 10 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 11 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 12 (message)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init]Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] --- changing route of indirect server ---Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 13 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 14 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] Warning: client: lookup for service "LOG" failed (ignored)                                                             [init -> test-init] [init] Warning: client: lookup for service "LOG" failed (ignored)                                                             Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x80                                   Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
[init -> test-init] [init] child "indirect_server" announces service "LOG" (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 14 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> indirect_server] created LOG service (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 14 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 15 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> indirect_server] [client] client started (expected)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 15 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> indirect_server] [client] going to create 1 LOG connections (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init -> indirect_server] [client] created all LOG connections (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 16 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 17 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 17 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 18 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
[init -> test-init] step 19 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 19 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 20 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 21 (message)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init]Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] --- test changing provided services ---Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 22 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 23 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x100                                  Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init] Error: dummy: LOG environment session denied (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 23 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 23 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 24 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 25 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 26 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 27 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> log] config 2: providing service (expected)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] child "log" announces service "LOG" (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> log] created LOG service (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 28 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 29 (sleep)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> log] [dummy] started (expected)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored)                                                              Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Warning: unmapping of managed dataspaces not yet supported                                                                                       Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
Error: attempt to replenish more quota than withdrawn                                                                                            Â
[init -> test-init] [init] Warning: dummy: lookup for service "LOG" failed (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] [init] Error: dummy: LOG environment session denied (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [init -> test-init] step 30 (expect_init_state)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 31 (message)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init]Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] --- update child config ---Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 32 (init_config)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] step 33 (expect_log)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
[init -> test-init] [init -> log] config 3: became unavailable (ignored)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
no RM attachment (READ pf_addr=0x5f868 pf_ip=0x5f868 from pager_object: pd='init -> init -> log' thread='ep')
On x86_64, run/init occasionally fails with the same "no RM attachment" error, but unlike on Sabre Lite or Wandboard, this error does not occur every time, but if it does, it usually occurs in different places. On my yesterday run, 3 out of 10 trials resulted in "no RM attachment" error.Â
On Thu, Oct 19, 2017 at 9:20 AM, Martin Stein <martin.stein@...1... mailto:martin.stein@...1...> wrote:
Hi Yevgeni, Stefan, Am 19.10.2017 um 13:05 schrieb Stefan Kalkowski: >> And, is it possible to reproduce the USB Armory's "run/tz_vmm" scenario >> on i.MX6 platform? > > This cannot be done out of the box. The most easy part would be to add > support to the hw kernel to execute i.MX6 in the secure world, provide > the TrustZone specific VM interface to the user-land, and to partition > the memory into secure and normal one. The next probably more > time-consuming step is the para-virtualization of the i.MX6 specific > Linux Kernel that is run as "guest" in the tz_vmm.run scenario. Let me add that the USB-Armory branch on my Linux fork [1] might serve as template for para-virtualization. The youngest commit adds a para-virtualized block driver and serial driver to a 4.2.3 Linux. Cheers, Martin [1] branch https://github.com/m-stein/linux/commits/genode_hw_usb_armory_tz_vmm <https://github.com/m-stein/linux/commits/genode_hw_usb_armory_tz_vmm> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main <https://lists.sourceforge.net/lists/listinfo/genode-main>
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Yevgeny, Stefan,
Am 08.11.2017 um 11:29 schrieb Stefan Kalkowski:
Actually, I have no idea why the HW kernel should not work for you. We test it all night, and currently _all_ tests for HW on Wandboard are green. I can confirm the trouble you experience with init.run and bomb.run on top of sel4. I think there exist resource limitations regarding Genode/Sel4 that lead to those problems.
The only difference in between your setup, and our nightly test scenario is that we use u-boot's "uImage" format and the "bootm" command instead of the "bootelf" command, because the latter is not enabled in most pre-installed u-boot variants. You can produce a ready to use uImage when adding the following run-tool option to your "etc/build.conf":
RUN_OPT += --include image/uboot
I should wonder if it makes any difference to boot the uImage instead of the ELF image, but maybe you can give it a try.
Might it be that the u-boot versions differ and therefore the pre-Genode hardware/uart initialization causes troubles with HW?
Martin
Hi Stefan, Martin,
Thank you for your suggestions. Switching from .elf to uImage for Wandboard Quad actually did the trick, and now I can observe serial output. This is interesting, bootelf never failed me before.
On Wed, Nov 8, 2017 at 3:06 PM, Martin Stein <martin.stein@...1...> wrote:
Hi Yevgeny, Stefan,
Am 08.11.2017 um 11:29 schrieb Stefan Kalkowski:
Actually, I have no idea why the HW kernel should not work for you. We test it all night, and currently _all_ tests for HW on Wandboard are green. I can confirm the trouble you experience with init.run and bomb.run on top of sel4. I think there exist resource limitations regarding Genode/Sel4 that lead to those problems.
The only difference in between your setup, and our nightly test scenario is that we use u-boot's "uImage" format and the "bootm" command instead of the "bootelf" command, because the latter is not enabled in most pre-installed u-boot variants. You can produce a ready to use uImage when adding the following run-tool option to your "etc/build.conf":
RUN_OPT += --include image/uboot
I should wonder if it makes any difference to boot the uImage instead of the ELF image, but maybe you can give it a try.
Might it be that the u-boot versions differ and therefore the pre-Genode hardware/uart initialization causes troubles with HW?
Martin
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
On 11/10/2017 12:05 PM, Yevgeny Lavrov wrote:
Hi Stefan, Martin,
Thank you for your suggestions. Switching from .elf to uImage for Wandboard Quad actually did the trick, and now I can observe serial output. This is interesting, bootelf never failed me before.Â
well, that's interesting indeed. Would be interesting to know what the u-boot ELF loader makes different.
But it is good to hear that you can now proceed at least.
On Wed, Nov 8, 2017 at 3:06 PM, Martin Stein <martin.stein@...1... mailto:martin.stein@...1...> wrote:
Hi Yevgeny, Stefan, Am 08.11.2017 um 11:29 schrieb Stefan Kalkowski: > Actually, I have no idea why the HW kernel should not work for you. We > test it all night, and currently _all_ tests for HW on Wandboard are > green. I can confirm the trouble you experience with init.run and > bomb.run on top of sel4. I think there exist resource limitations > regarding Genode/Sel4 that lead to those problems. > > The only difference in between your setup, and our nightly test scenario > is that we use u-boot's "uImage" format and the "bootm" command instead > of the "bootelf" command, because the latter is not enabled in most > pre-installed u-boot variants. You can produce a ready to use uImage > when adding the following run-tool option to your "etc/build.conf": > >Â Â RUN_OPT += --include image/uboot > > I should wonder if it makes any difference to boot the uImage instead of > the ELF image, but maybe you can give it a try. Might it be that the u-boot versions differ and therefore the pre-Genode hardware/uart initialization causes troubles with HW? Martin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net <mailto:genode-main@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/genode-main <https://lists.sourceforge.net/lists/listinfo/genode-main>
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
unknown＠example.com -
Alexander Boettcher -
Christian Helmuth -
Hinnerk van Bruinehsen -
Martin Stein -
Norman Feske -
Stefan Kalkowski -
Yevgeny Lavrov