We have a design based largely on the imx6ULevk. The code is build using yocto and the *.sdcard file is copied to the SD via dd command. The SD card is then inserted into the imx6ulevk, u-boot and the kernel boot as expected. If I take that same SD card and attempt to boot, u-boot is loaded by the IMX6ul ROM, u-boot runs and is able to see the mmc into which the SD card is inserted. U-boot is then able to extract the zImage and device tree blobs. The kernel then hangs. I have placed several printk statements into the kernel but our custom board seems to have trouble after the zImage is decompressed. Here is the output from our custom board:
reading zImage
6339800 bytes read in 329 ms (18.4 MiB/s)
Booting from mmc ...
reading imx6ul-14x14-evk.dtb
30156 bytes read in 20 ms (1.4 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x60bcd8 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 83000000, end 8300a5cb
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Here is the output from the EVK:
reading zImage
6339800 bytes read in 328 ms (18.4 MiB/s)
Booting from mmc ...
reading imx6ul-14x14-evk.dtb
30156 bytes read in 20 ms (1.4 MiB/s)
Kernel image @ 0x80800000 [ 0x000000 - 0x60bcd8 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 83000000, end 8300a5cb
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
start_kernel: Function Entered <--------------------------my printk
start_kernel: Calling smp_setup_processor_id()<--------------------------my printk
smp_setup_processor_id: Function Entered<--------------------------my printk
Booting Linux on physical CPU 0x0
Linux version 3.14.38-6UL_ga+ge4944a5 (mac@ubuntu) (gcc version 4.9.2 (GCC) ) #18 SMP PREEMPT Tue Jan 26 15:58:27 CST 2016
At this point I would like to place a dump_stack() or similar call to see where arch/arm/boot/compressed/misc.c: decompress_kernel() returns to thereby allowing me to see where the kernel locks. Any thoughts?
Solved! Go to Solution.
Found and fixed the issue. It all came down to the decrease in ram size I was not made aware of. Thanks for all of your help Igor!
Found and fixed the issue. It all came down to the decrease in ram size I was not made aware of. Thanks for all of your help Igor!
Hi michael
for new board it is necessary to run ddr test
i.MX6/7 DDR Stress Test Tool V2.40
obtain calibration settings and modify uboot *.cfg file,
also one can check uboot/include/configs *board*.h file
for other board specific settings. For debugging one can look at
AN4553 Using Open Source Debugging Tools for Linux on i.MX Processors
http://cache.nxp.com/files/32bit/doc/app_note/AN4553.pdf
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Igor,
Why would I have to run the DDR stress test if our board uses the same SOC as the EVK? DDR is internal to the SOC and as such the DDR test values would be similar between our custom board and the EVK.
Hi michael
DDR is not internal to the SOC, there is external
ddr chip on SPF-28617.PDF p.5. Also board material affects on
ddr lines impedance and should be tested with ddr test.
Best regards
igor
Igor,
Clear mistake on my part. Anyway, I was informed by the hardware team that our design, unlike the EVK, is using 1/2 as much memory. This is probably why linux is hanging. I am guessing that this new memory configuration needs to be communicated to u-boot and kernel. Being new to device tree, I am not sure where to look for such changes. Any help?
Any documentation on this tool? I spent over an hour looking for some sort of guide but found nothing.
I don't understand why everything with Freescale parts has to be such a hassle.