YOCTO secure boot imx7 eMMC build failure

pfarre · February 24, 2025, 12:10pm

Hi, trying to move from imx7d NAND to eMMC and build secure boot.

Seems to be 2 problems - not sure which is the error that fails at the end?

Yocto keeps building several device trees - I tried this Removing not needed files from bootfs but still all eval boards are built and skips before the custom device tree.
Then there is the actual fail - where there are a few messages, that could relate to it.

a)

test -e arch/arm/dts/imx7d-colibri-emmc-eval-v3.dtb || (						\
echo >&2;							\
echo >&2 "Device Tree Source (arch/arm/dts/imx7d-colibri-emmc-eval-v3.dtb) is not correctly specified.";	\
echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'";		\
echo >&2 "or build with 'DEVICE_TREE=<device_tree>' argument";	\
echo >&2;							\
/bin/false)
  cat arch/arm/dts/imx7d-colibri-emmc-eval-v3.dtb > dts/dt.dtb
  cp dts/dt.dtb u-boot.dtb
Failed to add verification data for 'signature-1' signature node in 'conf-nxp_imx_imx7d-colibri-emmc-aster.dtb' configuration node
FIT description: Kernel fitImage for TDX Wayland with XWayland Upstream/6.6/colibri-imx7-emmc
Created:         Thu Jan  2 09:32:11 2025

b)
Could not find subimage node type ‘ramdisk’

c)

test -e u-boot.dtb-signed || (						\
echo >&2;							\
echo >&2 "Device Tree Source (u-boot.dtb-signed) is not correctly specified.";	\
echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'";		\
echo >&2 "or build with 'DEVICE_TREE=<device_tree>' argument";	\
echo >&2;							\
/bin/false)
  cat u-boot.dtb-signed > dts/dt.dtb
  cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
  cp u-boot-dtb.bin u-boot.bin
make -f /home/pef/oe-core/build/tmp/work/colibri_imx7_emmc-tdx-linux-gnueabi/u-boot-toradex/2024.07/git/scripts/Makefile.build obj=arch/arm/mach-imx u-boot.imx
mkdir -p ./
  ./tools/mkimage -n u-boot.cfgout -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx >u-boot.imx.log  && cat u-boot.imx.log

Any suggestions ?

ToradexAI · February 24, 2025, 12:11pm

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello,

To address the issues you’re encountering with your Yocto build for the iMX7D platform, let’s tackle each problem separately:

Unnecessary Device Tree Builds:
- Yocto often builds multiple device trees by default. To control this, you can specify the desired device tree in your build configuration. You can set the CONFIG_DEFAULT_DEVICE_TREE variable in your U-Boot configuration to specify the exact device tree you want to build. This can be done by adding a line like CONFIG_DEFAULT_DEVICE_TREE="imx7d-colibri-emmc-custom" in your U-Boot configuration file.
- Alternatively, during the build process, you can pass the DEVICE_TREE=<your_device_tree> argument to specify the exact device tree to use. Ensure that the device tree name matches the file you intend to use.
Build Failure and Error Messages:
- The error message regarding the device tree source not being correctly specified suggests that the build system cannot find the specified device tree file. Ensure that the device tree file imx7d-colibri-emmc-eval-v3.dtb exists in the expected directory. If you are using a custom device tree, make sure it is correctly named and placed in the appropriate directory.
- For the secure boot error related to the signature node, ensure that your device tree is correctly configured for secure boot. This involves ensuring that the device tree includes the necessary nodes for secure boot and that the keys used for signing are correctly configured.
- The message about the missing ‘ramdisk’ subimage node indicates that the build process expects a ramdisk image that is not provided. Verify your build configuration to ensure all required components are included.

By addressing these configuration issues, you should be able to resolve the build errors and successfully transition to using eMMC with secure boot on your iMX7D platform.

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

OPTEE Support on IMX7D.

henrique.tx · February 25, 2025, 5:40pm

Hi, @pfarre!

Regarding having several device trees please check the threads below the related documentation and other threads about it:

Regarding the failure when building, I would like to go through some topics:

Since you are migrating from a NAND module to an eMMC, is it possible that some of your NAND-specific is bringing some issue to the eMMC module?
Have you tried to build the default Reference Minimal Image for colibri-imx7-emmc? This is a good thing to try out (like a “hello world” just to check if your setup is healthy).
As for the image with secure boot, are you using our meta-toradex-security layer? This is they way-to-go to have a smoother experience:

This is the related documentation in Toradex Developer: https://developer.toradex.com/torizon/security/secure-boot-on-torizoncore/

Best regards,

pfarre · February 26, 2025, 7:58am

Hi, thanks for the answers.

I tried the Removing not needed files from bootfs and the suggestions from the AI, but still all the eval,aster and iris DTBs are built - not really sure what i am doing wrong…

I am using meta-toradex-security and joined the webinar on secure boot if i comment out the INHERIT += “tdx-signed” i get a bootable custom image on emmc using EasyInstaller.

With the INHERIT active the kernel and DTB’s are built but result is
…/u-boot-toradex_2024.07.bb:do_uboot_assemble_fitimage) failed with exit code ‘1’

