Boot Easy Installer from USB/SD

Technical Support
, , ,
1

Hello Community,

I know this subject has already been somehow answered several times.

I also know that loading tezi from sd or usb disk is not supported. However, in cases where I have to flash again a module while I’m unable to put it in recovery mode and it’s not possible to remove the module itself from the board, it is very useful to be able to flash from a simple usb key.

In order to do that I changed the u-boot env variable boot_targets to have usb0 as first choice. Everything worked fine until a few days ago.

It seems that u-boot is longer able to boot tezi. This is what i get from the serial:

Boot log 
U-Boot SPL 2024.07-7.6.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
SEC0:  RNG instantiated
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
Trying to boot from MMC1
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.10.0	(release):lf-6.6.52-2.2.1-dirty
NOTICE:  BL31: Built : 06:40:36, Jul  7 2025

U-Boot 2024.07-7.6.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)

CPU:   Freescale i.MX8MMQ rev1.0 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 55C
Reset cause: POR
DRAM:  2 GiB
Core:  150 devices, 26 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC… Reading from MMC(0)… OK
In:    serial@30860000
Out:   serial@30860000
Err:   serial@30860000
Model: Toradex 0055 Verdin iMX8M Mini Quad 2GB WB IT V1.1F
Serial#: 15702494
Carrier: Toradex Verdin Development Board V1.1F, Serial# 11490726
SEC0:  RNG instantiated
Setting variant to wifi
Net:   eth0: ethernet@30be0000 [PRIME]
Hit any key to stop autoboot:  0
starting USB…
Bus usb@32e40000: Bus usb@32e50000: USB EHCI 1.00
scanning bus usb@32e40000 for devices… 1 USB Device(s) found
scanning bus usb@32e50000 for devices… 4 USB Device(s) found
scanning usb for storage devices… 1 Storage Device(s) found

Device 0: Vendor: General  Rev: 5.00 Prod: UDisk
Type: Removable Hard Disk
Capacity: 30500.0 MB = 29.7 GB (62464000 x 512)
… is now current device
Scanning usb 0:1…
Found U-Boot script /boot.scr
2071 bytes read in 2 ms (1010.7 KiB/s)

Executing script at 50280000

86 bytes read in 2 ms (42 KiB/s)
40085291 bytes read in 1721 ms (22.2 MiB/s)
Bootargs: video=HDMI-A-1:1280x720@60D console=ttymxc0,115200 quiet rootfstype=squashfs root=/dev/ram autoinstall

Loading kernel from FIT Image at 44200000 …

Could not find configuration node
ERROR -2: can’t get kernel image!
SCRIPT FAILED: continuing…
MMC: no card present
Card did not respond to voltage select! : -110
No EFI system partition
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
Loading Boot0000 ‘mmc 0’ failed
Loading Boot0001 ‘usb 0’ failed
EFI boot manager: Cannot load any image
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found U-Boot script /boot.scr
5389 bytes read in 1 ms (5.1 MiB/s)
Executing script at 50280000
Loading DeviceTree: imx8mm-verdin-dlc50.dtb

At this point the flashed image starts.

I tried with usb key and sd card, also using the tezi 7.6.0+build.11 (I guess is the last one available). In the key, in general, I copy the boot.scr and tezi.itb but I tried also to copy all the files in the .zip package, just in the case something is missing. To avoid any possible issues I put in the key only the tezi files, without the Linux image to be flashed.

If I flash (with recovery) an older image, built 1 month ago, then I’m able to boot tezi. I can only guess there was a sync of the metas (repo sync) between builds, unfortunately I wasn’t able to track that, but it is the only explanation I’ve found to explain this behavior. I also noticed that u-boot bin is different.

Following this article, I guess there might be something that needs to be changed in boot.scr.

I’m having this problem even with the Verdin Development Board.

HW and SW in use:

tdx-info 
Software summary

