U-Boot fitImage configuration node boot error with Apalis i.MX8QM, BSP 5.5.0

Hi!

I am working on a secure industrial platform for one of our projects, based on the Apalis iMX8QM 4GB IT V1.1B and an Ixora carrier board. The image I’m working on is based on the txd-reference-minimal-image. The modifications are made via local.conf changes and additional layers.

So far, I have used the BSP 5.3.0 quarterly version and integrated secure boot and a few other features into our image. It worked great until I ported our image to the latest quarterly BSP 5.5.0 reference image, which broke the boot process because it says it cannot find the configuration node in the fitImage (log at the bottom).
If I load the fitImage into memory with fatload in U-Boot and boot it using bootm, it verifies the fitImage and boots (with a few minor hiccups that I believe happen due to the “raw” booting and a few unset variables). However, If I just let it boot after powerup, it hangs.

For the secure boot I

  • created an apalis-imx8_defconfig.patch file to enable CONFIG_AHAB_BOOT in the U-Boot (required for enforcing secure boot in NXP chip level)
  • set up the U-Boot fitImage with the local.conf modifications, seen at the bottom.

Apart from these changes, I did not make modifications to the U-Boot.

With BSP 5.3.0 it worked great. I verified every stage by modifying different parts of the imx-boot and the fitImage images. With BSP 5.5.0 it does not work; however, I can see that TEZI still uses fitImages, so I believe the fitImage feature itself is still supported.

I compared the Tezi U-Boot defconfig, and the used settings, with the ones the minimal image provides; I compared the BSP 5.3.0 and the BSP 5.5.0; I compared the boot logs, U-Boot env vars, etc., but I cannot seem to locate the changes that broke the fitImage boot process for me. The only difference I can see in the fitImage config is that now instead of @ the image uses - as in kernel-1 instead of kernel@1.

I tried to use BSP 5.5.0, BSP 5.5.0-devel-202112, BSP 5.4.0, dunfell-5.x.y, but the U-Boot will only load the fitImage properly if I use the “original” BSP 5.3.0 reference image.
I also tried clean building the whole project several times (completely removed sstate too), but it did not help.

Could you please help me find what I should change in the image to fix the fitImage boot process? We need to use the BSP 5.5.0 because it contains an updated SCFW, required for enforcing the Secure Boot on the chip level.

Many thanks,
Csongor

U-Boot log with hang fitImage

U-Boot 2020.04-5.5.0-devel+git.81bc8894031d (Nov 30 2021 - 11:36:12 +0000)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

DRAM:  4 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Apalis iMX8 QuadMax 4GB IT V1.1C, Serial# 06852556

 BuildInfo:
  - SCFW 778670e2, SECO-FW d63fdb21, IMX-MKIMAGE 8947fea3, ATF 835a8f6
  - U-Boot 2020.04-5.5.0-devel+git.81bc8894031d

switch to partitions #0, OK
mmc0(part 0) is current device
flash target is MMC:0
Net:   eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0
MMC: no card present
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
5754 bytes read in 22 ms (254.9 KiB/s)
## Executing script at 83100000
** Bad device specification ${boot_devtype} ${boot_devnum} **
** Bad device specification ${boot_devtype} ${boot_devnum} **
Loading hdp firmware from 0x000000009c000000 offset 0x0000000000002000
Loading hdp firmware Complete
43 bytes read in 12 ms (2.9 KiB/s)
13582914 bytes read in 422 ms (30.7 MiB/s)
Bootargs: pci=nomsi root=PARTUUID=f1045e45-02 ro rootwait
## Loading kernel from FIT Image at 8a000000 ...
Could not find configuration node
ERROR: can't get kernel image!
Booting from mmc failed!
SCRIPT FAILED: continuing...
starting USB...
Bus usb@5b0d0000: usb dr_mode not found
Port not available.
Bus usbh3: XHCI-imx8 init hccr 0x000000005b130000 and hcor 0x000000005b130080 hc_length 128
Register 2000820 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usbh3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
BOOTP broadcast 1
DHCP client bound to address 10.85.10.100 (2 ms)
Using ethernet@5b040000 device
TFTP from server 10.85.15.254; our IP address is 10.85.10.100
Filename 'boot.scr'.
Load address: 0x83100000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
BOOTP broadcast 1
DHCP client bound to address 10.85.10.100 (3 ms)
Using ethernet@5b040000 device
TFTP from server 10.85.15.254; our IP address is 10.85.10.100
Filename 'pxelinux.0'.
Load address: 0x80280000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Apalis iMX8 #

U-Boot fitImage related local.conf modifications

# Enable fitimage kernel creation and thus kernel signing
KERNEL_CLASSES_append = " toradex-fitimage"
KERNEL_IMAGETYPE_forcevariable = "${@'zImage' if d.getVar('TORADEX_FLASH_TYPE') == 'rawnand' else 'fitImage'}"

