Hi Henrique,
“An important question here: are you facing this issue with only this specific module or you could face the same issue with other modules?”
Most other modules are affected, both version 1.1B and 1.1D.
One 1.1B SoM is reported to not be affected. But they are going to swap with another SoM and see if the startup problem follows the affected SOM or not. I’m waiting for that information.
brdgs
Jerker
Hi @jerrymek !
Ok. Let us know if you have updates regarding your issue.
The U-Boot environment variables corruption is happening with Toradex’s U-boot? Or you are getting the U-Boot from somewhere else? If you are getting it from Toradex, could you please check which branch you are using?
Please refer to the U-Boot version table of Build From Source Code Documentation Overview | Toradex Developer Center article to find out the expected U-Boot branch to be used for each Toradex Module. For BSP 5 and Verdin iMX8M MIni, it is expected to use the U-boot branch toradex_imx_v2020.04_5.4.70_2.3.0.
Furthermore, your U-Boot version has a devel in its name:
When I install the Reference Minimal Image (BSP 5.7.0) from Toradex’s feed using Toradex Easy Installer, I get a different U-Boot version (no devel):
U-Boot SPL 2020.04-5.7.0+git.33bb8e968332 (Jul 06 2022 - 12:21:53 +0000)
Please, try to use Toradex’s default image/U-Boot to check if the problem still occurs on your modules.
Best regards,
Hi Henrique,
thx for the info.
The U-boot version was from an earlier build where I stepped the version of the OS image to 5.7.1 but still had our own layers in the build.
Today I loaded a Toradex Minimal Reference Image:
U-Boot SPL 2020.04-5.7.0+git.33bb8e968332 (Jul 06 2022 - 12:21:53 +0000)
So far only one try - where the boot was successful.
I will do more testing to see if I can provoke the problem.
brdgs
Jerker
I tried approx 30 restarts of the minimal reference image then I decided to revert back to 4.7.1, where we have seen the problem and add some debug printouts to try to add some more insight what’s going wrong occasionally.
Please give some input what might be interesting to look at, for example are there any error bits that can indicate the error state of the MMC or any interface to the MMC.
I’ve checked which u-boot branch we’re using:
$ git status
On branch toradex_imx_v2020.04_5.4.70_2.3.0
Your branch is up to date with ‘origin/toradex_imx_v2020.04_5.4.70_2.3.0’.
We seem to use the right branch of u-boot.
Hi @jerrymek !
Does this mean that all 30 boot attempts with unmodified Toradex Reference Minimal Image faced the same issue? Is this what you meant?
Best regards,
Hi Henrique,
No, during the 30 attempts with the minimal reference image I did see the problem once.
Brgds
Jerker
The word not was missing. sorry for the typo.
brdgs
Jerker
Hello,
I am pleased to say that I think we have found the root cause of our problems. I have been running tests during the last two weeks with a fix which has resulted in zero issues.
We are using the boot script from the “Mender integration layer for Toradex family of boards” [1] which reads a file ‘overlays.txt’ and imports whatever environment variables it contains. Our issue is that someone previously has removed the file from our distribution image causing the u-boot loading of the file to fail.
The u-boot script does not check if the file read is successful or not and tries to import environment variables from whatever may be in the memory at the specified address with a size of the last successful file read, in our case the device tree.
This could explain our trashed environment and sporadic booting problems. I have applied a patch to the boot script as to only perform the environment import if the file load succeeds and this has solved our issues.
Best regards,
Rasmus Linusson
[1] History for meta-mender-toradex-nxp - mendersoftware/meta-mender-community · GitHub
Hi Rasmus,
nice work!
brdgs
Jerker
Hi @rasmus !
That’s great that you solved the issue!
Also, thanks for sharing the solution. That’s great for our Community! 
Could you please mark your message as the solution?
Thanks and best regards,
Hello Rasmus,
I have the same (sporadic) issue, also using mender, but I am not sure in which commit of meta-toradex-nxp your solution has been implemented. Could you give me a hint or share your patch?
Thank you, Klaus
Hello Klaus,
This is the patch that I implemented to solve our issue. I hope it can help you solve your issue!
The only change is the addition of ‘&&’ after trying to load the file and reading the memory and returning true for both file load failed and success as it doesn’t matter for us.
It patches boot.cmd.in and I placed in the following directory: recipes-bsp/u-boot-distro-boot/files/toradex-bsp-5.7.0/0002-Fix-uboot-issue.patch
I don’t remember everything exactly but from the link in my previous message I believe this is the source of the lines that I needed to patch. It’s introduced by mender so if you have the same issue it should be applied after that patch.
--- boot.cmd.in.orig
+++ boot.cmd.in
@@ -23,7 +23,7 @@ env set load_prefix 'boot/'
env set load_cmd 'load ${mender_uboot_root}'
env set load_cmd_boot 'load ${mender_uboot_boot}'
env set set_bootcmd_kernel 'env set bootcmd_kernel "${load_cmd} \\${kernel_addr_load} \\${load_prefix}\\${kernel_image}"'
-env set set_load_overlays_file 'env set load_overlays_file "${load_cmd_boot} \\${loadaddr} \\${overlays_file}; env import -t \\${loadaddr} \\${filesize}"'
+env set set_load_overlays_file 'env set load_overlays_file "${load_cmd_boot} \\${loadaddr} \\${overlays_file} && env import -t \\${loadaddr} \\${filesize}; true"'
env set fdt_resize 'fdt addr ${fdt_addr_r} && fdt resize 0x20000'
env set set_bootcmd_dtb 'env set bootcmd_dtb "echo Loading DeviceTree: \\${fdtfile}; ${load_cmd} \\${fdt_addr_r} \\${load_prefix}\\${fdtfile}"'
env set set_apply_overlays 'env set apply_overlays "for overlay_file in \\${fdt_overlays}; do echo Applying Overlay: \\${overlay_file} && ${load_cmd_boot} \\${loadaddr} \\${overlays_prefix}\\${overlay_file} && fdt apply \\${loadaddr}; env set overlay_file; done; true"'
Best of luck!
/Rasmus