Genode on i.MX6 (eMMC Flash)

Fri Apr 21 11:00:59 CEST 2017

Hi Kranthi,

On 04/20/2017 01:15 PM, Kranthi Tej 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 just wanted to add: You cannot print a message within bootstrap after
enabling the MMU until the core component is started. Due to the fact,
that the serial log console for bootstrap is initialized using the
physical address of the UART's I/O registers, because bootstrap is first
running with disabled MMU. When the MMU is enabled there are no 1:1
mappings of the UART's I/O registers, but they are somewhere above
0xf0000000. Within the core component the serial log console is
initialized using the correct virtual memory address of the UART's I/O
registers, that is why you can print log messages again in core.

I wonder if you have made any other changes. Can you please verify to
change the values of RAM and UART in the board_base.h file only? So we
can be sure to not hunt some other artifact?

regards
Stefan

> 
>     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 ldrr5, [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 <http://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
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/