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:
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
error!
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.
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.
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.
EDIT:
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
error!
Bad hash value for 'hash' hash node in 'kernel-1' image node
Bad Data Hash
ERROR: can't get kernel image!
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:
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:
Modify the original boot-tezi.scr to something like this: boot.cmd (1.0 KB)
Use dumpimage -l on tezi.itb to get the list of all images in FIT image
Use dumpimage to extract kernel, ramdisk and dtb from tezi.itb
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.
Use mkimage to create a new image with created image tree file, more info here
I’m not using dhcp, so I just set the static IP address and server IP and proceed with following commands:
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:
Use dumpimage to extract kernel, ramdisk, and dtb from tezi.itb.
Create an imagetree.its similar to yours, with md5 for hash algo.
Use mkimage to recompile a custom tezi.itb.
Place the new tezi.itb, along with the originally provided boot-tezi.scr (renamed to boot.scr), on the SD/USB.
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.
