Hi,

On 04/06/2017 07:34 AM, Kranthi Tej wrote:

Hello Stefan,

Thank you for the quick response.

Yes, I've been following the parallel thread and I've made the necessary changes in the "/repos/base/include/spec/imx6/drivers/board_base.h" file. I've set the following values:

*UART_1_IRQ = 57, UART_1_MMIO_BASE = 0x021e8000,

*RAM0_SIZE = 0x20000000,*

Your RAM size can be increased to 0x40000000, but obviously it should also work with less.

It turns out I was flashing it the wrong way. I've fixed it by drawing insights from how Android is currently being flashed onto the device. I've followed a similar procedure. After installing the bootloader, I've flashed the Genode uImage (generated using RUN_OPT += --include image/uboot) onto the device as per your advice. Flashing was successfully done. Upon booting up, I got the following:

U-Boot 2009.08-dirty (Jul 08 2016 - 12:21:39)

CPU: Freescale i.MX6 family TO1.5 at 792 MHz Thermal sensor with ratio = 175 Temperature: 37 C, calibration data 0x5534ce69 mx6q pll1: 792MHz mx6q pll2: 528MHz mx6q pll3: 480MHz mx6q pll8: 50MHz ipg clock : 66000000Hz ipg per clock : 66000000Hz uart clock : 80000000Hz cspi clock : 60000000Hz ahb clock : 132000000Hz axi clock : 264000000Hz emi_slow clock: 132000000Hz ddr clock : 528000000Hz usdhc1 clock : 198000000Hz usdhc2 clock : 198000000Hz usdhc3 clock : 198000000Hz usdhc4 clock : 198000000Hz nfc clock : 24000000Hz Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ] Boot Device: MMC

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x1c 0x41 0x33 0x18 0xc0 0x00 0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00 0x00 0x00 0x0d 0x34 0x27 0x80 0x04 0x00 0x00 0x13 0xec 0x00

--------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x00 0x00 0x00 0x00 0x20

--------- HAB Event 3 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x2c 0x00 0x00 0x02 0xa0

--------- HAB Event 4 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x20 0x00 0x00 0x00 0x01

--------- HAB Event 5 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x06 0xe0 0x00 0x00 0x00 0x04 I2C: ready DRAM: 1 GB MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 *** Warning - bad CRC or MMC, using default environment

In: serial Out: serial Err: serial Found PFUZE100! deviceid=10,revid=11 Net: got MAC address from IIM: 00:00:00:00:00:00 FEC0 [PRIME] Hit any key to stop autoboot: 0 booti: bad boot image magic fastboot is in init......flash target is MMC:3 wait usb cable into the connector!

I think you hit some High-Assurance-Boot (HAB) problem here, and the boot procedure therefore resets to some default boot option in this case fastboot over USB.

So, I've tried to write the image at an address and have loaded it from there. I've did the following in the uboot prompt:

MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage Loading file "uImage" from mmc device 3:1 (xxd1) 594591 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: 594527 Bytes = 580.6 kB Load Address: 10001000 Entry Point: 10001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

Starting kernel ...

It stops here (even after adjusting the *UART* settings before building the image). I've also tried *UART1* *(0x02020000)*, *UART3* (*0x021ec000*), *UART4* *(**0x021f0000**)* and *UART5 (**0x021F4000**) *with the same interrupt values.

I've built the uImage for log (make run/log) and demo (make run/demo). I'm facing the same issue.

I'm unable to find the source of the problem. Can you give me any leads on the possible problems?

I'm afraid I have no idea why it should still fail. I know I also successfully booted our system on that SABRE board before, so in principle it should work. Of course, you can put some "log()" message at some very early stage into the bootstrap binary, e.g. at line:

repos/base-hw/src/bootstrap/init.cc:28

If you have a JTAG debugger, you can of course breakpoint at 0x10001000 and single-step to identify the problem.

Regards Stefan

Thanks, Kranthi

On Thu, Apr 6, 2017 at 12:07 AM, Kranthi Tej <ee13b037@...484... mailto:ee13b037@...484...> wrote:

Hello Stefan,

Thank you for the quick response.

Yes, I've been following the parallel thread and I've made the
necessary changes in the
"/repos/base/include/spec/imx6/drivers/board_base.h" file. I've set
the following values:
UART_1_IRQ = 57,
UART_1_MMIO_BASE = 0x021e8000,
RAM0_SIZE = 0x20000000.

It turns out I was flashing it the wrong way. I've fixed it by
drawing insights from how Android is currently being flashed onto
the device. I've followed a similar procedure. After installing the
bootloader, I've flashed the Genode uImage (generated using RUN_OPT
+= --include image/uboot) onto the device as per your advice.
Flashing was successfully done. Upon booting up, I got the following:

U-Boot 2009.08-dirty (Jul 08 2016 - 12:21:39)

CPU: Freescale i.MX6 family TO1.5 at 792 MHz
Thermal sensor with ratio = 175
Temperature:   37 C, calibration data 0x5534ce69
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ]
Boot Device: MMC

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x1c 0x41 0x33 0x18 0xc0 0x00
0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00
0x00 0x00 0x0d 0x34 0x27 0x80 0x04 0x00
0x00 0x13 0xec 0x00

--------- HAB Event 2 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x00
0x00 0x00 0x00 0x20

--------- HAB Event 3 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x2c
0x00 0x00 0x02 0xa0

--------- HAB Event 4 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x20
0x00 0x00 0x00 0x01

--------- HAB Event 5 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x06 0xe0
0x00 0x00 0x00 0x04
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
*** Warning - bad CRC or MMC, using default environment

In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:00:00:00:00:00
FEC0 [PRIME]
Hit any key to stop autoboot:  0 
booti: bad boot image magic
fastboot is in init......flash target is MMC:3
wait usb cable into the connector!

So, I've tried to write the image at an address and have loaded it
from there. I've did the following in the uboot prompt:

MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage
Loading file "uImage" from mmc device 3:1 (xxd1)
594591 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:    594527 Bytes = 580.6 kB
   Load Address: 10001000
   Entry Point:  10001000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

It stops here (even after adjusting the UART settings before
building the image). I'm unable to find the source of the problem.
Can you give me any leads on the possible problems?

Thanks,
Kranthi

On Wed, Mar 29, 2017 at 6:18 PM, Kranthi Tej
<ee13b037@...484... <mailto:ee13b037@...484...>> wrote:

    ---------- Forwarded message ----------
    From: "Stefan Kalkowski" <stefan.kalkowski@...1...
    <mailto:stefan.kalkowski@...1...>>
    Date: Mar 29, 2017 6:03 PM
    Subject: Re: Genode on i.MX6 (eMMC Flash)
    To: "Genode OS Framework Mailing List"
    <genode-main@lists.sourceforge.net
    <mailto:genode-main@lists.sourceforge.net>>
    Cc:

    Hi Kranthi Tej,

    On 03/28/2017 12:30 PM, Kranthi Tej wrote:
    > Hi Stefan,
    >
    > I've tried using the uboot plugin (RUN_OPT += --include
    image/uboot).
    > I've been able to generate a uImage successfully. When I tried
    to flash
    > it on to the board, it stops with following log (was observed in
    > TeraTerm while using the MfgTool):
    >
    > U-Boot 2009.08 (Aug 16 2013 - 14:38:59)
    >
    > CPU: Freescale i.MX6 family TO1.5 at 792 MHz
    > Thermal sensor with ratio = 175
    > Temperature:   42 C, calibration data 0x5524cd69
    > mx6q pll1: 792MHz
    > mx6q pll2: 528MHz
    > mx6q pll3: 480MHz
    > mx6q pll8: 50MHz
    > ipg clock     : 66000000Hz
    > ipg per clock : 66000000Hz
    > uart clock    : 80000000Hz
    > cspi clock    : 60000000Hz
    > ahb clock     : 132000000Hz
    > axi clock   : 264000000Hz
    > emi_slow clock: 132000000Hz
    > ddr clock     : 528000000Hz
    > usdhc1 clock  : 198000000Hz
    > usdhc2 clock  : 198000000Hz
    > usdhc3 clock  : 198000000Hz
    > usdhc4 clock  : 198000000Hz
    > nfc clock     : 24000000Hz
    > Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ]

    As I can see you are using another board with less memory than the
    Wandboard. Did you adapted the memory settings before building the
    Genode image for that board?
    Like it was discussed in this parallel mail thread:


    http://genode-main.narkive.com/nWs1hbc8/genode-on-i-mx6q-sabre-lite
    <http://genode-main.narkive.com/nWs1hbc8/genode-on-i-mx6q-sabre-lite>

    > Boot Device: MMC
    > I2C:   ready
    > DRAM:   1 GB
    > MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
    > Using default environment
    >
    > In:    serial
    > Out:   serial
    > Err:   serial
    > Net:   got MAC address from IIM: 00:00:00:00:00:00
    > FEC0 [PRIME]
    > Hit any key to stop autoboot:  0
    > ## Booting kernel from Legacy Image at 10800000 ...
    >    Image Name:
    >    Image Type:   ARM Linux Kernel Image (gzip compressed)
    >    Data Size:    2075251 Bytes =  2 MB
    >    Load Address: 10001000
    >    Entry Point:  10001000
    >    Verifying Checksum ... OK
    > ## Loading init Ramdisk from Legacy Image at 10c00000 ...
    >    Image Name:   uboot initramfs rootfs
    >    Image Type:   ARM Linux RAMDisk Image (gzip compressed)
    >    Data Size:    4545326 Bytes =  4.3 MB
    >    Load Address: 00000000
    >    Entry Point:  00000000
    >    Verifying Checksum ... OK
    >    Uncompressing Kernel Image ... OK
    >
    > Starting kernel ...
    >
    > Also, I'm using the Android RAMDisk Image. Would that be a
    potential
    > cause for the problem? I've used the following XML script to
    flash the
    > image on to the board (UCL file for MfgTool):

    If you think the Android RAM disk might interfer with your
    Genode image,
    being in your position I would not load it in the first place.

    >
    > <UCL>
    > <CFG>
    > <STATE name="BootStrap" dev="MX6Q" vid="15A2" pid="0054"/>
    > <STATE name="Updater"   dev="MSC" vid="066F" pid="37FF"/>
    > </CFG>
    >
    > <LIST name="SabreSD-eMMC" desc="Choose eMMC as media">
    > <CMD state="BootStrap" type="boot" body="BootStrap" file
    > ="u-boot-mx6q-sabresd.bin" >Loading U-boot</CMD>
    > <CMD state="BootStrap" type="load" file="files/demo/uimage"
    > address="0x10800000"
    >         loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE"
    >>Loading Kernel.</CMD>
    > <CMD state="BootStrap" type="load" file="initramfs.cpio.gz.uboot"
    > address="0x10C00000"
    >         loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE"
    >>Loading Initramfs.</CMD>
    > <CMD state="BootStrap" type="jump" > Jumping to OS image. </CMD>
    > <CMD state="Updater" type="push" body="$ dd if=/dev/zero
    of=/dev/mmcblk0
    > bs=512 seek=1536 count=16">clean up u-boot parameter</CMD>
    > <!--CMD state="Updater" type="push" body="$ echo 1 >
    >
    /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0:0001/boot_config">access
    > boot partition 1</CMD-->
    > <CMD state="Updater" type="push" body="$ echo 0 >
    > /sys/block/mmcblk0boot0/force_ro">access boot partition 1</CMD>
    > <CMD state="Updater" type="push" body="send"
    > file="files/demo/mmc_img">Sending U-Boot</CMD>
    > <CMD state="Updater" type="push" body="$ dd if=$FILE
    of=/dev/mmcblk0
    > bs=512 seek=2 skip=2">write U-Boot to sd card</CMD>
    > <!-- <CMD state="Updater" type="push" body="$ dd if=$FILE
    > of=/dev/mmcblk0p1 bs=1k seek=1 skip=1 conv=fsync">write U-Boot
    to sd
    > card</CMD> -->
    > <CMD state="Updater" type="push" body="$ echo 8 >
    >
    /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0:0001/boot_config">access
    > user partition and enable boot partion 1 to boot</CMD>
    > <CMD state="Updater" type="push" body="send"
    > file="mksdcard-android.sh.tar">Sending partition shell</CMD>
    > <CMD state="Updater" type="push" body="$ tar xf $FILE ">
    > Partitioning...</CMD>
    > <CMD state="Updater" type="push" body="$ sh mksdcard-android.sh
    > /dev/mmcblk0"> Partitioning...</CMD>
    > <CMD state="Updater" type="push" body="$ ls -l /dev/mmc*
    ">Formatting sd
    > partition</CMD>
    > <CMD state="Updater" type="push" body="pipe dd
    of=/dev/mmcblk0p5 bs=512"
    > file="files/demo/demo.img">Sending and writting demo.img</CMD>
    > <CMD state="Updater" type="push" body="frf">Finishing rootfs
    write</CMD>
    > <CMD state="Updater" type="push" body="$ echo Update
    Complete!">Done</CMD>
    > </LIST>
    > </UCL>
    >
    > The script stops executing at "Jumping to OS image". Can you
    give me any
    > leads as to where I'm going wrong?
    >

    As I already told you, I do not have any experiences with that
    tool, but
    you probably encounter the same problems like when using the
    uImage above.

    > Note: I've generated the "mmc_img" file using the
    "create_uboot" tool
    > provided in the genode tools.

    I see. In contrast to the run-tool, which produces either a disk
    image
    or uImage, this utility creates a disk image with the u-boot binary
    only. I'm not sure whether you can use the same u-boot binary in
    between
    Wandboard and your board, probably not!

    We do not have a combination tool that combines u-boot and
    system image
    to provide one final disk image to you.

    Best regards
    Stefan

    --
    Stefan Kalkowski
    Genode Labs

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

    ------------------------------------------------------------------------------
    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@lists.sourceforge.net
    <mailto:genode-main@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/genode-main
    <https://lists.sourceforge.net/lists/listinfo/genode-main>

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello,

Following up on the previous email, I've stumbled upon something while debugging. I've debugged the enable_mmu_and_caches function line by line. I've discovered that the lines which involved the address worked fine. It stops at:

Sctlr::enable_mmu_and_caches();

(repos/base-hw/src/core/include/spec/arm/cpu_support.h:509)

I've debugged (placed log messages after every line) the function further and observed that the problem is with

Sctlr::write(v) function

(repos/base-hw/src/core/include/spec/arm/cpu_support.h:111)

I've looked into the write function. But, I haven't been able to pinpoint what was going wrong. Could it be a problem with the function? Or, could it be a problem with the value being passed to it? (I haven't been completely able to tell that the problem isn't with the address. It could still be a problem.)

I've also tried using the images built by Genode - 15.02 and 16.05. It stops with a "Pagefault in core thread" message after "kernel initialized".

Could you please give me any pointers to go forward? I'm stuck here. Your help will be greatly appreciated.

Note: I've printed the value of core_pd->table base. It is 104a8000.

Thanks in advance, Kranthi

On Wed, Apr 12, 2017 at 5:34 PM, Kranthi Tej <ee13b037@...484...> wrote:

Hello Stefan,

Thank you for the hint.

As per your advice, I've placed log messages in the repos/base-hw/src/ bootstrap/init.cc file. Some of the log messages were printed. Based on this, I've been successfully able to establish that there is no problem with the load address as well as the UART port address. I've been able to progress further with your help. I have placed a log message just before

platform().enable_mmu();

in the repos/base-hw/src/bootstrap/init.cc file. It seems to print the message. I've also placed a log message after this as well. It doesn't get printed. I've looked into the enable_mmu() function. I've identified that it stops at:

cpu.enable_mmu_and_caches((Genode::addr_t)core_pd->table_base);

(repos/base-hw/src/bootstrap/spec/cortex_a9/platform.cc:142)

I've been unable to find out if the problem lies with core_pd or table_base. Could it be a possibility that the core_pd variable has been wrongly initialized? I haven't been able to figure out where the "core_pd" variable is being initialized. If anyone else has had a similar problem, could you please advise about how to go through with it?

I've checked the UART, SDHC, EPIT2, AIPS1, AIPS2, CORTEX_A9_PRIVATE_MEM, PL310, SRC base addresses with it's android counterpart (which is working on the board). All the addresses are the same.

Kindly help me with this.

Note: Unfortunately, I do not have a JTAG debugger.

Thanks in advance, Kranthi

On Tue, Apr 11, 2017 at 1:55 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:

...

Hi,

On 04/06/2017 07:34 AM, Kranthi Tej wrote:

...

Hello Stefan,

Thank you for the quick response.

Yes, I've been following the parallel thread and I've made the necessary changes in the "/repos/base/include/spec/imx6/drivers/board_base.h" file. I've set the following values:

*UART_1_IRQ = 57, UART_1_MMIO_BASE = 0x021e8000,

*RAM0_SIZE = 0x20000000,*

Your RAM size can be increased to 0x40000000, but obviously it should also work with less.

...

It turns out I was flashing it the wrong way. I've fixed it by drawing insights from how Android is currently being flashed onto the device. I've followed a similar procedure. After installing the bootloader, I've flashed the Genode uImage (generated using RUN_OPT += --include image/uboot) onto the device as per your advice. Flashing was successfully done. Upon booting up, I got the following:

U-Boot 2009.08-dirty (Jul 08 2016 - 12:21:39)