The results for bitbake tdx-reference-minimal-image are the same.

btw. can i attach a file instead of inline 600 lines of log ?

henrique.tx · February 26, 2025, 12:24pm

Hi, @pfarre !

Oh, yeah… sorry. You are talking about device trees and I shared stuff related to device tree overlays. My bad.

Please share exactly how you tried, so we can take a look at it.

I see. That’s good: it indicates that you are able to build the Reference Image.

That’s a long log
Please try using this button when you are replying

Best regards,

pfarre · February 26, 2025, 1:48pm

Added layer meta-bdsk-imx7 to bblayers.conf
Added recipes-kernel/linux/linux-toradex/my-custom-devicetree.dts
Added oe-core/layers/meta-bdsk-imx7/conf/machine/colibri-imx7d-extra.conf
include extra.conf in meta-bdsk-imx7/conf/layer.conf

first setting KERNEL_DEVICETREE:append = “nxp/imx/my-custom-devicetree.dtb” and the devicetree is built together with the eval board DTB’s

change to KERNEL_DEVICETREE:colibri-imx7-emmc = “nxp/imx/my-custom-devicetree.dtb” - only the eval board DTB’s are built

change to KERNEL_DEVICETREE = “nxp/imx/my-custom-devicetree.dtb” also only the eval board ones are built.

also tried with a space before nxp KERNEL_DEVICETREE = " nxp/imx/my-custom-devicetree.dtb"

Also tried setting my layer priority to 6 , 25(highest) and 9

So far at best my devicetree is built together with the others.

Also tried setting DEVICE_TREE in local.conf

!!! and now while writing i see that i may be confusing DEVICE_TREE, CONFIG_DEFAULT_DEVICE_TREE and KERNEL_DEVICETREE variables. And that i should set my layer back to priority 25

Unless you see something obvious, i might look things througt one more if i set the right variable - but they all 3 need to be right.

Regards Paul

henrique.tx · February 27, 2025, 6:31pm

Hi @pfarre !

If the tips from the other thread aren’t working for you, I would need to take a closer look.

But I see you still have some stuff to try on your side.

Let us know how it goes and if it isn’t solved, I will try on my side.

Best regards,

pfarre · March 4, 2025, 7:30am

Hi,
i started all over with a new Yocto repo and only try to build tdx-reference-minimal with tdx-signed - with all at default (exept the catalog where CST is placed) it builds but the fit image key is NULL even though it autogenerates the keys (FIT_GENERATE_KEYS = “1”)

Loading kernel from FIT Image at 88400000 …

Using ‘conf-nxp_imx_imx7d-colibri-emmc-eval-v3.dtb’ configuration
Verifying Hash Integrity … sha256,rsa2048:dev- error!
Verification failed for ‘’ hash node in ‘conf-nxp_imx_imx7d-colibri-emmc-e val-v3.dtb’ config node
Failed to verify required signature ‘key-dev2’
Bad Data Hash
ERROR -2: can’t get kernel image!

btw. Do you have a working example local.conf for tdx-reference-minimal-image and colibri-imx7-emmc
(path to cst and keys ofcourse custom)

Regards Paul

henrique.tx · March 4, 2025, 1:02pm

Hi @pfarre !

Just to be sure, have you followed the READMEs from the layer?

github.com

toradex/meta-toradex-security/blob/scarthgap-7.x.y/docs/README-secure-boot.md

# Secure boot

