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@...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