Bootloader:               U-Boot
Kernel version:           6.6.119-7.6.0-devel #1 SMP PREEMPT Fri Feb 27 14:36:24 UTC 2026
Kernel command line:      root=PARTUUID=692bf278-02 ro rootwait console=tty1 console=ttymxc0,115200
Distro name:              NAME=“TDX Wayland with XWayland”
Distro version:           VERSION_ID=7.6.0-devel-20260306134045-build.0
Distro variant:           -
Hostname:                 DL-15702494-18H54

Hardware info

HW model:                 Toradex Verdin iMX8M Mini WB on DLC50 Platform
Toradex version:          0055 V1.1F
Serial number:            15702494
Processor arch:           aarch64

And by the way, I had in the past the same issue with the Colibri iMX8X.

For sure I’m doing something wrong, but what?

Thank you for your kind help

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

The issue you’re encountering with Toradex Easy Installer (TEZI) not booting from USB appears to be related to the FIT image configuration. Based on your boot log, the error “Could not find configuration node” suggests that U-Boot cannot locate the proper configuration within the tezi.itb file.

Understanding the Boot Process

When U-Boot attempts to boot from USB, it follows the DistroBoot sequence defined by the boot_targets variable(1). The error occurs when U-Boot tries to load the kernel from the FIT image but cannot find the appropriate configuration node.

Environment Variable Configuration

You can modify the boot sequence using U-Boot environment variables. The boot_targets variable defines the order in which U-Boot probes boot sources(1). For example:

> setenv boot_targets "usb0 mmc1 mmc2 dhcp"
> saveenv

(1)

Troubleshooting Steps

1. Verify Boot Script Contents

Ensure your boot.scr on the USB device is properly formatted for your specific hardware configuration. The boot script should match the device tree requirements for your Verdin iMX8M Mini.

2. Check FIT Image Integrity

The tezi.itb file might have configuration issues. Try using a fresh download of TEZI 7.6.0+build.11 and verify the file integrity.

3. Device Tree Considerations

Since you mentioned this works with older images, there might be device tree changes affecting the boot process. The error suggests the FIT image configuration doesn’t match what U-Boot expects for your hardware variant.

4. Alternative Recovery Method

If you need to recover the module without removing it from the board, consider using the U-Boot console to manually load and boot TEZI:

> usb start
> load usb 0:1 ${loadaddr} tezi.itb
> bootm ${loadaddr}

(1)

Additional Debugging

To get more detailed information about the FIT image structure, you can use U-Boot’s iminfo command to inspect the tezi.itb file and verify its configuration nodes.

The fact that this works with older U-Boot versions suggests there may have been changes in the FIT image handling or device tree configuration between builds. You might want to compare the U-Boot configuration between your working and non-working builds.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello,

Ok, however mine is a bit different:

Verdin iMX8MM # printenv boot_targets
boot_targets=usb0 mmc1 mmc0 dhcp

1:

Ok, I guess this explains why TDX is releasing a version for each module. The one I’m using is the right one: usb otg approach is working.

2: Done
3: There (should) be the right dtb inside the .itb image. Checked fdt-freescale_imx8mm-verdin-wifi-dev.dtb in the 7.6.0-build11.

4: This is actually interesting, but, I got an error:

U-boot log 
Verdin iMX8MM # usb start
starting USB...
Bus usb@32e40000: Bus usb@32e50000: USB EHCI 1.00
scanning bus usb@32e40000 for devices... 1 USB Device(s) found
scanning bus usb@32e50000 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Verdin iMX8MM # load usb 0:1 ${loadaddr} tezi.itb
40085291 bytes read in 1700 ms (22.5 MiB/s)
Verdin iMX8MM # bootm ${loadaddr}
## Loading kernel from FIT Image at 48200000 ...
   Using 'conf-freescale_imx8mm-verdin-nonwifi-dahlia.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x482000f0
     Data Size:    7455534 Bytes = 7.1 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48200000
     Entry Point:  0x48200000
     Hash algo:    sha256
     Hash value:   1066916f150e7b19ec435caaa4689621b6744b76ac58cbfb2d87aea32f7a98d3
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 48200000 ...
   Using 'conf-freescale_imx8mm-verdin-nonwifi-dahlia.dtb' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  tezi-initramfs
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x489c4444
     Data Size:    31936512 Bytes = 30.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x52300000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   2f36772e1f9d3027dece4cc2f2703b2448e6ea942d6e3429e47240074d4a766e
   Verifying Hash Integrity ... sha256+ OK
   Loading ramdisk from 0x489c4444 to 0x52300000