CPU: Freescale i.MX6 family TO1.5 at 792 MHz Thermal sensor with ratio = 175 Temperature: 37 C, calibration data 0x5534ce69 mx6q pll1: 792MHz mx6q pll2: 528MHz mx6q pll3: 480MHz mx6q pll8: 50MHz ipg clock : 66000000Hz ipg per clock : 66000000Hz uart clock : 80000000Hz cspi clock : 60000000Hz ahb clock : 132000000Hz axi clock : 264000000Hz emi_slow clock: 132000000Hz ddr clock : 528000000Hz usdhc1 clock : 198000000Hz usdhc2 clock : 198000000Hz usdhc3 clock : 198000000Hz usdhc4 clock : 198000000Hz nfc clock : 24000000Hz Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ] Boot Device: MMC

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x1c 0x41 0x33 0x18 0xc0 0x00 0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00 0x00 0x00 0x0d 0x34 0x27 0x80 0x04 0x00 0x00 0x13 0xec 0x00

--------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x00 0x00 0x00 0x00 0x20

--------- HAB Event 3 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x2c 0x00 0x00 0x02 0xa0

--------- HAB Event 4 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x20 0x00 0x00 0x00 0x01

--------- HAB Event 5 ----------------- event data: 0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x27 0x80 0x06 0xe0 0x00 0x00 0x00 0x04 I2C: ready DRAM: 1 GB MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 *** Warning - bad CRC or MMC, using default environment

In: serial Out: serial Err: serial Found PFUZE100! deviceid=10,revid=11 Net: got MAC address from IIM: 00:00:00:00:00:00 FEC0 [PRIME] Hit any key to stop autoboot: 0 booti: bad boot image magic fastboot is in init......flash target is MMC:3 wait usb cable into the connector!

I think you hit some High-Assurance-Boot (HAB) problem here, and the boot procedure therefore resets to some default boot option in this case fastboot over USB.

...

So, I've tried to write the image at an address and have loaded it from there. I've did the following in the uboot prompt:

MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage Loading file "uImage" from mmc device 3:1 (xxd1) 594591 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: 594527 Bytes = 580.6 kB Load Address: 10001000 Entry Point: 10001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

Starting kernel ...

It stops here (even after adjusting the *UART* settings before building the image). I've also tried *UART1* *(0x02020000)*, *UART3* (*0x021ec000*), *UART4* *(**0x021f0000**)* and *UART5 (**0x021F4000**) *with the same interrupt values.

I've built the uImage for log (make run/log) and demo (make run/demo). I'm facing the same issue.

I'm unable to find the source of the problem. Can you give me any leads on the possible problems?

I'm afraid I have no idea why it should still fail. I know I also successfully booted our system on that SABRE board before, so in principle it should work. Of course, you can put some "log()" message at some very early stage into the bootstrap binary, e.g. at line:

repos/base-hw/src/bootstrap/init.cc:28

If you have a JTAG debugger, you can of course breakpoint at 0x10001000 and single-step to identify the problem.

Regards Stefan

...

Thanks, Kranthi

On Thu, Apr 6, 2017 at 12:07 AM, Kranthi Tej <ee13b037@...484... mailto:ee13b037@...484...> wrote:

Hello Stefan,

Thank you for the quick response.

Yes, I've been following the parallel thread and I've made the
necessary changes in the
"/repos/base/include/spec/imx6/drivers/board_base.h" file. I've set
the following values:
UART_1_IRQ = 57,
UART_1_MMIO_BASE = 0x021e8000,
RAM0_SIZE = 0x20000000.

It turns out I was flashing it the wrong way. I've fixed it by
drawing insights from how Android is currently being flashed onto
the device. I've followed a similar procedure. After installing the
bootloader, I've flashed the Genode uImage (generated using RUN_OPT
+= --include image/uboot) onto the device as per your advice.
Flashing was successfully done. Upon booting up, I got the

following:

...

U-Boot 2009.08-dirty (Jul 08 2016 - 12:21:39)

CPU: Freescale i.MX6 family TO1.5 at 792 MHz
Thermal sensor with ratio = 175
Temperature:   37 C, calibration data 0x5534ce69
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock     : 66000000Hz
ipg per clock : 66000000Hz
uart clock    : 80000000Hz
cspi clock    : 60000000Hz
ahb clock     : 132000000Hz
axi clock   : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock     : 528000000Hz
usdhc1 clock  : 198000000Hz
usdhc2 clock  : 198000000Hz
usdhc3 clock  : 198000000Hz
usdhc4 clock  : 198000000Hz
nfc clock     : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ]
Boot Device: MMC

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
0xdb 0x00 0x1c 0x41 0x33 0x18 0xc0 0x00
0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00
0x00 0x00 0x0d 0x34 0x27 0x80 0x04 0x00
0x00 0x13 0xec 0x00

--------- HAB Event 2 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x00
0x00 0x00 0x00 0x20

--------- HAB Event 3 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x2c
0x00 0x00 0x02 0xa0

--------- HAB Event 4 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x04 0x20
0x00 0x00 0x00 0x01

--------- HAB Event 5 -----------------
event data:
0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00
0x00 0x00 0x00 0x00 0x27 0x80 0x06 0xe0
0x00 0x00 0x00 0x04
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
*** Warning - bad CRC or MMC, using default environment

In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:00:00:00:00:00
FEC0 [PRIME]
Hit any key to stop autoboot:  0
booti: bad boot image magic
fastboot is in init......flash target is MMC:3
wait usb cable into the connector!

So, I've tried to write the image at an address and have loaded it
from there. I've did the following in the uboot prompt:

MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage
Loading file "uImage" from mmc device 3:1 (xxd1)
594591 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:    594527 Bytes = 580.6 kB
   Load Address: 10001000
   Entry Point:  10001000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

It stops here (even after adjusting the UART settings before
building the image). I'm unable to find the source of the problem.
Can you give me any leads on the possible problems?

Thanks,
Kranthi

On Wed, Mar 29, 2017 at 6:18 PM, Kranthi Tej
<ee13b037@...484... <mailto:ee13b037@...484...>>

wrote:

