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[8] 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.
I should also mention that the same u-boot image “imx-boot” (IMAGE_BOOTLOADER = “imx-boot”) when loaded on an SD card boots without issue. So, the issue appears to be only when the “imx-boot” (MENDER_IMAGE_BOOTLOADER_FILE = “imx-boot”) is loaded using the UUU tool.
As indicated the standard imx-boot image generated without Mender enabled will boot both from the SD card as well as using the UUU tool
Your best bet is probably to look at the patch that it generates, and make sure it makes sense. Take a look at the manual U-Boot integration section in the documentation, and in particular, the part about extracting the patch from the automatic patcher.
Thank you both for the suggestions. After digging through the u-boot configurations and settings, it looks like the issue is caused by the fact that u-boot/SPL does not like having an environment storage location defined if none exists. By, default the Variscite board configurations are set to CONFIG_ENV_IS_NOWHERE, this configuration is not allowed by Mender. Mender wants to see a configuration of CONFIG_ENV_IS_MMC. (Mender also requires the CONFIG_BOOTCOUNT configurations and although there is a CONFIG_BOOTCOUNT_RAM option, Mender wants the CONFIG_BOOTCOUNT_ENV option defined. When the Mender generated image is flashed to the SD card, or eMMC all is good because the environment location has been defined and configured. But, when using the UUU tool to flash an image, the initial u-boot image that the UUU tool needs can’t have and environment that is anywhere but in RAM. (Curiously CONFIG_ENV_IS_ does not appear to have a RAM option.)
The UUU tool needs to load an initial u-boot image that can initialize the USB communication transfer and flash the eMMC/SD image. This initial u-boot image will need to have CONFIG_ENV_IS_NOWHERE defined, and I’m guessing should not have Mender enabled. I don’t remember seeing this issue with the non-SPL version of u-boot.
It would be nice to have one build configuration and u-boot image, but I have not been able to think of an elegant way to accomplish this. It’s possible that my diagnosis of the issue is not correct, but this is my current conclusion based on what I’m seeing.
I’m just providing a solution for those that encounter a similar issue and are looking for a good solution. I found that the best thing to do to solve the the issue mentioned in this post was to patch the Mender recipes to accept CONFIG_ENV_IS_NOWHERE as a valid configuration along with CONFIG_ENV_IS_MMC. The final solution is very easy to fix, by patching/updating two files. The affected files are: recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch and recipes-bsp/u-boot/files/uboot_auto_configure.sh
Make the following modification in recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch:
+#ifndef MENDER_AUTO_PROBING
+
+#include <config_mender_defines.h>
+/* Ossian: CONFIG_ENV_IS_NOWHERE is needed to boot using the UUU tool was: #ifdef CONFIG_ENV_IS_NOWHERE */
+#if !defined(CONFIG_ENV_IS_IN_MMC) && !defined(CONFIG_ENV_IS_IN_UBI)
+# error A CONFIG_ENV_IS_IN_<storage-type> define is required for Mender to work. For standard Mender setups this should be CONFIG_ENV_IS_IN_MMC for HD/SSD/MMC/SD storage setup, and CONFIG_ENV_IS_IN_UBI for Flash/UBI storage.
+#endif
+
+#ifndef CONFIG_BOOTCOUNT_LIMIT
Make the following modification in recipes-bsp/u-boot/files/uboot_auto_configure.sh:
# Make sure the environment is in MMC.
replace_definition \
'CONFIG_ENV_IS_(NOWHERE|IN_[^ ]*)' \
'CONFIG_ENV_IS_IN_MMC'
# Ossian: Need to have CONFIG_ENV_IS_NOWHERE defined for the UUU tool.
# Mender still works as designed with this config enabled.
add_definition \
'CONFIG_ENV_IS_NOWHERE'
add_definition \
'CONFIG_CMD_EXT4'
add_definition \
'CONFIG_CMD_FS_GENERIC'
add_definition \
'CONFIG_MMC'
}
With these two modifications and MENDER_UBOOT_AUTO_CONFIGURE = “1” enabled u-boot should be setup to work with the UUU tool, and will continue to work as expected for Mender updates.
I encountered the exact same issue when trying to integrate mender into an Avnet msc sm2s-imx8plus board. Thank you for providing detailed information and a fix, this saved my day!
