Genode on i.MX6 (eMMC Flash)

Thu Apr 20 13:15:18 CEST 2017

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/20170420/5c94de4d/attachment.html>