# Enable kernel signing for uboot
UBOOT_SIGN_KEYDIR = "/workdir/keys/fitimage-signing-keys/active_key/"
UBOOT_SIGN_KEYNAME = "fitimage"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_SIGN_ENABLE = "1"

Greetings @csongor.ferenczi,

instead of @ the image uses - as in kernel-1 instead of kernel@1 .

I believe this small change might actually be the cause or related to the issue. It seems this change was done in the dunfell branch here: kernel-fitimage: Don't use unit addresses on FIT · openembedded/openembedded-core@14eec2f · GitHub

Then it was probably pulled in by us when updating our layers for 5.5.0. However if you see the bootscript we use: boot.cmd.in « u-boot-distro-boot « u-boot « recipes-bsp - meta-toradex-bsp-common.git - Toradex BSP layer, recipes common to all modules

Notice that for the bootcmd_boot:

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

We still refer to the chosen conf node using @ instead of -. I believe this is the issue and may explain why U-Boot can’t find the conf node anymore.

Please try adjusting this in the boot script then give it another try and let me know if it works. If so then I’ll see about reporting this so our team can fix the script on our side.

Best Regards,
Jeremias

@jeremias.tx, I cannot express my gratitude towards you! The typo was the problem.

I created the recipes-bsp/u-boot/u-boot-distro-boot.bbappend file in our layer with the following content:

do_install_prepend () {
    sed -i -e 's/conf@/conf-/' "${WORKDIR}/boot.cmd.in"
}

I verified that the freshly baked image contains the fix, booted the device, and it worked!

U-Boot boot log

U-Boot 2020.04-5.5.0-devel+git.81bc8894031d (Nov 30 2021 - 11:36:12 +0000)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

DRAM:  4 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Apalis iMX8 QuadMax 4GB IT V1.1C, Serial# 06852556

 BuildInfo:
  - SCFW 778670e2, SECO-FW d63fdb21, IMX-MKIMAGE 8947fea3, ATF 835a8f6
  - U-Boot 2020.04-5.5.0-devel+git.81bc8894031d

switch to partitions #0, OK
mmc0(part 0) is current device
flash target is MMC:0
Net:   eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0
MMC: no card present
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
5754 bytes read in 21 ms (267.6 KiB/s)
## Executing script at 83100000
** Bad device specification ${boot_devtype} ${boot_devnum} **
** Bad device specification ${boot_devtype} ${boot_devnum} **
Loading hdp firmware from 0x000000009c000000 offset 0x0000000000002000
Loading hdp firmware Complete
43 bytes read in 12 ms (2.9 KiB/s)
13582914 bytes read in 421 ms (30.8 MiB/s)
Bootargs: pci=nomsi root=PARTUUID=f900f8e7-02 ro rootwait
## Loading kernel from FIT Image at 8a000000 ...
   Using 'conf-imx8qm-apalis-v1.1-eval.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x8a000114
     Data Size:    12192653 Bytes = 11.6 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x80280000
     Entry Point:  0x80280000
     Hash algo:    sha256
     Hash value:   b494ab996c8066f0ba1100d61faa00ea92f008d826bcec53c77003d718da4be8
   Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at 8a000000 ...
   Using 'conf-imx8qm-apalis-v1.1-eval.dtb' configuration
   Trying 'fdt-imx8qm-apalis-v1.1-eval.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x8abf2ad4
     Data Size:    166807 Bytes = 162.9 KiB
     Architecture: AArch64
     Load Address: 0x83000000
     Hash algo:    sha256
     Hash value:   74f8ec3967d9fbd331467cfd6668341c9e38bacae6664f0c728dcfbeeb2837a0
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x8abf2ad4 to 0x83000000
## Loading fdt from FIT Image at 8a000000 ...
   Using 'conf-apalis-imx8_hdmi_overlay.dtbo' configuration
   Trying 'fdt-apalis-imx8_hdmi_overlay.dtbo' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x8ace9f60
     Data Size:    2177 Bytes = 2.1 KiB
     Architecture: AArch64
     Load Address: 0x83100000
     Hash algo:    sha256
     Hash value:   75d00dae6d1d5de88ccd2ea8be1ba975496ee7a8d507eae6b5871089b4bd45f4
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x8ace9f60 to 0x83100000
   Booting using the fdt blob at 0x83000000
   Uncompressing Kernel Image
   Loading Device Tree to 00000000fd620000, end 00000000fd64bb5a ... OK

Starting kernel ...

Thank you so much for your lightning fast help! I really appriciate it!

Sincerely,
Csongor

Glad to hear it was just a simple issue. Thank you for reporting back that it works for you. I’ll go ahead and forward this back to our team to fix on our side.

Best Regards,
Jeremias

1 Like