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:
 
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