Easy installer TFTP boot fails on Verdin iMX8M Plus

Dear community,

I’ve ran into an issue while trying to boot the easy installer (tezi.itb) via TFTP. I’m using a similar approach mentioned in this subject here.

My first try is to just load the tezi.itb to a memory location on ram and execute bootm command:

tftp 0x47400000
bootm 0x47400000

Second approach is to mimic uuu.auto file and for this I use a slightly modified boot-tezi.scr. I was able to modify it using dumpimage and mkimage. I tried to remove anything not related to recovery mode:

env set bootcmd_hdp ';'
env set fdtfile ${fdt_prefix}imx8mp-verdin-wifi-dev.dtb
env set ramdisk_addr_r 0x47400000
env set vidargs 'drm.edid_firmware=edid/1280x720.bin video=HDMI-A-1:1280x720-16@60D video=HDMI-A-2:1280x720-16@60D'

env set bootcmd_args 'env set bootargs quiet ${vidargs} initcall_blacklist=vpu_driver_init rootfstype=squashfs root=/dev/ram autoinstall clk_ignore_unused pci=nomsi'

env set bootcmd 'run bootcmd_args && run bootcmd_hdp && run bootcmd_tezi && run bootcmd_run'

# Re-enable fdt relocation since in place fdt edits corrupt the ramdisk
# in a FIT image...
env set fdt_high

# Recovery mode
# Note: the memory locations are bound to the ones as used in uuu.auto
env set bootcmd_tezi ';'

env set fdt_high
env set fdt_resize true
env set fitconf_fdt_overlays

env set set_default_overlays 'env set fdt_overlays "verdin-imx8mp_native-hdmi_overlay.dtbo verdin-imx8mp_lt8912_overlay.dtbo"'

# Recovery-mode: load overlays.txt from the address provided by uuu utility
env set set_load_overlays_file 'env set load_overlays_file "env import -t 0x42e10000 0x200"'

env set set_apply_overlays 'env set apply_overlays "for overlay_file in \"\\${fdt_overlays}\"; do env set fitconf_fdt_overlays \"\\"\\${fitconf_fdt_overlays}#conf-\\${overlay_file}\\"\"; env set overlay_file; done; true"'

env set bootcmd_run 'echo "Bootargs: \${bootargs}" && bootm ${ramdisk_addr_r}#conf-\${fdtfile}\${fitconf_fdt_overlays}'

run set_load_overlays_file
run set_apply_overlays

run load_overlays_file
run apply_overlays

run bootcmd

After this, within uboot cmdline I load 3 files which I placed on TFTP server (same files and addresses used in uuu.auto) and source the script from it’s respective address:

tftp 0x42e00000; tftp 0x42e10000; tftp 0x47400000
source 0x42e00000

Each one of this approaches yields the same result:

Verdin iMX8MP # bootm 0x47400000
## Loading kernel from FIT Image at 47400000 ...
   Using 'conf-imx8mp-verdin-nonwifi-dahlia.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x47400108
     Data Size:    10805645 Bytes = 10.3 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x40000000
     Entry Point:  0x40000000
     Hash algo:    sha256
     Hash value:   32d1e3f705faa40dff47179c97d98d07f357db57f9a4ec84203ac09cf7b7ae23
   Verifying Hash Integrity ... sha256Error: Address arguments are not aligned
CAAM was not setup properly or it is faulty
Bad hash value for 'hash-1' hash node in 'kernel-1' image node
Bad Data Hash
ERROR: can't get kernel image!

I’m wondering why I’m getting a bad hash value and if I’m missing a step somewhere. When I try recovery mode via USB interface and recovery script from Verdin-iMX8MP_ToradexEasyInstaller_5.7.2+build.14 easy installer loads properly. I’m using the same files from Verdin-iMX8MP_ToradexEasyInstaller_5.7.2+build.14 (except the modified script) on TFTP server and the server is running on a windows machine.

Best regards,

1 Like

Hi @Marin ,

Thanks for the question.

Can you try the following steps and let me know if that works?

  1. tftp ${loadaddr} boot.scr
  2. tftp ${ramdisk_addr_r} tezi.itb
  3. source ${loadaddr}

EDIT: Are you installing a Toradex Image or a custom one?

Best Regards

Hi @kevin.tx,

Thanks for your reply.

I tried the steps you suggested and now the output is:

source ${loadaddr}
## Executing script at 48200000
Couldn't find partition : 0x47400000
Can't set block device

If I reload the tezi.itb image (i.e. run tftp ${ramdisk_addr_r} tezi.itb again), then I get the following output:

 source ${loadaddr}
## Executing script at 48200000
Wrong image format for "source" command

For this test I’ve used unmodified boot-tezi.scr and tezi.itb from Verdin-iMX8MP_ToradexEasyInstaller_5.7.2+build.14.
I already have a customized torizoncore image and my goal is to flash it via easy installer which was booted via TFTP.
I’m already able to successfully flash this firmware image using conventional methods (e.g. recovery mode + USB stick or web server). Our customer has a requirement to be able to flash the device from a local PC and to do it without physically interacting with the recovery pin, in this case SODIMM pin 246. This is why I’m considering this method.

