I’m attempting to load u-boot using the NXP UUU tool into a Variscite DART board with an i.MX8m-plus board.
When I generate the standard u-boot image in Yocto and load the image through the UUU tool, all boots as expected. But, if I enable “mender-uboot”, build the same u-boot image and load using the UUU tool u-boot will hang between the transition from SPL to the main u-boot. I have fully instrumented u-boot and see the following debug output before it locks up:
fit read sector 48031da0, sectors=912, dst=401ffc00, count=912, size=0x390 Selecting default config 'imx8mp-var-dart-dt8mcustomboard' firmware: 'uboot@1' External data: dst=40200000, offset=3000, size=a49b8 Selecting default config 'imx8mp-var-dart-dt8mcustomboard' fdt: 'fdt@1' Can't get 'load' property from FIT 0x401ffc00, node: offset 244, name fdt@1 (FDT_ERR_NOTFOUND) External data: dst=402a49c0, offset=a79b8, size=6dd8 Selecting default config 'imx8mp-var-dart-dt8mcustomboard' loadables: 'atf@1' External data: dst=970000, offset=ae790, size=b150 Selecting default config 'imx8mp-var-dart-dt8mcustomboard' no string for index 1 Jumping to U-Boot loaded - jumping to U-Boot... image entry point: 0x970000
The standard working boot transition looks like the following:
External data: dst=970000, offset=adf70, size=b150 Selecting default config 'imx8mp-var-dart-dt8mcustomboard' no string for index 1 Jumping to U-Boot loaded - jumping to U-Boot... image entry point: 0x970000 initcall: 0000000040268d28 U-Boot 2020.04-lf_v2020.04_var01+g7ffdddacd2 (Jun 06 2021 - 16:01:28 +0000) initcall: 0000000040214b20 U-Boot code: 40200000 -> 402A4190 BSS: -> 402C8228 initcall: 0000000040214e0c initcall: 0000000040214c8c print_resetinfo: No sysreset device found (error: -19) initcall: 00000000402034c4 CPU: i.MX8MP rev1.1 1600 MHz (running at 1200 MHz) CPU: Industrial temperature grade (-40C to 105C)nxp_tmu_parse_fdt dev name tmu@30260000 OF: ** translation for device tmu@30260000 ** OF: bus is default (na=1, ns=1) on bus@30000000
I have debugged this issue to the point where it looks like the issue occurs when u-boot-mender.inc is included in the build process.
I don’t know if anyone else has seen this issue or something similar. I’m looking for some guidance with how best to track down this issue within the u-boot-mender.inc file.
I currently have the feeling like what is causing the issue is set in do_mender_uboot_auto_configure() or do_provide_mender_defines(). I’m hopeful that someone can provide some guidance on how best to tackle identifying the root cause of this issue. My plan is to start digging further into these two functions, but I figured I would check if anyone has seen this and knows what might be causing the problem.