Genode on i.MX6 (eMMC Flash)
ee13b037 at ...484...
Mon Apr 24 13:53:03 CEST 2017
Following up on my previous email, I've looked into the creation of build
directory part (since, we build a build directory for wand_quad but we are
using a SabreSD board). I have observed a hierarchy in the ".mk" files
which have been included. The Makefile in the build directory has a
reference to . There is a repository included by the
address repos/base/include/spec/wand_quad. I could not find this folder,
Would it be something to worry about?
Also, I've forgotten to mention that I had changed the NR_OF_CPUS value to
1 in repos/base-hw/lib/mk/spec/imx6/*.mk files (Thanks to Stefan's mail on
another thread). I've also tried keeping the NR_OF_CPUS to be 4. But, in
that case, it seems to hang at "Starting kernel ..." itself.
As an experiment, I've also tried to replace SRC_MMIO_BASE value with
MMIO_BASE value in . The result is still the same. It is stuck at page
Is the offset in the memory addresses (that I have mentioned in my previous
email) when compared to the output mentioned in
https://sourceforge.net/p/genode/mailman/message/35743536/ a source of the
problem? If it can be a problem, how do I go about resolving it.
I've been unable to move forward. Kindly help me with this. Your help will
be greatly appreciated.
Thanks in advance,
On Thu, Apr 20, 2017 at 4:45 PM, Kranthi Tej <ee13b037 at ...484...>
> Hello Martin,
> Thank you for the response.
>> Most likely it's not a problem with the write function but with the
>> hardware implications of this specific write. This is the point where
>> memory-management unit and caches are switched on for the first time
>> implicitely moving execution from the physical to a virtual address
>> space. As the Kernel has no pager, this means that the page table behind
>> the virtual address space must already contain all stuff that is
>> essential to the Kernel (and the Core main/pager functionality).
> You were right about the write function. It was not the problem. I had
> accidentally placed a log message before the init_log() service was started
> in the repos/base-hw/src/bootstrap/init.cc file. That is why I couldn't
> reach the "kernel initialized" part in Genode 17.02.
>> I would lookup the pagefault IP denoted in the pagefault message first
>> using 'genode-arm-objdump -DCl <BUILD_DIR>/var/run/<RUN_NAME>.core'.
> I've taken the objdump of the file as you have suggested. The pagefault
> occurs at ip=0x200374f4. I've checked the corresponding line in the objdump
> output. It seems to correspond to a part of the prepare_init_main_thread
> function in . This is the line:
> 200374f4: e7975003 ldr r5, [r7, r3]
> I've also uploaded the objdump output at:
> https://drive.google.com/open?id=0B0jItjAniGQxR2FmWURsT1BZS0U (for
>> This should give you a hint what is missing in your page table. The MMIO
>> regions to be included in the early page table are defined in .
> I've referred to the file you've suggested. I've stumbled upon variables
> which seem to have been defined in . These are the values I'm currently
> /* normal RAM */
> RAM0_BASE = 0x10000000,
> RAM0_SIZE = 0x20000000,
> UART_1_IRQ = 58,
> UART_1_MMIO_BASE = 0x02020000,
> UART_1_MMIO_SIZE = 0x00004000,
> /* CPU */
> CORTEX_A9_PRIVATE_MEM_BASE = 0x00a00000,
> CORTEX_A9_PRIVATE_MEM_SIZE = 0x00002000,
> CORTEX_A9_PRIVATE_TIMER_CLK = 395037500,
> CORTEX_A9_PRIVATE_TIMER_DIV = 170,
> /* L2 cache controller */
> PL310_MMIO_BASE = 0x00a02000,
> PL310_MMIO_SIZE = 0x00001000,
>> It might help if you post the whole serial output of your test.
> The following is the serial output of my test. I've used "log" image
> instead of using "demo":
> MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage
> Loading file "uImage" from mmc device 3:1 (xxd1)
> 593794 bytes read
> MX6Q SABRESD U-Boot > bootm 0x30000000
> ## Booting kernel from Legacy Image at 30000000 ...
> Image Name:
> Image Type: ARM Linux Kernel Image (gzip compressed)
> Data Size: 593730 Bytes = 579.8 kB
> Load Address: 10001000
> Entry Point: 10001000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Starting kernel ...
> :virt_alloc: Allocator 0x200c40b4 dump:
> Block: [0x1000,0x10001000] size=0x10000000 avail=0x10000000
> Block: [0x1057d000,0x20001000] size=0xfa84000 avail=0xfa84000
> Block: [0x20174000,0x20175000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x20175000,0xe0000000] size=0xbfe8b000 avail=0xbfe8b000
> Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0 max_avail=0xbfe8b000
> 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
> => mem_size=4019159040 (3832 MB) / mem_avail=4019142656 (3832 MB)
> :phys_alloc: Allocator 0x200c3048 dump:
> Block: [0x105bf000,0x105c0000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x105c0000,0x105c1000] size=0x1000 avail=0x0 max_avail=0x1fa3d000
> Block: [0x105c1000,0x105c2000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x105c2000,0x105c3000] size=0x1000 avail=0x0 max_avail=0x1fa3d000
> Block: [0x105c3000,0x30000000] size=0x1fa3d000 avail=0x1fa3d000
> => mem_size=530845696 (506 MB) / mem_avail=530829312 (506 MB)
> :io_mem_alloc: Allocator 0x200c512c dump:
> Block: [0x0,0x105bf000] size=0x105bf000 avail=0x105bf000
> Block: [0x30000000,0xffffffff] size=0xcfffffff avail=0xcfffffff
> => mem_size=3764121599 (3589 MB) / mem_avail=3764121599 (3589 MB)
> :io_port_alloc: Allocator 0x200c6198 dump:
> => mem_size=0 (0 MB) / mem_avail=0 (0 MB)
> :irq_alloc: Allocator 0x200c7204 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: [10176000,10176158) config
> ROM: [10152000,10172178) init
> ROM: [100d5000,101519a4) ld.lib.so
> ROM: [10173000,10175598) test-log
> kernel initialized
> Error: page fault in core thread (core): ip=0x200374f4 fault=0x4ce79f8
> I've observed that all my address ranges (except phys_alloc) in the serial
> output have a negative offset of 0x30000 to the output mentioned in this:
> https://sourceforge.net/p/genode/mailman/message/35743536/ (which seems
> to be working).
> However, the phys_alloc address range has a negative offset of 0x60000.
> Can you give me your insights on this? Could it be a source of the problem?
> If yes, how can I go about resolving it?
> Thanks in advance,
>  repos/base-hw/src/lib/base/thread_bootstrap.cc
>  repos/base/include/spec/imx6/drivers/board_base.h
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users