...

    ---------- Forwarded message ----------
    From: "Stefan Kalkowski" <stefan.kalkowski@...1...
    <mailto:stefan.kalkowski@...1...>>
    Date: Mar 29, 2017 6:03 PM
    Subject: Re: Genode on i.MX6 (eMMC Flash)
    To: "Genode OS Framework Mailing List"
    <genode-main@lists.sourceforge.net
    <mailto:genode-main@lists.sourceforge.net>>
    Cc:

    Hi Kranthi Tej,

    On 03/28/2017 12:30 PM, Kranthi Tej wrote:
    > Hi Stefan,
    >
    > I've tried using the uboot plugin (RUN_OPT += --include
    image/uboot).
    > I've been able to generate a uImage successfully. When I tried
    to flash
    > it on to the board, it stops with following log (was observed

in

...

    > TeraTerm while using the MfgTool):
    >
    > U-Boot 2009.08 (Aug 16 2013 - 14:38:59)
    >
    > CPU: Freescale i.MX6 family TO1.5 at 792 MHz
    > Thermal sensor with ratio = 175
    > Temperature:   42 C, calibration data 0x5524cd69
    > mx6q pll1: 792MHz
    > mx6q pll2: 528MHz
    > mx6q pll3: 480MHz
    > mx6q pll8: 50MHz
    > ipg clock     : 66000000Hz
    > ipg per clock : 66000000Hz
    > uart clock    : 80000000Hz
    > cspi clock    : 60000000Hz
    > ahb clock     : 132000000Hz
    > axi clock   : 264000000Hz
    > emi_slow clock: 132000000Hz
    > ddr clock     : 528000000Hz
    > usdhc1 clock  : 198000000Hz
    > usdhc2 clock  : 198000000Hz
    > usdhc3 clock  : 198000000Hz
    > usdhc4 clock  : 198000000Hz
    > nfc clock     : 24000000Hz
    > Board: i.MX6Q-SABRESD: unknown-board Board: 0x63015 [POR ]

    As I can see you are using another board with less memory than

the

...

    Wandboard. Did you adapted the memory settings before building

the

...

    Genode image for that board?
    Like it was discussed in this parallel mail thread:


    http://genode-main.narkive.com/nWs1hbc8/genode-on-i-mx6q-sa

bre-lite

...

    <http://genode-main.narkive.com/nWs1hbc8/genode-on-i-mx6q-s

abre-lite>

...

    > Boot Device: MMC
    > I2C:   ready
    > DRAM:   1 GB
    > MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
    > Using default environment
    >
    > In:    serial
    > Out:   serial
    > Err:   serial
    > Net:   got MAC address from IIM: 00:00:00:00:00:00
    > FEC0 [PRIME]
    > Hit any key to stop autoboot:  0
    > ## Booting kernel from Legacy Image at 10800000 ...
    >    Image Name:
    >    Image Type:   ARM Linux Kernel Image (gzip compressed)
    >    Data Size:    2075251 Bytes =  2 MB
    >    Load Address: 10001000
    >    Entry Point:  10001000
    >    Verifying Checksum ... OK
    > ## Loading init Ramdisk from Legacy Image at 10c00000 ...
    >    Image Name:   uboot initramfs rootfs
    >    Image Type:   ARM Linux RAMDisk Image (gzip compressed)
    >    Data Size:    4545326 Bytes =  4.3 MB
    >    Load Address: 00000000
    >    Entry Point:  00000000
    >    Verifying Checksum ... OK
    >    Uncompressing Kernel Image ... OK
    >
    > Starting kernel ...
    >
    > Also, I'm using the Android RAMDisk Image. Would that be a
    potential
    > cause for the problem? I've used the following XML script to
    flash the
    > image on to the board (UCL file for MfgTool):

    If you think the Android RAM disk might interfer with your
    Genode image,
    being in your position I would not load it in the first place.

    >
    > <UCL>
    > <CFG>
    > <STATE name="BootStrap" dev="MX6Q" vid="15A2" pid="0054"/>
    > <STATE name="Updater"   dev="MSC" vid="066F" pid="37FF"/>
    > </CFG>
    >
    > <LIST name="SabreSD-eMMC" desc="Choose eMMC as media">
    > <CMD state="BootStrap" type="boot" body="BootStrap" file
    > ="u-boot-mx6q-sabresd.bin" >Loading U-boot</CMD>
    > <CMD state="BootStrap" type="load" file="files/demo/uimage"
    > address="0x10800000"
    >         loadSection="OTH" setSection="OTH"

HasFlashHeader="FALSE"

...

    >>Loading Kernel.</CMD>
    > <CMD state="BootStrap" type="load"

file="initramfs.cpio.gz.uboot"

...

    > address="0x10C00000"
    >         loadSection="OTH" setSection="OTH"

HasFlashHeader="FALSE"

...

    >>Loading Initramfs.</CMD>
    > <CMD state="BootStrap" type="jump" > Jumping to OS image.

