i.MX6UL: U-boot 2018.03 instability issue
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,
On 6/18/21 6:17 AM, Rosario Borsellino wrote:
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.
Does this occur with 2021.04?
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>]
What functions/lines are these? You can use objdump -S and grep for the reloc pc and lr (or look at u-boot.map, but that will not give you line numbers)
--Sean
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,
Hi
On Fri, Jun 18, 2021 at 6:49 PM Sean Anderson sean.anderson@seco.com wrote:
On 6/18/21 6:17 AM, Rosario Borsellino wrote:
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.
Does this occur with 2021.04?
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>]
What functions/lines are these? You can use objdump -S and grep for the reloc pc and lr (or look at u-boot.map, but that will not give you line numbers)
bdinfo
I don't have know a board switch on but the tftp load at 0x8800000 and your fdtaddr is 0x8300000
Michael
Michael
--Sean
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,
participants (3)
-
Michael Nazzareno Trimarchi -
Rosario Borsellino -
Sean Anderson