Genode on i.MX6 (eMMC Flash)

Mon Apr 24 13:53:03 CEST 2017

Hello Martin,

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 [1]. 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 [2]. The result is still the same. It is stuck at page
fault.

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,
Kranthi

[1] repos/base/mk/spec/wand_quad.mk
[2] repos/base/include/spec/imx6/drivers/board_base.h

On Thu, Apr 20, 2017 at 4:45 PM, Kranthi Tej <ee13b037 at ...484...>
wrote:

> 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 [1]. This is the line:
>
> _ZN6Genode17Native_capabilityaSERKS0_():
> /home/kranthitej/Desktop/BTP/BTP_Latest/genode-master/
> repos/base/include/base/native_capability.h:93
> 200374f4: e7975003  ldr r5, [r7, r3]
>
> I've also uploaded the objdump output at:
> https://drive.google.com/open?id=0B0jItjAniGQxR2FmWURsT1BZS0U (for
> reference)
>
>
>> 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 [1].
>>
>
> I've referred to the file you've suggested. I've stumbled upon variables
> which seem to have been defined in [2]. These are the values I'm currently
> using:
>
> /* 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
> max_avail=0x10000000
>  Block: [0x1057d000,0x20001000] size=0xfa84000 avail=0xfa84000
> max_avail=0xbfe8b000
>  Block: [0x20174000,0x20175000] size=0x1000 avail=0x0 max_avail=0x0
>  Block: [0x20175000,0xe0000000] size=0xbfe8b000 avail=0xbfe8b000
> max_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
> max_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
> max_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
> max_avail=0xcfffffff
>  Block: [0x30000000,0xffffffff] size=0xcfffffff avail=0xcfffffff
> max_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?
>
>
>> Cheers,
>> Martin
>
>
> Thanks in advance,
> Kranthi
>
> [1] repos/base-hw/src/lib/base/thread_bootstrap.cc
> [2] repos/base/include/spec/imx6/drivers/board_base.h
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20170424/d553bd75/attachment.html>