</CMD> > > <CMD state="Updater" type="push" body="$ dd if=/dev/zero > of=/dev/mmcblk0 > > bs=512 seek=1536 count=16">clean up u-boot parameter</CMD> > > <!--CMD state="Updater" type="push" body="$ echo 1 > > > > /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0: 0001/boot_config">access > > boot partition 1</CMD--> > > <CMD state="Updater" type="push" body="$ echo 0 > > > /sys/block/mmcblk0boot0/force_ro">access boot partition 1</CMD> > > <CMD state="Updater" type="push" body="send" > > file="files/demo/mmc_img">Sending U-Boot</CMD> > > <CMD state="Updater" type="push" body="$ dd if=$FILE > of=/dev/mmcblk0 > > bs=512 seek=2 skip=2">write U-Boot to sd card</CMD> > > <!-- <CMD state="Updater" type="push" body="$ dd if=$FILE > > of=/dev/mmcblk0p1 bs=1k seek=1 skip=1 conv=fsync">write U-Boot > to sd > > card</CMD> --> > > <CMD state="Updater" type="push" body="$ echo 8 > > > > /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0: 0001/boot_config">access > > user partition and enable boot partion 1 to boot</CMD> > > <CMD state="Updater" type="push" body="send" > > file="mksdcard-android.sh.tar">Sending partition shell</CMD> > > <CMD state="Updater" type="push" body="$ tar xf $FILE "> > > Partitioning...</CMD> > > <CMD state="Updater" type="push" body="$ sh mksdcard-android.sh > > /dev/mmcblk0"> Partitioning...</CMD> > > <CMD state="Updater" type="push" body="$ ls -l /dev/mmc* > ">Formatting sd > > partition</CMD> > > <CMD state="Updater" type="push" body="pipe dd > of=/dev/mmcblk0p5 bs=512" > > file="files/demo/demo.img">Sending and writting demo.img</CMD> > > <CMD state="Updater" type="push" body="frf">Finishing rootfs > write</CMD> > > <CMD state="Updater" type="push" body="$ echo Update > Complete!">Done</CMD> > > </LIST> > > </UCL> > > > > The script stops executing at "Jumping to OS image". Can you > give me any > > leads as to where I'm going wrong? > > > > As I already told you, I do not have any experiences with that > tool, but > you probably encounter the same problems like when using the > uImage above. > > > Note: I've generated the "mmc_img" file using the > "create_uboot" tool > > provided in the genode tools. > > I see. In contrast to the run-tool, which produces either a disk > image > or uImage, this utility creates a disk image with the u-boot binary > only. I'm not sure whether you can use the same u-boot binary in > between > Wandboard and your board, probably not! > > We do not have a combination tool that combines u-boot and > system image > to provide one final disk image to you. > > Best regards > Stefan > > -- > Stefan Kalkowski > Genode Labs > > https://github.com/skalk · http://genode.org/ > > ----------------------------------------------------------- ------------------- > 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@lists.sourceforge.net > <mailto:genode-main@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/genode-main > <https://lists.sourceforge.net/lists/listinfo/genode-main> > > > > > > ------------------------------------------------------------ ------------------ > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main >

-- Stefan Kalkowski Genode Labs

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

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

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

Hello Stefan,

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.

Thanks for the clarification. I have been wondering why my log messages weren't being printed once I encounter the pagefault. This provides an explanation to my question. I've removed all the messages before core component has started within bootstrap. I'm stuck at the pagefault part. (as I have mentioned in my previous email)

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?

I've only made changes in the board_base.h file only. I haven't made any other changes. However, in contrast to the earlier emails, where I have used UART2, I discovered that we should be looking at UART1 on our board. I've just changed UART_1_MMIO_BASE and UART_1_IRQ values to the ones mentioned in the iMX6 reference manual for UART1 in the same file itself.

Thanks, Kranthi

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

Hello Stefan,

I've cloned the genode repository freshly as you have suggested. I've followed the following steps for building the uImage:

- Created a build directory by using /tool/create_builddir wand_quad - Included "RUN_OPT += --include image/uboot in [1] - Changed RAM0_SIZE = 0x80000000 to RAM0_SIZE = 0x40000000 - Run "make run/log" from the build directory [2]

When I haven't changed NR_OF_CPUS, it is hanging at "Starting kernel ..." itself. When I've changed NR_OF_CPUS to 1, I'm getting the following output:

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: 608176 Bytes = 593.9 kB Load Address: 10001000 Entry Point: 10001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

Starting kernel ...

:virt_alloc: Allocator 0x200c40b8 dump: Block: [00001000,10001000) size=256M avail=256M max_avail=256M Block: [10585000,20001000) size=256496K avail=256496K max_avail=3144208K Block: [2017b000,2017c000) size=4K avail=0 max_avail=0 Block: [2017c000,e0000000) size=3144208K avail=3144208K max_avail=3144208K Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144208K Block: [f0007000,f0008000) size=4K avail=0 max_avail=0 Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K => mem_size=4019097600 (3832 MB) / mem_avail=4019081216 (3832 MB)

:phys_alloc: Allocator 0x200c304c dump: Block: [10585000,10586000) size=4K avail=0 max_avail=0 Block: [10586000,10587000) size=4K avail=0 max_avail=1042644K Block: [10587000,10588000) size=4K avail=0 max_avail=0 Block: [105ca000,105cb000) size=4K avail=0 max_avail=1042644K Block: [105cb000,50000000) size=1042644K avail=1042644K max_avail=1042644K => mem_size=1067683840 (1018 MB) / mem_avail=1067667456 (1018 MB)

:io_mem_alloc: Allocator 0x200c5130 dump: Block: [00000000,10585000) size=267796K avail=267796K max_avail=267796K Block: [10588000,105ca000) size=264K avail=264K max_avail=2952790015 Block: [50000000,ffffffff) size=2952790015 avail=2952790015 max_avail=2952790015 => mem_size=3227283455 (3077 MB) / mem_avail=3227283455 (3077 MB)

:io_port_alloc: Allocator 0x200c619c dump: => mem_size=0 (0 MB) / mem_avail=0 (0 MB)

:irq_alloc: Allocator 0x200c7208 dump: Block: [00000000,00000001) size=1 avail=1 max_avail=1 Block: [00000002,0000001d) size=27 avail=27 max_avail=994 Block: [0000001e,00000400) size=994 avail=994 max_avail=994 => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)

:rom_fs: ROM modules: ROM: [1017e000,1017e158) config ROM: [10154000,1017a900) init ROM: [100d6000,10153b64) ld.lib.so ROM: [1017b000,1017d598) test-log

kernel initialized Error: page fault in core thread (core): ip=0x20037b34 fault=0x68c88038

We are unable to detect what the problem is. Am I missing something in the build process itself?

Thanks, Kranthi

[1] build/wand_quad/etc/build.conf [2] /build/wand_quad

On Tue, May 2, 2017 at 1:57 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:

Hi Kranthi,

On 05/02/2017 09:43 AM, Kranthi Tej wrote:

...

