I.MX6 U-Boot hang while it boot linux kernel

[jinliang_li]

U-Boot Version: u-boot-fslc  2017.11-fslc  https://github.com/Freescale/u-boot-fslc/commit/a07698f0bfdb2887b617399643acd659c6e75138

Board: i.mx6ul

It can boot successfully until I add some debug information in boot process by printf function just like in the patch in attachments.  After adding some printf, U-Boot bootz command can't parse the dtb successfully, and then hang. The detailed error messages :

=> load mmc 1:1 0x83000000 imx6ul-14x14-evk.dtb
reading imx6ul-14x14-evk.dtb
37104 bytes read in 19 ms (1.9 MiB/s)
=> load mmc 1:1 0x82000000 zImage
reading zImage
7436328 bytes read in 337 ms (21 MiB/s)
=> bootz 0x82000000 - 0x83000000
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:612
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:641
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:655
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:664
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:715
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:721
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:612
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:641
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:655
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:664
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/bootm.c:692
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/arch/arm/lib/bootm.c:417
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/arch/arm/lib/bootm.c:224
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image.c:1508
Using Device Tree in place at 83000000, end 8300c0ef
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:194
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:196
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image.c:1515
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:467
DONKEY:/path/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:472
subnode: chosen: FDT_ERR_BADSTRUCTURE
ERROR: /chosen node create failed
- must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###

It seems that the memory of dtb (0x83000000 ) is corrupted due to my some printf.  That's unbelievable. Could anyone help me on this? 

Thanks in advance,

Jinliang

[jinliang_li]

I just tested the u-boot-fslc 2018.11+fslc， 2017.09+fslc, 2018.01+fslc,  they all can work well.  Is there any known issue in u-boot 2017.11+fslc? JiangJustin shivanipatel

That's too hard to debug such issue in u-boot. 

[shivanipatel]

Hi, Jinliang Li 

Could you please try to use u-boot supported by NXP which can be built from the attached Yocto User Guide?

I have compiled the uboot with applying your patch, kernel & DTB from the attached Yocto User Guide and I did not come across any error.

Regards,

Shivani

[jinliang_li]

Hi Shivani Patel,

Which u-boot version are you using? 

[jinliang_li]

Hi,

I also used the yocto meta-freescale, GitHub - Freescale/meta-freescale: Layer containing NXP hardware support metadata . And the u-boot version is u-boot-fslc_2017.11 .

[jinliang_li]

To reproduce this issue,  the minimum debug messages needed to be kept as 0001-Keep-minimum-debug-messages.patch.  Keep printf functions in common/fdt_support.c, common/image-fdt.c, common/image.c. It can work well if I only keep printf functions in common/fdt_support.c or common/image-fdt.c, common/image.c .

So it can not to be determined which exactlly printf function cause the issue. 

And when I add or remove some printf functions,  the error messages may be different, however it always hang at parsing dtb.

Sometimes, it hang here

U-Boot SPL 2017.11+fslc+ga07698f (Jul 30 2019 - 19:34:57)
Trying to boot from MMC1

U-Boot 2017.11+fslc+ga07698f (Jul 30 2019 - 19:34:57 +0800)

CPU: Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz)
CPU: Industrial temperature grade (-40C to 105C)Reset cause: POR
Board: MX6UL 14x14 EVK
I2C: ready
DRAM: 512 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

Video: 480x272x24
In: serial
Out: serial
Err: serial
Net: , FEC1
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
switch to partitions #0, OK
mmc1 is current device
** Unable to read file boot.scr **
reading zImage
7409120 bytes read in 336 ms (21 MiB/s)
Booting from mmc ...
reading imx6ul-14x14-evk.dtb
37104 bytes read in 18 ms (2 MiB/s)
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image.c:1508
Using Device Tree in place at 83000000, end 8300c0ef
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:194
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:196
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image.c:1515
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:467
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/image-fdt.c:472
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/fdt_support.c:284
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-r0/git/common/fdt_support.c:291
DONKEY:/path/alios-release/dev_linux_module2/build/tmp/work/imx6ulevk-alios-linux-gnueabi/u-boot-fslc/v2017.11+gitAUTOINC+a07698f0bf-0/git/common/fdt_support.c:115:offset:0 name:chosen

Sometimes, it throw a "data abort"/"undefined instruction" execption.

data abort
pc : [<9ff9f10e>] lr : [<9ff9efcf>]
reloc pc : [<8782710e>] lr : [<87826fcf>]
sp : 9ef77858 ip : 00000000 fp : 9ff78cc9
r10: 00000007 r9 : 9ef77eb8 r8 : 00000000
r7 : 9ffaa327 r6 : 83000000 r5 : 9ef77874 r4 : fffffff5
r3 : 0000001a r2 : 00008690 r1 : 00000064 r0 : 00000009
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...

resetting ...

However the pc pointer maybe different.

Other informations:

1. It can work well if I enable all debug message,  define debug in include/common.h.

2. I dumped and compared the memory of dtb with the working one, they are same.

3. printf is used after UART initialized.

[justin_jiang]

Usually printf() can't impact system boot. Would you narrow down the issue with removing some printf() and check which printf caused the issue? Did you call printf before UART is initialized?

[jinliang_li]

Hi Justin,

Do you have any other suggestion?