## Loading fdt from FIT Image at 48200000 ...
   Using 'conf-freescale_imx8mm-verdin-nonwifi-dahlia.dtb' configuration
   Trying 'fdt-freescale_imx8mm-verdin-nonwifi-dahlia.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4891c54c
     Data Size:    65437 Bytes = 63.9 KiB
     Architecture: AArch64
     Load Address: 0x50200000
     Hash algo:    sha256
     Hash value:   2151c092fdc27296bdc3c14bee4e63c2b061a8f1b8d1f9e38721db70ffe23924
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x4891c54c to 0x50200000
   Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
   Uncompressing Kernel Image to 48200000
Error: inflate() returned -3
gzip compressed: uncompress error -1
Must RESET board to r
U-Boot SPL 2024.07-7.6.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
SEC0:  RNG instantiated
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)

after that, a new boot begins.

Ok, kernel image and many dtbs are there, but it’s not helpful.

In the meantime, I did another repo sync, rebuilt the image, flashed with otg. Still same error.

4

The decompression error you’re encountering indicates a potential memory overlap issue when manually loading the TEZI image. The error “inflate() returned -3” suggests the kernel decompression failed, likely due to memory address conflicts.

Root Cause Analysis

The issue appears to be related to the FIT image configuration selection. When you manually boot with bootm ${loadaddr}, U-Boot selects the configuration conf-freescale_imx8mm-verdin-nonwifi-dahlia.dtb, but your module is a Wi-Fi variant (as shown by “Setting variant to wifi” in your boot log).

Troubleshooting Steps

1. Check Device Tree Configuration

Your boot log shows U-Boot is setting the variant to “wifi”, but the FIT image is trying to use the non-wifi configuration. The fdtfile variable should match your hardware variant(1).

You can check and modify this in U-Boot:

> printenv fdtfile
> setenv fdtfile imx8mm-verdin-wifi-dev.dtb
> saveenv

(1)

2. Memory Address Considerations

The decompression error suggests memory overlap. Try loading the image to a different address:

> load usb 0:1 0x50000000 tezi.itb
> bootm 0x50000000

3. Boot Script Analysis

Since the automatic boot from USB fails with “Could not find configuration node”, the issue is likely in how the boot script (boot.scr) selects the FIT configuration. The boot script should properly detect your Wi-Fi variant and select the appropriate configuration node.

4. Alternative Boot Target Configuration

Based on the community discussion, you can modify the U-Boot environment to include USB as a boot target with fallback to eMMC(2). Your current configuration looks correct:

boot_targets=usb0 mmc1 mmc0 dhcp

(1)

5. Verify Boot Script Compatibility

The boot script in your TEZI package might not be compatible with the newer U-Boot version. Try using the boot-tezi.scr file renamed to boot.scr as suggested in the community forum(2).

Recommended Solution

  1. Download a fresh TEZI package for your specific module variant (Wi-Fi version)
  2. Rename boot-tezi.scr to boot.scr on your USB device(2)
  3. Ensure compatibility between your BSP version and the TEZI version

The fact that this worked with older builds suggests there have been changes in either the U-Boot FIT image handling or the device tree configuration detection between BSP versions.

Alternative Recovery Method

If USB boot continues to fail, you might need to use the serial console to access U-Boot and manually configure the environment variables to force the correct device tree selection before attempting to boot TEZI.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

This is the solution:

I added the variable fdtfile in the u-boot env to statically use my dtb, but in this way u-boot looks for that dtb in the .itb image.
I will add a guard to use default fdtfile in case of boot from USB.

Thanks (AI) !!!

:balloon: