Device tree which refuses to boot T4240QDS-64b

[jakobdanielsson]

Hello!

I am using a T4240QDS-64b board which for some reason stops booting whenever the devicetree blob is getting loaded. According to the DCM system i am using a T4240QDS/tetra board and Build 2012_0918_1005/V42.

The fact is, I get the exact same error as in: T4240rdb kernel hangs after loading device tree, and according to suggested solutions there was a patch fix in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e95235. However, I was able to verify that this patch had been applied as I was able to locate the code of vmlinuz.lds.s. I am also using the latest SDK version of QorliQ namely, 1703. 

The difference between my error and the error posted in T4240rdb kernel hangs after loading device tree, is that the device tree hangs regardless of which GCC version I am using. Thus, gcc 5.2.0 fails and so does gcc 4.9.4. I used current poky and meta-fsl-ppc layers to compile the image.

I've tried two approaches for loading the system onto the T4240QDS

The suggest approach by yocto:

tftp 1000000 uImage--4.1-r0-t4240qds-64b-20170612134818.bin
tftp 2000000 uImage--4.1-r0-t4240qds-64b-usdpaa-20170612134818.dtb
tftp 5000000 fsl-image-core-t4240qds-64b-20170612134818.rootfs.ext2.gz.u-boot
=> bootm 1000000 5000000 2000000
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-4.1.35-rt41
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    5107701 Bytes = 4.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 05000000 ...
   Image Name:   fsl-image-core-t4240qds-64b-2017
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    33194692 Bytes = 31.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x02000000
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 2e057000, end 2ffff2c4 ... OK
   Loading Device Tree to 03fdb000, end 03fff12e ... OK

This approach just hangs after loading the device tree and wont give me any further information.

And the freescale approach: http://cache.freescale.com/files/training/doc/ftf/2014/FTF-SDS-F0095.pdf 

bootfile=uImage--4.1-r0-t4240qds-64b-20170612134818.bin
fdtfile=uImage--4.1-r0-t4240qds-usdpaa-shared-interfaces-20170612134818.dtb
ramdiskfile=fsl-image-core-t4240qds-64b-20170612134818.rootfs.ext2.gz.u-boot
loadaddr=0x1000000
ramdiskaddr=0x02000000
fdtaddr=0x00c00000
run ramboot
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-4.1.35-rt41
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    5107701 Bytes = 4.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
   Image Name:   fsl-image-core-t4240qds-64b-2017
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    33194692 Bytes = 31.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 00c00000
   Booting using the fdt blob at 0x00c00000
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 2e057000, end 2ffff2c4 ... OK
ERROR: image is not a fdt - must RESET the board to recover.

This approach atleast reboots the board.

Anyhow, it seems to be some major issue regarding the device tree blob, and the question is, why is this happening and how can I fix it?

Best,

Jakob

[Pavel]

It looks like that your problem requires debugging like to the debugging on this page:

https://community.nxp.com/thread/377178

This page shows problem in the kernel-source/arch/powerpc/kernel/head_64.S file.

Perhaps this problem happens in your code.

Test your board using GCC 9.4.4.

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jakobdanielsson]

I should mention that the GCC version I'm compiling is 4.9.2, not 4.9.4