Genode on i.MX6 (eMMC Flash)

Mon May 1 13:33:33 CEST 2017

Hello Martin & Stefan,

We've been working on this issue. The pagefault occurs at ip = 0x200374f4.
I've referred to the objdump output corresponding to this ip. The following
is the corresponding 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]

When we looked into the LDR documentation in the ARM Infocenter, we've
discovered that the possible way of getting an error with the LDR command
is when the literal pool is not within the range of the LDR instruction.
The solution to this problem is given to be adding "LTORG" directive in the
assembly code before the problematic instruction.

However, in our case, the assembly file is being generated by higher level
code. We are not able to comprehend as to how we can add a literal pool in
the image being generated. Can you give us any pointers on what
modifications could be made and where?

Thanks in advance,
Kranthi

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/20170501/c2897dfa/attachment.html>