We've already made this change. We are currently using this setting itself. Besides, making this change, we've changed the NR_OF_CPUS to 1 in [1]. If we let the default value of 4 be set, the device hangs at "Starting kernel ..." stage itself. We also tried setting the RAM0_SIZE to 0x20000000. Our board has a physical RAM of 1 GB.

We have been facing the same pagefault for both the images (demo and log). The core isn't being started. Please provide any pointers to resolve this problem.

Please, do not test the release version 17.02, but the _current_ master branch, e.g., by cloning the git repository:

git@...116...:genodelabs/genode.git

just to ensure whether this works for you. I've used this version successfully with all 4 cores enabled on the same board.

Regards Stefan

-- Stefan Kalkowski Genode Labs

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

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello Stefan,

I've made the changes you've asked me to do and built a fresh uImage. I've shared the link to the uImage to your personal id ( stefan.kalkowski@...1...) with the subject "Genode on i.MX6 uImage".

Thanks, Kranthi

On Tue, May 2, 2017 at 4:00 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:

Hi Kranthi,

can you send me your resulting uImage (var/run/log/uImage) after a fresh built without NR_OF_CPUS changes to me personally so that I can test it on our board using my boot procedure?

Regards Stefan

On 05/02/2017 11:54 AM, Kranthi Tej wrote:

...

Hello Stefan,

I've cloned the genode repository freshly as you have suggested. I've followed the following steps for building the uImage:

• Created a build directory by using /tool/create_builddir wand_quad
• Included "RUN_OPT += --include image/uboot in [1]
• Changed RAM0_SIZE = 0x80000000 to RAM0_SIZE = 0x40000000
• Run "make run/log" from the build directory [2]

When I haven't changed NR_OF_CPUS, it is hanging at "Starting kernel ..." itself. When I've changed NR_OF_CPUS to 1, I'm getting the following output:

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: 608176 Bytes = 593.9 kB Load Address: 10001000 Entry Point: 10001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

Starting kernel ...

:virt_alloc: Allocator 0x200c40b8 dump: Block: [00001000,10001000) size=256M avail=256M max_avail=256M Block: [10585000,20001000) size=256496K avail=256496K max_avail=3144208K Block: [2017b000,2017c000) size=4K avail=0 max_avail=0 Block: [2017c000,e0000000) size=3144208K avail=3144208K

max_avail=3144208K

...

Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144208K Block: [f0007000,f0008000) size=4K avail=0 max_avail=0 Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K => mem_size=4019097600 (3832 MB) / mem_avail=4019081216 (3832 MB)

:phys_alloc: Allocator 0x200c304c dump: Block: [10585000,10586000) size=4K avail=0 max_avail=0 Block: [10586000,10587000) size=4K avail=0 max_avail=1042644K Block: [10587000,10588000) size=4K avail=0 max_avail=0 Block: [105ca000,105cb000) size=4K avail=0 max_avail=1042644K Block: [105cb000,50000000) size=1042644K avail=1042644K

max_avail=1042644K

...

=> mem_size=1067683840 (1018 MB) / mem_avail=1067667456 (1018 MB)

:io_mem_alloc: Allocator 0x200c5130 dump: Block: [00000000,10585000) size=267796K avail=267796K max_avail=267796K Block: [10588000,105ca000) size=264K avail=264K max_avail=2952790015 Block: [50000000,ffffffff) size=2952790015 avail=2952790015 max_avail=2952790015 => mem_size=3227283455 (3077 MB) / mem_avail=3227283455 (3077 MB)

:io_port_alloc: Allocator 0x200c619c dump: => mem_size=0 (0 MB) / mem_avail=0 (0 MB)

:irq_alloc: Allocator 0x200c7208 dump: Block: [00000000,00000001) size=1 avail=1 max_avail=1 Block: [00000002,0000001d) size=27 avail=27 max_avail=994 Block: [0000001e,00000400) size=994 avail=994 max_avail=994 => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)

:rom_fs: ROM modules: ROM: [1017e000,1017e158) config ROM: [10154000,1017a900) init ROM: [100d6000,10153b64) ld.lib.so http://ld.lib.so ROM: [1017b000,1017d598) test-log

kernel initialized Error: page fault in core thread (core): ip=0x20037b34 fault=0x68c88038

We are unable to detect what the problem is. Am I missing something in the build process itself?

Thanks, Kranthi

[1] build/wand_quad/etc/build.conf [2] /build/wand_quad

On Tue, May 2, 2017 at 1:57 PM, Stefan Kalkowski <stefan.kalkowski@...1... mailto:stefan.kalkowski@...1...> wrote:

Hi Kranthi,

On 05/02/2017 09:43 AM, Kranthi Tej wrote:
> We've already made this change. We are currently using this setting
> itself. Besides, making this change, we've changed the NR_OF_CPUS

to 1

...

> in [1]. If we let the default value of 4 be set, the device hangs

at

...

> "Starting kernel ..." stage itself. We also tried setting the

RAM0_SIZE

...

> to 0x20000000. Our board has a physical RAM of 1 GB.
>
> We have been facing the same pagefault for both the images (demo

and

...

> log). The core isn't being started. Please provide any pointers to
> resolve this problem.

Please, do not test the release version 17.02, but the _current_

master

...

branch, e.g., by cloning the git repository:

  git@...116...:genodelabs/genode.git

just to ensure whether this works for you. I've used this version
successfully with all 4 cores enabled on the same board.

Regards Stefan

--
Stefan Kalkowski
Genode Labs

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

------------------------------------------------------------

---

...

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@lists.sourceforge.net
<mailto:genode-main@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/genode-main
<https://lists.sourceforge.net/lists/listinfo/genode-main>

---

---

...

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

-- Stefan Kalkowski Genode Labs

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

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hello Stefan,

Thank you very much for patiently responding to all my queries. After you have run my uImage on your board successfully, we have changed the hardware and tried to run the uImage on it. It was working properly. I've been able to generate the same log that you have attached in your previous email.

We wouldn't have thought of changing the device if it was not for your help. Thanks a lot! :-)

