i.MX6UL: U-boot 2018.03 instability issue

Rosario Borsellino rosario.borsellino at dave.eu
Fri Jun 18 12:17:44 CEST 2021


Hello everyone,

This is the first time that I request help on a mailing list so tell me 
if I make anything wrong.

I'm having hard time trying to debug an issue on U-boot 2018.03, built 
for a custom i.MX6UL platform.

During the porting from U-boot 2015.04, as I need to display a 
splashcreen, I enabled the CONFIG_VIDEO property (alongside with the 
required initializations on my board sources). This made the work (I can 
see the default DENX splash on video) but made the U-boot unstable.

As an example, if I run any fdt command from the shell, U-boot hangs 
with a data abort. Here the printout:

...
=> setenv loadfdt tftpboot ${fdtaddr} ${serverip}:${fdtfile}
=> setenv fdtaddr 0x83000000
=> setenv fdtfile rb/imx6ul-dave-devel.dtb
=> setenv serverip 192.168.0.13
=> setenv ipaddr 192.168.0.83
=> run loadfdt
Using FEC0 device
TFTP from server 192.168.0.13; our IP address is 192.168.0.83
Filename 'rb/imx6ul-dave-devel.dtb'.
Load address: 0x88000000
Loading: ########
          1.2 MiB/s
done
Bytes transferred = 38141 (94fd hex)
=> fdt addr ${fdtaddr}
=> fdt print /cb
data abort
pc : [<8ff460c0>]          lr : [<8ff4c2c9>]
reloc pc : [<878000c0>]    lr : [<878062c9>]
sp : 8df45cf8  ip : 00000000     fp : 00000003
r10: 8df50cd8  r9 : 8df45eb0     r8 : 00000003
r7 : fffffff5  r6 : 00000020     r5 : 00000000  r4 : 8ffbf514
r3 : 00000001  r2 : 0000894c     r1 : 000000d8  r0 : fffffff5
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

U-Boot SPL 2018.03-munich-2.0.0-rc4 (Jun 18 2021 - 09:16:52 +0200)
...

But the instability is not only related to these commands (I use this as 
a PASS/FAIL test), so I don't either know where to check.

Debugging via JTAG, with Trace32 tool, I can make the command print the 
requested node, but only if I run step-by-step.

I found that CONFIG_VIDEO property enables by default the 
CONFIG_CONSOLE_MUX property, disabling the latter the fdt test pass.

Has anyone ever seen this behaviour and can address me to find the root 
cause?

I'm working on top of NXP stable branches, so I don't know if I can find 
help here. I also enbled the SPL build which is not officially supported 
by NXP. Let me know what printouts, code snippet or test to perform I 
need to share to help in the identification of the problem.

Best regards,

-- 
Rosario BORSELLINO

DAVE Embedded Systems

via Talponedo 29/A 33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
web: www.dave.eu


More information about the U-Boot mailing list