Secure boot has the objective of protecting the integrity and authenticity of the operating system components (bootloader, kernel, root filesystem, etc) at boot time.

Secure boot is currently supported on the following SoMs:

- Apalis iMX6
- Apalis iMX8
- Colibri iMX6DL
- Colibri iMX6ULL (1GB eMMC variant only)
- Colibri iMX7D (1GB eMMC variant only)
- Colibri iMX8X
- Verdin AM62
- Verdin iMX8MM
- Verdin iMX8MP

## Secure boot implementation

The secure boot implementation provided by this layer is based on the verification of digital signatures, where every component of the operating system is signed, and its signature is checked at boot time.

This file has been truncated. show original

github.com

toradex/meta-toradex-security/blob/scarthgap-7.x.y/docs/README-secure-boot-imx.md

# Bootloader signature checking for NXP iMX-based platforms

This document describes how bootloader signature checking works for System on Modules (SoMs) that use iMX-based System on Chips (SoCs) by NXP Semiconductors.

## Introduction

To support bootloader signature checking, such a feature needs to be available in the SoC ROM code.

On iMX6, iMX7 and iMX8M, this feature is available and it is called HAB (High Assurance Boot).

On iMX8 and iMX8X, this feature is available and it is called AHAB (Advanced High Assurance Boot).

## Configuring HAB/AHAB support

When the `tdx-signed` class is inherited, signing bootloader images via HAB/AHAB is enabled by default. Set `TDX_IMX_HAB_ENABLE` to `0` to disable it.

Before using this feature, it is required to:

1. Download NXP CST tool from https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL_NEW.
2. Follow the NXP documentation to generate the keys, certificates, SRK tables and Efuse Hash (the documentation can be found inside the CST tool in `docs/CST_UG.pdf`); be sure to take note of your answers to the key generation script.

This file has been truncated. show original

There are others regarding encryption, optee, data partition as well.

I will check for it. Could you please share yours in the meantime?

Best regards,

pfarre · March 4, 2025, 1:11pm

here my build/conf/local.conf
local.conf.txt (15.4 KB)

henrique.tx · March 4, 2025, 2:16pm

Hi @pfarre !

Thanks for the file!

Could you please also check this question. It is important to be sure about the details

Best regards,

pfarre · March 4, 2025, 3:48pm

Hi,
yes i followed the README, i should think that the fused keys match the u-boot. I have not changed any of the TDX_SECBOOT_WL_ALLOW_OPEN and CLOSED variables.
And only made changes to local.conf and bblayer.conf which was my impression from tha webinar should be enough - but i might be mistaken.

Regards Paul

henrique.tx · March 4, 2025, 3:54pm

Hi @pfarre !

Thank you for the information.

We will check and get back to you on this as soon as possible.

In the meantime, if you have further information, let us know

Best regards,

pfarre · March 5, 2025, 11:43am

additional info, hope its usefull:

1. The keys for fit image are created as expected

ls /home/pef/Downloads/CST/cst-3.4.1/keys/fit -als
4 -rw-r--r-- 1 pef pef 1245 Feb 28 14:02 dev2.crt
4 -rw------- 1 pef pef 1704 Feb 28 14:02 dev2.key
4 -rw-r--r-- 1 pef pef 1245 Feb 28 14:02 dev.crt
4 -rw------- 1 pef pef 1704 Feb 28 14:02 dev.key

2. From the boot prompt:

Colibri iMX7 # ls mmc 0:1
## WARNING: Command execution WOULD BE DENIED in closed state (blocked by category) for `ls mmc 0:1`.
  8281129   fitImage
       51   overlays.txt
     5948   boot.scr

3. Is this correct ?

Colibri iMX7 # hab_status
*Secure boot disabled*
HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

4. Reversing the u-boot…dtb

        signature {
                key-dev2 {
                        required = "conf";
                        algo = "sha256,rsa2048";
                        rsa,r-squared = < 0x....
                        rsa,modulus = <0x...
                        rsa,exponent = <0x00 0x10001>;
                        rsa,n0-inverse = <0x.... >;
                        rsa,num-bits = <0x800>;
                        key-name-hint = "dev2";
                };
        };

pfarre · March 10, 2025, 1:23pm

Hi Good News
3rd time is the lucky…

I started the whole repo over again, deleted the fit image keys from CST and bitbaked the tdx-signed image with the local.conf and bblayer.conf from the previous attempts.

