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