Best regards,


I’ve also tried extracting from FIT image using dumpimage (U-Boot tools). I ended up with 3 files: devicetree.dtb, Image and ramdisk.cpio.

After placing them on TFTP server, I tried following commands:

tftpboot $kernel_addr_r Image
tftpboot $fdt_addr_r devicetree.dtb
tftpboot $ramdisk_addr_r ramdisk.cpio

Files successfully load to respective addresses and then I try to run the booti command, but I run into an issue with ramdisk image:

Verdin iMX8MP # booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r
## Loading ramdisk from FIT Image at 50300000 ...
Bad FIT ramdisk image format! (err=-42)
Ramdisk image is corrupt or invalid

From what I’ve read elsewhere, this could be caused by U-Boot version. Updating U-Boot could potentially fix this. Keeping the attention to my goal, i.e. getting the Easy installer to load without any physical interaction with the board it would be great if I could just load another U-Boot version from U-Boot during runtime, but I don’t think that is possible.


I’ve read here that bad hash could be caused by alignment issues, so I’ve tried the following:

Use -EB 0x40 when generating your image. This will use “external” data
(e.g. not within the dtb) which is aligned to 64 bytes.

To be more exact, with kernel image, device tree and ramdisk extracted from the original tezi.itb, I’ve used a custom image source tree file and generated a new image passing argument -EB 0x40 to the mkimage. I’m not sure if this offset value is correct, or where to confirm it. I’m getting a bad hash value this time as well, but with a slightly different output:

 Verifying Hash Integrity ... sha256dev_get_priv: null device
CAAM was not setup properly or it is faulty
Bad hash value for 'hash' hash node in 'kernel-1' image node
Bad Data Hash
ERROR: can't get kernel image!

Trying to do pretty much the same thing, and facing the same caam hash alignment problem. Did you manage to do any progress on this?

EDIT: I’m trying external media (SSD/USB), not TFTP. I’m facing the same issue though.

Hi @berganas,

I made some progress, haven’t solve the issue yet, however I’ve learned a couple of things along the way and have more understanding of how FIT image works.

There is one thing I did incorrectly while trying to extract elements of FIT image, i.e., I was using the wrong index for ramdisk image. With the following command:

dumpimage -l tezi.itb

I see that ramdisk is at index 25, so I run dumpimage again, on the correct index this time:

dumpimage -T flat_dt -p 25 -o kernel_image/ramdisk.cpio tezi.itb

With kernel image, ramdisk and device tree extracted this way, I try to load them to RAM via TFTP again, I run booti and U Boot still complains about the ramdisk:

booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r
   Uncompressing Kernel Image
Moving Image from 0x48200000 to 0x48280000, end=49c7e000
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid

If I omit the ramdisk and run like this: booti $kernel_addr_r - $fdt_addr_r the kernel actually loads, but then of course it complains about the missing root fs:

 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

I think I’m very close to getting it work in this extracted form (corrupted ramdisk is holding me back), although it would be nicer to be able to load the FIT image directly from U Boot.

After spending quite some time on this, I finally found a solution, or better call it a workaround. The approach with extracting the kernel image, ramdisk and fdt and repacking the FIT image proved successful, but with a slight twist. The hash algo needed to be changed in the image tree file, and after that I got easy installer to boot from U Boot. Here are all the steps:

  1. Modify the original boot-tezi.scr to something like this:
    boot.cmd (1.0 KB)

  2. Use dumpimage -l on tezi.itb to get the list of all images in FIT image

  3. Use dumpimage to extract kernel, ramdisk and dtb from tezi.itb

  4. Use information from step 2. to create an image tree like this:
    imagetree.its (1.5 KB)

Important: changing the hash algo from sha256 to md5 inside image tree file solved the problem for me.

  1. Use mkimage to create a new image with created image tree file, more info here

  2. I’m not using dhcp, so I just set the static IP address and server IP and proceed with following commands:

tftp 0x42e00000 boot.scr
tftp 0x47400000 your_newly_generated_tezi.itb
source 0x42e00000

That should do the trick!

Nice! That works for me too.
In my case, I didn’t need to modify the boot.scr either.
I’m using external media (SD/USB), so all I had to do is:

  1. Use dumpimage to extract kernel, ramdisk, and dtb from tezi.itb.
  2. Create an imagetree.its similar to yours, with md5 for hash algo.
  3. Use mkimage to recompile a custom tezi.itb.
  4. Place the new tezi.itb, along with the originally provided boot-tezi.scr (renamed to boot.scr), on the SD/USB.
  5. On u-boot, use bootcmd_mmc1 (SD) or bootcmd_usb0 (USB) to boot the new tezi image.

I also configured my custom torizoncore image to autoinstall and placed it on the same storage device, so the custom tezi auto-installed the custom torizoncore and rebooted.

Thanks for the help @Marin!

Great! Glad I could help.