We are successfully able to run Genode with the uImage generated with release version as well as the one which I cloned today. This seems to be working only when I set NR_OF_CPUS = 1. When I tried setting NR_OF_CPUS = 4, the kernel doesn't get loaded and it hangs at "Starting kernel ...". I am not sure why this is happening.

Is it possible for you to share the boot procedure you've followed and the details of the boot-loader? It would help us figure if the problem was with the hardware or with the flashing procedure.

Many thanks, Kranthi

On Tue, May 2, 2017 at 4:20 PM, Stefan Kalkowski < stefan.kalkowski@...1...> wrote:

Hi Kranthi,

I could boot the uImage you provided to me successfully, see below. Either we have slightly different variants of the same board, or the boot-loader does something fundamentally different, or you have some problem when loading the uImage correctly, so that the image gets corrupted.

Sorry, at the moment I do not have another idea, because I cannot reproduce your problem.

Regards Stefan

--

U-Boot 2009.08 (Apr 29 2013 - 18:01:51)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz Thermal sensor with ratio = 188 Temperature: 20 C, calibration data 0x5a35087d mx6q pll1: 792MHz mx6q pll2: 528MHz mx6q pll3: 480MHz mx6q pll8: 50MHz ipg clock : 66000000Hz ipg per clock : 66000000Hz uart clock : 80000000Hz cspi clock : 60000000Hz ahb clock : 132000000Hz axi clock : 264000000Hz emi_slow clock: 132000000Hz ddr clock : 528000000Hz usdhc1 clock : 198000000Hz usdhc2 clock : 198000000Hz usdhc3 clock : 198000000Hz usdhc4 clock : 198000000Hz nfc clock : 24000000Hz Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ] Boot Device: SD I2C: ready DRAM: 1 GB MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 In: serial Out: serial Err: serial Found PFUZE100! deviceid=10,revid=11 Net: got MAC address from IIM: 00:04:9f:02:e2:bb FEC0 [PRIME] Hit any key to stop autoboot: 0 PHY indentify @ 0x1 = 0x004dd074 FEC: Link is Up 796d BOOTP broadcast 1 DHCP client bound to address 10.0.0.109 Using FEC0 device TFTP from server 10.0.0.2; our IP address is 10.0.0.109 Filename '/tftpboot/hosts/imx6-sabre.scr'. Load address: 0x10800000 Loading: # done Bytes transferred = 156 (9c hex) ## Executing script at 10800000 FEC: Link is Up 796d Using FEC0 device TFTP from server 10.0.0.17; our IP address is 10.0.0.109 Filename '/var/lib/tftpboot/uImage'. Load address: 0x30000000 Loading: ########################################## done Bytes transferred = 608911 (94a8f hex) ## Booting kernel from Legacy Image at 30000000 ... Image Name: Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 608847 Bytes = 594.6 kB Load Address: 10001000 Entry Point: 10001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK

Starting kernel ...

:virt_alloc: Allocator 0x200f40b8 dump: Block: [00001000,10001000) size=256M avail=256M max_avail=256M Block: [105b5000,20001000) size=256304K avail=256304K max_avail=3144016K Block: [201ab000,201ac000) size=4K avail=0 max_avail=0 Block: [201ac000,e0000000) size=3144016K avail=3144016K max_avail=3144016K Block: [f0004000,f0005000) size=4K avail=0 max_avail=3144016K Block: [f0007000,f0008000) size=4K avail=0 max_avail=0 Block: [f0009000,f000a000) size=4K avail=0 max_avail=262036K Block: [f000a000,fffef000) size=262036K avail=262036K max_avail=262036K => mem_size=4018704384 (3832 MB) / mem_avail=4018688000 (3832 MB)

:phys_alloc: Allocator 0x200f304c dump: Block: [105b5000,105b6000) size=4K avail=0 max_avail=0 Block: [105b6000,105b7000) size=4K avail=0 max_avail=1042260K Block: [105b7000,105b8000) size=4K avail=0 max_avail=0 Block: [1062a000,1062b000) size=4K avail=0 max_avail=1042260K Block: [1062b000,50000000) size=1042260K avail=1042260K max_avail=1042260K => mem_size=1067290624 (1017 MB) / mem_avail=1067274240 (1017 MB)

:io_mem_alloc: Allocator 0x200f5130 dump: Block: [00000000,105b5000) size=267988K avail=267988K max_avail=267988K Block: [105b8000,1062a000) size=456K avail=456K max_avail=2952790015 Block: [50000000,ffffffff) size=2952790015 avail=2952790015 max_avail=2952790015 => mem_size=3227676671 (3078 MB) / mem_avail=3227676671 (3078 MB)

:io_port_alloc: Allocator 0x200f619c dump: => mem_size=0 (0 MB) / mem_avail=0 (0 MB)

:irq_alloc: Allocator 0x200f7208 dump: Block: [00000000,00000001) size=1 avail=1 max_avail=1 Block: [00000002,0000001d) size=27 avail=27 max_avail=994 Block: [0000001e,00000400) size=994 avail=994 max_avail=994 => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)

:rom_fs: ROM modules: ROM: [101ae000,101ae158) config ROM: [10184000,101aa900) init ROM: [10106000,10183b64) ld.lib.so ROM: [101ab000,101ad598) test-log

kernel initialized Genode 17.02-127-gf6386c6 <local changes> 1016 MiB RAM assigned to init [init -> test-log] hex range: [0e00,1680) [init -> test-log] empty hex range: [0abc0000,0abc0000) (empty!) [init -> test-log] hex range to limit: [f8,ff] [init -> test-log] invalid hex range: [f8,08) (overflow!) [init -> test-log] negative hex char: 0xfe [init -> test-log] positive hex char: 0x02 [init -> test-log] multiarg string: "parent -> child.7" [init -> test-log] String(Hex(3)): 0x3 [init -> test-log] Test done.

Run script execution successful.

-- Stefan Kalkowski Genode Labs

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

---

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main