And its verifying and booting !

My theory is that as soon as the image without tdx-signed has been built or if its built in steps, something does not rebuild due to maybe missing dependency rules or something is cached and reused. I did bitbake world -c cleanall and -c cleansstate between bakes on the sesond repo several times but the keys were not updated in the fitimage.

btw. is it possible on the build system to check the keys from the dtc decompile of the dtb wether they pair up with the fitimage signature ?

Regards Paul

pfarre · March 13, 2025, 5:55am

A few minor issues

1). i saw something about PARTUUID in BOOTARGS but cant refind it (how to avoid PARTUUID in bootargs) - obviously a general ‘root=’ is needed and not something that changes with each module.

 WARNING: Initial part of passed bootargs string (A) does not match ‘required-bootargs’ property (B) in device-tree.

 A: “ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=2a83a1a2-02”

 B: “ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=0bd3ab9c-02”

 WARNING: Allowing boot while device is open; please fix bootargs before closing device.

Changed to root=/dev/mmcblk0p2 but found that its boot.scr that sets the rootfsargs2 env var. The recipe for boot.scr should then ideally adapt to TDX_SECBOOT_REQUIRED_BOOTARGS (suggestion )

2a)

Loading fdt from 0x88bb6840 to 0x88200000

 Loading fdt from FIT Image at 88400000 …

Using ‘conf-colibri-imx7-emmc-secboot-kargs_overlay.dtbo’ configuration
Verifying Hash Integrity … sha256,rsa2048:dev+ OK
Trying ‘fdt-colibri-imx7-emmc-secboot-kargs_overlay.dtbo’ fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x88be0c30
Data Size: 418 Bytes = 418 Bytes
Architecture: ARM
Load Address: 0x88300000
Hash algo: sha256
Hash value: xxxxx
Verifying Hash Integrity … sha256CACHE: *Misaligned operation* at range [88be0c30, 88be0df0]

OK

2b)

 Loading fdt from FIT Image at 88400000 …

Using ‘conf-colibri-imx7_vga-640x480_overlay.dtbo’ configuration
Verifying Hash Integrity … sha256,rsa2048:dev+ OK
Trying ‘fdt-colibri-imx7_vga-640x480_overlay.dtbo’ fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x88be3610
Data Size: 1352 Bytes = 1.3 KiB
Architecture: ARM
Load Address: 0x88300000
Hash algo: sha256
Hash value: xxxx
Verifying Hash Integrity … sha256CACHE: *Misaligned operation* at range [88be3610, 88be3b90]

OK

Regards Paul

henrique.tx · March 14, 2025, 3:44pm

Hi @pfarre !

I asked internally for some help on this topic and, to be honest, there was some confusion about the actual issue you are currently facing (if any).

If you have any current issue (or doubt) could you kindly summarize it/them so it is easier for us to help you?

Best regards,

pfarre · March 17, 2025, 6:13am

Hi, sorry for the confusion.

After the complete start over with new repo there are only 2 minor issues.

How to get the bootargs to work - getting TDX_SECBOOT_REQUIRED_BOOTARGS and the bootargs from boot.scr to match. I expect that PARTUUID will change for each module. The only solution is to make a recipe to change boot.scr ? - or are there any builtin solutions in meta-toradex-security
I get this message

Verifying Hash Integrity … sha256CACHE: *Misaligned operation* at range [88be0c30, 88be0df0]

henrique.tx · March 17, 2025, 4:42pm

Hi @pfarre !

Thanks for the summary.

The team is checking, and we will get back to you.

Best regards,

henrique.tx · March 18, 2025, 1:03pm

Hi @pfarre !

From your local.conf, we see:

TDX_SECBOOT_REQUIRED_BOOTARGS = "ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=0bd3ab9c-02"

So, you have the fixed part (ro rootwait console=tty1 console=ttymxc0,115200) and the variable/dynamic part (root=PARTUUID=0bd3ab9c-02). And TDX_SECBOOT_REQUIRED_BOOTARGS is meant only for the fixed part of the kernel command line arguments.

Have you tried to build without adding the root=PARTUUID=... to TDX_SECBOOT_REQUIRED_BOOTARGS?

Is there a specific reason for you to change the TDX_SECBOOT_REQUIRED_BOOTARGS?

Best regards,