![]() 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. +# error A CONFIG_ENV_IS_IN_ define is required for Mender to work. +#if !defined(CONFIG_ENV_IS_IN_MMC) & !defined(CONFIG_ENV_IS_IN_UBI) ![]() +/* Ossian: CONFIG_ENV_IS_NOWHERE is needed to boot using the UUU tool was: #ifdef CONFIG_ENV_IS_NOWHERE */ Make the following modification in recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch: +#ifndef MENDER_AUTO_PROBING 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 The final solution is very easy to fix, by patching/updating two files. #U BOOT SPL PATCH#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. I’m just providing a solution for those that encounter a similar issue and are looking for a good solution. ![]() It’s possible that my diagnosis of the issue is not correct, but this is my current conclusion based on what I’m seeing. 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. I don’t remember seeing this issue with the non-SPL version of u-boot. This initial u-boot image will need to have CONFIG_ENV_IS_NOWHERE defined, and I’m guessing should not have Mender enabled. The UUU tool needs to load an initial u-boot image that can initialize the USB communication transfer and flash the eMMC/SD image. (Curiously CONFIG_ENV_IS_ does not appear to have a RAM option.) 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. 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. (Mender also requires the CONFIG_BOOTCOUNT configurations and although there is a CONFIG_BOOTCOUNT_RAM option, Mender wants the CONFIG_BOOTCOUNT_ENV option defined. Mender wants to see a configuration of CONFIG_ENV_IS_MMC. By, default the Variscite board configurations are set to CONFIG_ENV_IS_NOWHERE, this configuration is not allowed by Mender. 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. 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’m hopeful that someone can provide some guidance on how best to tackle identifying the root cause of this issue. 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 looking for some guidance with how best to track down this issue within the u-boot-mender.inc file. I don’t know if anyone else has seen this issue or something similar. OF: bus is default (na=1, ns=1) on 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. Print_resetinfo: No sysreset device found (error: -19)ĬPU: i.MX8MP rev1.1 1600 MHz (running at 1200 MHz)ĬPU: Industrial temperature grade (-40C to 105C)nxp_tmu_parse_fdt dev name ** translation for device ** The standard working boot transition looks like the following: External data: dst=970000, offset=adf70, size=b150 Selecting default config 'imx8mp-var-dart-dt8mcustomboard'įirmware: data: dst=40200000, offset=3000, size=a49b8įdt: get 'load' property from FIT 0x401ffc00, node: offset 244, name (FDT_ERR_NOTFOUND)Įxternal data: dst=402a49c0, offset=a79b8, size=6dd8 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 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. When I generate the standard u-boot image in Yocto and load the image through the UUU tool, all boots as expected. I’m attempting to load u-boot using the NXP UUU tool into a Variscite DART board with an i.MX8m-plus board. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |