Hello
Is there anything from Genode that I can try on i.MX6Q Sabre Lite development board? So far I've already attempted *log* image that I've obtained from compiling Genode for i.MX6 based Wandboard. The fastboot option that gets executed after *$ make run/log *resulted in nothing, so I've also tried to copy the created images onto SD Card and run them directly on the board.
Steps: Once in u-boot prompt
=> fatload mmc 0 0x30000000 image.elf reading image.elf
1716880 bytes read in 107 ms (15.3 MiB/s) => bootelf 0x30000000 ## Starting application at 0x10001000 ...
Then the terminal hangs w/o any output.
Same thing happens when executing uImage => fatload mmc 0 0x30000000 uImage reading uImage 594679 bytes read in 48 ms (11.8 MiB/s) => bootm 0x30000000
Terminal hangs once it reaches: Starting kernel ...
Any suggestions on what's wrong?
Thank you
Hi,
well, just because both boards Wandboard and i.MX 6Q Sabre Lite are using the same system-on-chip (SoC) does not mean they are identical. So if you are hesitant to start instrumenting the startup code, e.g., via additional log() calls, you can at least compare the high level description of the boards. One main issue is which memory slots are used by which board, and which UART within the SoC is used for the serial line connector of the board.
One thing that was striking me first when looking at high-level description of the Sabre Lite board is that is has just 1 GB of RAM, whereby the Wandboard has 2 GB. This is obviously an issue. When lowering the RAM size for your setup you potentially will get one step ahead. But if they are using different UARTs you will not see any log message anyway. In that case you have to check whether both boards use the same UART.
Regards Stefan
On 03/01/2017 08:28 PM, Yevgeny Lavrov wrote:
Hi
Thanks for the hint. You're correct about the UART, they are different. Wand uses UART1 = 0x02020000 while Sabre Lite uses UART2 which is 0x021e800. I tried Genode 15.02 from the institute of Madras: https://github.com/iitmadras/genode/tree/hw_sabrelite_tz_support, simple run/printf for now, and it works. I currently use it as a reference. After comparing board_base.h files for i.MX6 platform, I noticed that specifically for Sabre Lite the values in the board_base.h from Madras are set to:
UART_1_IRQ = 57, UART_1_MMIO_BASE = 0x021e8000,
while for Wandboard, they are the same as in Genode 17.02.
I don't think that adjusting UART will be as simple as copying these values over to Genode 17.02 /repos/base/include/spec/imx6/drivers/board_base.h So if there are any other files involved, would you please tell me what those files are so I know exactly what to look for?
How would I lower the RAM size for my build, and what files are involved?
Thank you
On Thu, Mar 2, 2017 at 4:53 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 03/22/2017 08:14 AM, Yevgeny Lavrov wrote:
well, if you just want to adjust the code to replace the Wandboard definitions with your i.MX 6Q Sabre Lite, it is actually that simple. You only have to change the settings in above mentioned file with in the 17.02 release.
If you want to add support of your board beside of the Wandboard support, you will have to insert a new layer of board definition. But being in your position I would first change the current Wandboard settings to see whether it works in general.
How would I lower the RAM size for my build, and what files are involved?
It is the very same file. You have to change the value of RAM0_SIZE.
Regards Stefan
I've made the necessary changes to UART variables, and lowered the amount of RAM by making RAM0_SIZE = 0x20000000. After executing the image.elf on Sabre Lite, I got the following output:
## Starting application at 0x10001000 ...
:virt_alloc: Allocator 0x200f40b4 dump:
Block: [0x1000,0x10001000] size=0x10000000 avail=0x10000000 max_avail=0x10000000
Block: [0x105ad000,0x20001000] size=0xfa54000 avail=0xfa54000 max_avail=0xbfe5b000
Block: [0x201a4000,0x201a5000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x201a5000,0xe0000000] size=0xbfe5b000 avail=0xbfe5b000 max_avail=0xbfe5b000
Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0 max_avail=0xbfe5b000
Block: [0xf0007000,0xf0008000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0xf0009000,0xf000a000] size=0x1000 avail=0x0 max_avail=0xffe5000
Block: [0xf000a000,0xfffef000] size=0xffe5000 avail=0xffe5000 max_avail=0xffe5000
=> mem_size=4018765824 (3832 MB) / mem_avail=4018749440 (3832 MB)
:phys_alloc: Allocator 0x200f3048 dump:
Block: [0x1061f000,0x10620000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x10620000,0x10621000] size=0x1000 avail=0x0 max_avail=0x1f9dd000
Block: [0x10621000,0x10622000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x10622000,0x10623000] size=0x1000 avail=0x0 max_avail=0x1f9dd000
Block: [0x10623000,0x30000000] size=0x1f9dd000 avail=0x1f9dd000 max_avail=0x1f9dd000
=> mem_size=530452480 (505 MB) / mem_avail=530436096 (505 MB)
:io_mem_alloc: Allocator 0x200f512c dump:
Block: [0x0,0x1061f000] size=0x1061f000 avail=0x1061f000 max_avail=0xcfffffff
Block: [0x30000000,0xffffffff] size=0xcfffffff avail=0xcfffffff max_avail=0xcfffffff
=> mem_size=3764514815 (3590 MB) / mem_avail=3764514815 (3590 MB)
:io_port_alloc: Allocator 0x200f6198 dump:
=> mem_size=0 (0 MB) / mem_avail=0 (0 MB)
:irq_alloc: Allocator 0x200f7204 dump:
Block: [0x0,0x1] size=0x1 avail=0x1 max_avail=0x1
Block: [0x2,0x1d] size=0x1b avail=0x1b max_avail=0x3e2
Block: [0x1e,0x400] size=0x3e2 avail=0x3e2 max_avail=0x3e2
=> mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)
:rom_fs: ROM modules:
ROM: [101a6000,101a6158) config
ROM: [10182000,101a2178) init
ROM: [10105000,101819a4) ld.lib.so
ROM: [101a3000,101a5598) test-log
kernel initialized
Genode 17.02
504 MiB RAM assigned to init
[init -> test-log] hex range: [0e00,1680)
[init -> test-log] empty hex range: [0abc0000,0abc0000) (empty!)
[init -> test-log] hex range to limit: [f8,ff]
[init -> test-log] invalid hex range: [f8,08) (overflow!)
[init -> test-log] negative hex char: 0xfe
[init -> test-log] positive hex char: 0x02
[init -> test-log] multiarg string: "parent -> child.7"
[init -> test-log] String(Hex(3)): 0x3
[init -> test-log] Test done.
Is this the desired output from "log"?
Thanks
On Wed, Mar 22, 2017 at 6:56 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 03/23/2017 04:10 AM, Yevgeny Lavrov wrote:
Exactly!
Regards Stefan
Excellent :) Thank you for guiding me through it. Is there anything else in Genode, other than log that I can try on Sabre Lite to make sure that it works? My current goal is to get Genode running on top of seL4 micro kernel on ARM platform. I'm aware that Genode/seL4 support for ARM is scheduled for August 2017, but maybe there's anything that I can start experimenting with now?
Thank you
On Thu, Mar 23, 2017 at 4:15 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 03/27/2017 09:14 AM, Yevgeny Lavrov wrote:
The following run-scripts run successfully each night on the Wandboard, and therefore should succeed on your board too:
affinity blk_cache bomb clipboard cpu_quota cpu_sampler ds_ownership fault_detection fpu fs_log init ldso libc_getenv libc_pipe libc_vfs libc_vfs_block libc_vfs_ext2 libc_vfs_fs libc_vfs_ram moon new_delete nic_loopback noux part_blk pthread ram_fs_chunk reconstructible report_rom resource_request resource_yield rm_fault rom_blk rom_filter rump_ext2 rust sd_card_bench signal sub_rm synced_interface trace util_mmio xml_generator xml_node
However, the only test here that deals with hardware beside the CPU or timer is the sd_card_bench test. There is almost no peripheral device driver support available for Genode on i.MX6 except the SD-card driver. So if you want to run more sophisticated setups including graphics, network, or input you could concentrate on writing or porting related drivers first.
Best regards Stefan
Thank you for providing me this list, Stefan. I ran every single script from this list on my Sabre Lite, and the majority of them succeeded, except the following three: bomb, part_blk, and sd_card_bench. The sd_card_bench gave me the following msg:
[init] child "timer" announces service "Timer" [init -> sd_card_bench] Error: command timed out [init -> sd_card_bench] Error: Send_if_cond command failed [init -> sd_card_bench] Error: Uncaught exception of type 'Sd_card::Host_controller::Detection_failed' [init -> sd_card_bench] Warning: abort called - thread: ep [init] child "sd_card_bench" exited with exit value 1
Can it be caused by the wrong values of SDHC_IRQ and SDHC_MMIO_BASE in imx6/drivers/board_base.h?
Just to make sure. When a test module exits with "exit value 0", does it mean that the test module succeeded, or something else?
And if it is possible, can you please suggest me a starting point for Genode/seL4 on i.MX6? I'm currently going through files in repos/base-sel4 directory and trying to make sense out of it. I'm still quite new to ARM platforms, as well as Genode and seL4 kernel, so I would greatly appreciate any thoughts or ideas of where to begin.
Thank you
Hi Yevgeny,
Am 29.03.2017 um 10:53 schrieb Yevgeny Lavrov:
I don't think that this is the problem. At this point, you have already reset the component (excludes wrong MMIO base) and IRQs are not needed for Send_if_cond (we poll for completion). It's more likely that there's a problem with card initialization. Could you please print out completion state in [1] like...
error("command timed out irqstat: ", read<Irqstat>());
... and send the result? This might give a glue about whats happened.
Just to make sure. When a test module exits with "exit value 0", does it mean that the test module succeeded, or something else?
This depends on the surrounding test environment (eg. the parent component of the test component or the run script that runs the scenario with the test component). If "Init" is the parent, it simply prints out "child X exited with value Y". We sometimes use this in run scripts to determine if a test succeeded, but there's no general heuristic about that.
Unfortunately, I'm not that familiar with base-sel4. Maybe someone else can answer this?
Cheers, Martin
[1] os/src/drivers/sd_card/spec/imx/driver.cc:132
Hi all, I am booting Android on an IMX53 Sabre tablet. The last few lines seen on serial port as android boots up normally and the screen gets suspended due to inactivity is as follows:
Now I wanted to trap external aborts to monitor. In initialization of secure monitor, I do the following:
My monitor vector table looks as follows:
An example exception handler function just prints a statement and looks as follows: In assembly:
In C:
I add this vector table in initialization of secure monitor as follows:
ldr r0, =tz_monitor @ Get address of Monitors vector table mcr p15, 0, r0, c12, c0, 1 @ Write Monitor Vector Address Register
But the external abort as seen with the Android boot previously does not come to the monitor (the print statement doesn't happen). I get the following output on serial now, when booting Android:
Do I need some other setting to trap the abort to monitor mode? Eventually I will set CSU to make peripherals like I2C0/IPU secure and trap and emulate aborts there. But I need to do this first step of directing an abort to a monitor handler function. Can someone please help?
Thanks! Riju
Hi,
On 29.03.2017 15:06, Martin Stein wrote:
Look for any x86 specific configuration/files in base-sel4 and come up with imx6 specific ones, I would guess. E.g. if you search for x86* you find in
repos/base-sel4/lib/mk/spec/x86_32
several files which setup the sel4 kernel for x86 (build the sel4 kernel, sel4 kernel bindings etc.). This must be (probably) also added to
repos/base-sel4/lib/mk/spec/imx6/
(somehow similar as base-hw does).
For example in repos/base-sel4/lib/mk/spec/x86_32/kernel-sel4.mk the seL4 kernel is build for x86_32. Here you have to come up with a kernel-sel4.mk in the imx6 folder which builds the sel4 kernel for imx6/Sabre lite. How this is exactly is done, you have to check the documentation of seL4.
Cheers,
Alex.
Hi,
Thanks for the hints. I managed to solve the sd_card_bench issue. I've tried to print out completion state as Martin suggested by making the following changes to: <genode-dir>/repos/os/src/drivers/sd_card/spec/imx/driver.cc
driver.cc : line 131: error("command timed out irqstat: ", Mmio::read<Irqstat>());
And got the following output during run: “[init -> sd_card_bench] Error: command timed out irqstat: 0” I assumed that Genode is unable to locate the device for some reason, and decided to see if the same approach that worked for the UART would work here as well. Went back to /repos/base/include/spec/imx6/drivers/board_base.h and adjusted the SDHC variables to these values:
/* SD host controller */ SDHC_IRQ = 56, SDHC_MMIO_BASE = 0x02198000,
This did the trick and sd_card_bench successfully executed :)
On seL4 side I got this far: As it was suggested, I took files from base-sel4/lib/mk/spec/x86_32/ modified them, and placed them in newly created imx6 folder. These changes got me from:
checking library dependencies... Library-description file startup-sel4.mk is missing Library-description file syscall-sel4.mk is missing make[2]: *** No rule to make target 'startup-sel4.lib', needed by 'base-sel4-common.lib'. Stop.
to the point where build process hits:
Library core-sel4 COMPILE capability_space.o
The error occurs once the build process hits one of the files within this directory: base-sel4/src/core and these files appear to be Genode specific. I was able to clear out errors that are caused by wrong object types, but I hit dead end once I reach io_port_session_support.c
Since I'm interested in something as basic as Hello World msg for now, do I need all the files from base-sel4/src/core directory or I may exclude some them?
Thanks
On Thu, Mar 30, 2017 at 4:43 AM, Alexander Boettcher < alexander.boettcher@...1...> wrote:
Hi,
On 03.04.2017 04:49, Yevgeny Lavrov wrote:
This did the trick and sd_card_bench successfully executed :)
Good !
io_ports are a speciality on x86, so on ARM you have to skip the io_port* files completely. (On base-hw, which runs x86 and arm, look there into the mk files, where the io_port* files depended on the platform are added or not).
Cheers,
Alex.
Hi,
I have done some testing to get seL4 and Genode boot on an ARM device (AM335x based). I have a branch on github that got into the Genode userland code, but it sadly isn't that up to date (from december 2016). I just broke x86 support for testing purposes (as it is more or less hard coded in Genode's seL4 code).
https://github.com/N8Fear/genode/tree/sel4-am335x
There are a few more things to consider: - my board uses barebox as bootloader (an uboot fork, so I guess much would work for uboot, too) - I also used a somewhat hacked version of seL4's elfloader to get an image, that combines the seL4 kernel and the genode userland to use with uboot. I guess it also may work using the Genode image as initramfs, but I never really tried that. - The branch referenced above does get into the Genode userland, but fails relatively early on due to a cap fault. (You can read the simple_root_task.txt from the documentation directory in base-sel4 - there is a part about GS-relative addressing of a thread-local-storage facility. My guess is, that that's the point were it fails on my branch).
I guess the real question is, considering that Genode+seL4 on ARM is planned for this year, how much work makes sense. Especially because it would really only make sense, if one has a concept to split the code in a way that allows to build seL4 for different architectures at the same time, which essentially means, that the code could be upstreamed. To get that done, likely would required a certain ammount of coordination with upstream...
WKR Hinnerk
On Mon, Apr 03, 2017 at 10:36:48AM +0200, Alexander Boettcher wrote:
Hi,
On 03.04.2017 12:41, Hinnerk van Bruinehsen wrote:
I have done some testing to get seL4 and Genode boot on an ARM device (AM335x based). I have a branch on github that got into the Genode
Nice !
feel invited to open up a feature issue on github and we may discuss and streamline patches in a clean way.
It's right that we plan seL4 and ARM support, but as said on the roadmap website, nothing is set in stone (e.g. because of high prior commissioned contract work which may come in at any point in time). So, I would not bet on this to happen, at least not bet on the schedule ...
Additionally, we would only add support to SoCs we see a need for, have physical access to and therefore may also test. The whole zoo of ARM SoCs can't be managed by GenodeLabs alone. That means specifically, that your desired board may not be part of this line of work.
Why I'm talking about this ? If you have a need for Genode/seL4 and have already something running, please open up a feature issue on github and we will see how we get it upstream. Just waiting for things to happen is the worst thing we can do, community wise.
Cheers,
Alex.
On 04/03/2017 10:49 AM, Martin Stein wrote:
In fact, the i.MX6 SoCs have even four different SDHC controllers. Obviously, the card-slot of the i.MX6Q Sabre Lite is connected to a different controller than the one of the Wandboard.
@m-stein: sorry, I forgot that point when I asked you for support to investigate this
Regards Stefan
Thanks for the support, and thank you Hinnerk for sharing your GitHub branch, so far it was very useful to me when dealing with some errors. I've looked into .mk files from base-hw and yes, the io_port* files only get added to the core-hw.mk if one compiles for x86_64, so I've excluded these files from core-sel4.mk file. After excluding io_port* files, and clearing out seL4 object type related errors (e.g seL4_X86_4K) it got me through compile phase. The compiled image hangs on ## Starting application at 0xe0000000 … which appears to be an invalid address. All my previous apps were starting at 0x10001000. I've assumed that this is because I didn't include platform specific files that can be found in base-hw/src/core/spec and base-hw/src/core/include/spec directories.
Copying spec files from base-hw dir to my base-seL4/src/core/ directory and including them into my build didn't give me anything so far. When attempting to include them into my core-seL4.mk file normally resulted in one or the other file missing or doesn't exist error. But at least it improved my understanding of Genode's make process.
For now I just want to confirm one thing about core-seL4.mk file. Want to make sure that I understand everything correctly. The files that are included through SRC_CC in core-seL4.mk. Not all of them are present in base-seL4/src/core. So, where does it pull the files that are not in base-sel4/src/core? Do they come from repos/base/src/core directory?
On Tue, Apr 4, 2017 at 5:26 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hello Yevgeny
the files are obtained according to the 'vpath' definitions at the end of the core-sel4.mk file. If you want to inspect the build steps in detail, I recommend you to append the "VERBOSE=" argument when invoking make. E.g.,
make core/sel4 VERBOSE=
Cheers Norman
Hi,
I kept experimenting with Genode/seL4 and I ran into the following issue that I can't solve. I have no more problems compiling Genode with seL4 kernel, but my build always ends with a lot of "undefined reference" errors: Ex:
genode build completed using 'ld-sel4.lib.so' as 'ld.lib.so' using 'sel4/core.o' as 'core.o' core/sel4/core.o: In function `error<char const (&)[53], char const (&)[18], void*&, char const (&)[35], void*, char const (&)[2]>': ../genode-17.02/repos/base/include/base/log.h:131: undefined reference to `Genode::Log::log()' core/sel4/core.o: In function `warning<long unsigned int&, char const (&)[21], char const*, char const (&)[31]>': ../genode-17.02/repos/base/include/base/log.h:119: undefined reference to `Genode::Log::log()' core/sel4/core.o: In function `error<char const (&)[19], Genode::Avl_node_base*&, char const (&)[22]>': ../genode-17.02/repos/base/include/base/log.h:131: undefined reference to `Genode::Log::log()' .......
It looks like the linking between Genode & seL4 fails at some point. I think that this is caused by /<genode-dir>/tool/run/boot_dir/sel4 file, so I'm trying to change it so that it looks more like run/boot_dir/hw Am I on the right track, or is there something else that I'm missing?
Thank you
On Mon, Apr 10, 2017 at 2:49 AM, Norman Feske <norman.feske@...1...> wrote:
Hi
Are there any suggestions on what might be causing linking between seL4 and Genode to fail? It fails once it reaches <genode>/tool/run/run: proc build_core {lib modules target link_address} with "undefined reference" errors.
# link final image exec [cross_dev_prefix]g++ {*}$arch -nostdlib {*}[core_ld_opts] \ -Wl,-z -Wl,max-page-size=0x1000 \ -Wl,-Ttext=$link_address -Wl,-gc-sections \ -Wl,-nostdlib -Wl,--whole-archive -Wl,--start-group \ $lib [run_dir].boot_modules.o -Wl,--no-whole-archive \ -Wl,--end-group $libgcc -o $target
Do I need to add bootstrap to my build? The similar way it is done when compiling Genode with hw kernel? I would really appreciate any suggestions or ideas on where to look.
Thank you
On Tue, May 9, 2017 at 7:33 PM, Yevgeny Lavrov <ylavrov13@...9...> wrote:
Hello,
On 16.06.2017 08:39, Yevgeny Lavrov wrote:
Which "undefined references" ? If it is still the Log* methods, see below.
no, bootstrap of hw is a wrong direction. (It's specific for hw and can't be used with any other kernel.)
Log::log, e.g., is implemented in repos/base/src/lib/base/default_log.cc and normally compiled by repos/base-sel4/lib/mk/core-sel4.mk.
It seems that it is missing. 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".
Cheers,
Hi,
well, just because both boards Wandboard and i.MX 6Q Sabre Lite are using the same system-on-chip (SoC) does not mean they are identical. So if you are hesitant to start instrumenting the startup code, e.g., via additional log() calls, you can at least compare the high level description of the boards. One main issue is which memory slots are used by which board, and which UART within the SoC is used for the serial line connector of the board.
One thing that was striking me first when looking at high-level description of the Sabre Lite board is that is has just 1 GB of RAM, whereby the Wandboard has 2 GB. This is obviously an issue. When lowering the RAM size for your setup you potentially will get one step ahead. But if they are using different UARTs you will not see any log message anyway. In that case you have to check whether both boards use the same UART.
Regards Stefan
On 03/01/2017 08:28 PM, Yevgeny Lavrov wrote:
Hi
Thanks for the hint. You're correct about the UART, they are different. Wand uses UART1 = 0x02020000 while Sabre Lite uses UART2 which is 0x021e800. I tried Genode 15.02 from the institute of Madras: https://github.com/iitmadras/genode/tree/hw_sabrelite_tz_support, simple run/printf for now, and it works. I currently use it as a reference. After comparing board_base.h files for i.MX6 platform, I noticed that specifically for Sabre Lite the values in the board_base.h from Madras are set to:
UART_1_IRQ = 57, UART_1_MMIO_BASE = 0x021e8000,
while for Wandboard, they are the same as in Genode 17.02.
I don't think that adjusting UART will be as simple as copying these values over to Genode 17.02 /repos/base/include/spec/imx6/drivers/board_base.h So if there are any other files involved, would you please tell me what those files are so I know exactly what to look for?
How would I lower the RAM size for my build, and what files are involved?
Thank you
On Thu, Mar 2, 2017 at 4:53 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 03/22/2017 08:14 AM, Yevgeny Lavrov wrote:
well, if you just want to adjust the code to replace the Wandboard definitions with your i.MX 6Q Sabre Lite, it is actually that simple. You only have to change the settings in above mentioned file with in the 17.02 release.
If you want to add support of your board beside of the Wandboard support, you will have to insert a new layer of board definition. But being in your position I would first change the current Wandboard settings to see whether it works in general.
How would I lower the RAM size for my build, and what files are involved?
It is the very same file. You have to change the value of RAM0_SIZE.
Regards Stefan
I've made the necessary changes to UART variables, and lowered the amount of RAM by making RAM0_SIZE = 0x20000000. After executing the image.elf on Sabre Lite, I got the following output:
## Starting application at 0x10001000 ...
:virt_alloc: Allocator 0x200f40b4 dump:
Block: [0x1000,0x10001000] size=0x10000000 avail=0x10000000 max_avail=0x10000000
Block: [0x105ad000,0x20001000] size=0xfa54000 avail=0xfa54000 max_avail=0xbfe5b000
Block: [0x201a4000,0x201a5000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x201a5000,0xe0000000] size=0xbfe5b000 avail=0xbfe5b000 max_avail=0xbfe5b000
Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0 max_avail=0xbfe5b000
Block: [0xf0007000,0xf0008000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0xf0009000,0xf000a000] size=0x1000 avail=0x0 max_avail=0xffe5000
Block: [0xf000a000,0xfffef000] size=0xffe5000 avail=0xffe5000 max_avail=0xffe5000
=> mem_size=4018765824 (3832 MB) / mem_avail=4018749440 (3832 MB)
:phys_alloc: Allocator 0x200f3048 dump:
Block: [0x1061f000,0x10620000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x10620000,0x10621000] size=0x1000 avail=0x0 max_avail=0x1f9dd000
Block: [0x10621000,0x10622000] size=0x1000 avail=0x0 max_avail=0x0
Block: [0x10622000,0x10623000] size=0x1000 avail=0x0 max_avail=0x1f9dd000
Block: [0x10623000,0x30000000] size=0x1f9dd000 avail=0x1f9dd000 max_avail=0x1f9dd000
=> mem_size=530452480 (505 MB) / mem_avail=530436096 (505 MB)
:io_mem_alloc: Allocator 0x200f512c dump:
Block: [0x0,0x1061f000] size=0x1061f000 avail=0x1061f000 max_avail=0xcfffffff
Block: [0x30000000,0xffffffff] size=0xcfffffff avail=0xcfffffff max_avail=0xcfffffff
=> mem_size=3764514815 (3590 MB) / mem_avail=3764514815 (3590 MB)
:io_port_alloc: Allocator 0x200f6198 dump:
=> mem_size=0 (0 MB) / mem_avail=0 (0 MB)
:irq_alloc: Allocator 0x200f7204 dump:
Block: [0x0,0x1] size=0x1 avail=0x1 max_avail=0x1
Block: [0x2,0x1d] size=0x1b avail=0x1b max_avail=0x3e2
Block: [0x1e,0x400] size=0x3e2 avail=0x3e2 max_avail=0x3e2
=> mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)
:rom_fs: ROM modules:
ROM: [101a6000,101a6158) config
ROM: [10182000,101a2178) init
ROM: [10105000,101819a4) ld.lib.so
ROM: [101a3000,101a5598) test-log
kernel initialized
Genode 17.02
504 MiB RAM assigned to init
[init -> test-log] hex range: [0e00,1680)
[init -> test-log] empty hex range: [0abc0000,0abc0000) (empty!)
[init -> test-log] hex range to limit: [f8,ff]
[init -> test-log] invalid hex range: [f8,08) (overflow!)
[init -> test-log] negative hex char: 0xfe
[init -> test-log] positive hex char: 0x02
[init -> test-log] multiarg string: "parent -> child.7"
[init -> test-log] String(Hex(3)): 0x3
[init -> test-log] Test done.
Is this the desired output from "log"?
Thanks
On Wed, Mar 22, 2017 at 6:56 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:
Hi,
On 03/23/2017 04:10 AM, Yevgeny Lavrov wrote:
Exactly!
Regards Stefan
Excellent :) Thank you for guiding me through it. Is there anything else in Genode, other than log that I can try on Sabre Lite to make sure that it works? My current goal is to get Genode running on top of seL4 micro kernel on ARM platform. I'm aware that Genode/seL4 support for ARM is scheduled for August 2017, but maybe there's anything that I can start experimenting with now?
Thank you
On Thu, Mar 23, 2017 at 4:15 AM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote: