WARNING: You have included the meta-tpm layer, but 'tpm or tpm2' has not been enabled in your DISTRO_FEATURES. Some bbappend files and preferred version setting may not take effect. See the meta-tpm README for details on enabling tpm support.
WARNING: You have included the meta-security layer, but 'security' has not been enabled in your DISTRO_FEATURES. Some bbappend files and preferred version setting may not take effect. See the meta-security README for details on enabling security support.
WARNING: Host distribution "linuxmint-21.3" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
WARNING: No recipes in default available for:
/home/matej/oe-core-imx8mp/build/../layers/meta-toradex-nxp/recipes-bsp/imx-mkimage/imx-mkimage_1.0.bbappend
/home/matej/oe-core-imx8mp/build/../layers/meta-toradex-nxp/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.20.0.imx.bbappend
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "2.0.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-tdx-linux"
MACHINE = "verdin-imx8mp"
DISTRO = "tdx-xwayland"
DISTRO_VERSION = "6.7.0-devel-20250114114651+build.0"
TUNE_FEATURES = "aarch64 armv8a crc cortexa53"
TARGET_FPU = ""
meta-toradex-nxp = "HEAD:92a03e8efa00234026139919789989a11bc7ed58"
meta-freescale = "HEAD:4c81b4161b99698b03332842b588dd8235ac47e4"
meta-freescale-3rdparty = "HEAD:9e94b64bdfebcf7bfdf2af6447cec866a4efa814"
meta-toradex-ti = "HEAD:514cf7550c3873c8011b63e4a52f46223c2ea0f6"
meta-arm-toolchain
meta-arm = "HEAD:260e3adc2bf322f52d81c0642c825088a88bb051"
meta-ti-bsp
meta-ti-extras = "HEAD:c57b63147d2ac0dde16e43f7407d0ff50e62efdb"
meta-toradex-bsp-common = "HEAD:0fc41401fb86fa642f43c103441a81c69498a0ce"
meta-oe
meta-filesystems
meta-gnome
meta-xfce
meta-networking
meta-multimedia
meta-python = "HEAD:8e297cdc841c6cad34097f00a6903ba25edfc153"
meta-freescale-distro = "HEAD:d5bbb487b2816dfc74984a78b67f7361ce404253"
meta-toradex-demos = "HEAD:df4296ba9a5334ac036b2445dd7fe848de9290bb"
meta-qt5 = "HEAD:644ebf220245bdc06e7696ccc90acc97a0dd2566"
meta-tpm = "HEAD:353078bc06c8b471736daab6ed193e30d533d1f1"
meta-toradex-distro = "HEAD:7212583d894bbf5501fb1ff20c131ce485b4e4b7"
meta-poky = "HEAD:6518f291d692997632304451695b6c194fec6fa6"
meta = "HEAD:ab2649ef6c83f0ae7cac554a72e6bea4dcda0e99"
meta-custom = "<unknown>:<unknown>"
meta-perl = "HEAD:8e297cdc841c6cad34097f00a6903ba25edfc153"
meta-security = "HEAD:353078bc06c8b471736daab6ed193e30d533d1f1"
meta-toradex-security = "kirkstone-6.x.y:c05a06c4283beb2ad36e08d22d97eee3d52778f3"
Sstate summary: Wanted 439 Local 430 Mirrors 0 Missed 9 Current 3197 (97% match, 99% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
NOTE: Running task 3899 of 8784 (/home/matej/oe-core-imx8mp/build/../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex_5.15-2.2.x.bb:do_package_qa)
NOTE: recipe linux-toradex-5.15.148+gitAUTOINC+f437ddb719-r0: task do_package_qa: Started
NOTE: Running task 8401 of 8784 (/home/matej/oe-core-imx8mp/build/../layers/meta-freescale/recipes-bsp/imx-mkimage/imx-boot_1.0.bb:do_compile)
NOTE: recipe imx-boot-1.0-r0: task do_compile: Started
ERROR: imx-boot-1.0-r0 do_compile: ExecutionError('/home/matej/oe-core-imx8mp/build/tmp/work/verdin_imx8mp-tdx-linux/imx-boot/1.0-r0/temp/run.do_compile.8420', 126, None, None)
ERROR: Logfile of failure stored in: /home/matej/oe-core-imx8mp/build/tmp/work/verdin_imx8mp-tdx-linux/imx-boot/1.0-r0/temp/log.do_compile.8420
NOTE: recipe imx-boot-1.0-r0: task do_compile: Failed
ERROR: Task (/home/matej/oe-core-imx8mp/build/../layers/meta-freescale/recipes-bsp/imx-mkimage/imx-boot_1.0.bb:do_compile) failed with exit code '1'
NOTE: recipe linux-toradex-5.15.148+gitAUTOINC+f437ddb719-r0: task do_package_qa: Succeeded
NOTE: Tasks Summary: Attempted 8759 tasks of which 8757 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 3 seconds
I also include the log file home/matej/oe-core-imx8mp/build/tmp/work/verdin_imx8mp-tdx-linux/imx-boot/1.0-r0/temp/log.do_compile.8420. log.do_compile.8420 (6.5 KB)
I am not sure the whole process is correct. Do you have any suggestions what may cause the problem?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Matej,
Thank you for reaching out with your question about enabling secure boot on the IMX8MP with the Mallow board V1.1. Let’s go through some steps to help resolve the build failure you’re experiencing.
Yocto Configuration: Double-check your local.conf file to ensure all paths and variables related to secure boot are correctly set. Verify that TDX_IMX_HAB_CST_DIR and TDX_IMX_HAB_CST_CERTS_DIR point to the correct directories.
Dependencies and Layers: The warnings about meta-tpm and meta-security layers suggest missing features. Ensure DISTRO_FEATURES includes tpm or tpm2 and security if needed.
Host Distribution: Consider using a validated host distribution like Ubuntu, as your current Linux Mint version might introduce unexpected issues.
Recipe and Layer Setup: Check your bblayers.conf to ensure all necessary layers are included and correctly configured, especially for imx-mkimage and gstreamer.
Log File Analysis: Review the log.do_compile.8420 file for specific error messages that could indicate the root cause of the failure. Look for missing dependencies or permission issues.
Secure Boot Keys: Ensure the keys generated with the NXP tool are correctly integrated into your build process and are in the expected format and location.
Clean Build Environment: Sometimes, residual files from previous builds can cause issues. Consider cleaning the build environment with bitbake -c cleanall <recipe> for affected recipes before rebuilding.
By addressing these areas, you should be able to identify and resolve the issue causing the build failure. If you need further assistance, feel free to reach out.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I noticed you’re not using the latest for the Kirkstone build, maybe try updating your build to latest and see if it works. On my side my build has the following hashes for the meta-layers:
This was with our Torizon distro and image instead of the reference image. Though this shouldn’t make a huge difference for this, since your build failed on a common recipe.
Thank you for the information. Now I got the error
| ERROR: Could not find '/home/matej/cst-3.4.1/crts/SRK1_sha256_2048_65537_v3_ca_crt.pem'
Because I did not have CA flag set when creating keys. Should there be CA flag when creating keys for fusing via NXP tool? (so SRK1_sha256_2048_65537_v3_ca_crt.pem instead of SRK1_sha256_2048_65537_v3_usr_crt.pem)
I tried to build it with CA flag on different computer and the build was successful. However, when I install the image (without fusing keys via Uboot console), the image loads successfully. Is this expected behaviour? When I dealt with secure boot implementetation on AM62 and I built the image, I could not get into the image without fusing the keys first (that is the point of secure boot). It is possible that the build was successful but it did not sign it? Should I be able to enter the installed system without fusing the keys?
Should there be CA flag when creating keys for fusing via NXP tool?
Well it’s optional depending on how you generated your keys you should set the appropriate values for TDX_IMX_HAB_CST_SRK_CA in your Yocto build. On my side during my test build I generated keys with the CA flag. No particular reason I did, it was just a test anyways.
However, when I install the image (without fusing keys via Uboot console), the image loads successfully. Is this expected behaviour? When I dealt with secure boot implementetation on AM62 and I built the image, I could not get into the image without fusing the keys first (that is the point of secure boot). It is possible that the build was successful but it did not sign it? Should I be able to enter the installed system without fusing the keys?
Yeah that is expected, all the Yocto build does is sign the U-Boot bootloader binary. However the NXP secure-boot behavior itself isn’t actually enforced until the fuses are set on the device. Until the fuses are set the device will still boot whatever software you flash to it. If you check your Yocto build in the deploy directory there should be a file called fuses-cmds.txt that contains the commands that should be executed in U-Boot to set your fuses for your keys.
Keep in mind these fuses are one-time only irreversible operations. Once you set the final closing fuse, then that device will only boot bootloaders that have been signed with matching credentials. This also means you can’t run our Toradex Easy Installer either making it difficult to work with such a fused device.
Thank you for the information, I do not have the file fuses-cmds.txt in the deploy folder. What I find weird is the log file that the error of the build refers to:
Wait I thought you said in your previous comment that the build was successful now? Did you change something? If your build was succesful then there should be a fuse-cmds.txt file in your deploy directory along with all the other build artifacts.
Looking at your log file the last printed line is:
This means something after this line is printed is silently failing for you, for some reason. It’s hard to say what failed though since there’s no log lines after this. You may need to trace the script starting from that log line onwards to see where your build might be failing silently. I can’t seem to reproduce your build issue so I’m not sure what the issue could be.
Yes, the build was successful, but I tried it on two PCs. The beforementioned error was caused by priviledges to the cst folder from NXP. Now it works.
Thank you for the information. It seems that the fusing was successful now. Is there an indication during boot that the fusing is active? During boot I see:
Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
Is that the debug log when hashes are compared?
My second question is about Easy installer. Now, when I go to recovery mode and try to run the EasyInstaller script, I get the following error:
HID(W):LIBUSB_ERROR_IO
I guess this is inteded, as the tezi feature is disabled by secure boot. Is this correct?
Thank you for the information. It seems that the fusing was successful now. Is there an indication during boot that the fusing is active? During boot I see:
There’s not really any visible indication. That log line you see is unrelated to NXP HAB and is related to the FIT image verification. If you set every fuse including the final closing fuse, then your indication is that the system booted in the first place. If something went wrong during fusing and you closed the device, then obviously the device wouldn’t boot at all in that case.
I guess this is inteded, as the tezi feature is disabled by secure boot. Is this correct?
As I said before in this thread, once you set the final closing fuse the device will only boot properly signed bootloaders. Toradex Easy Installer works by loading it’s own bootloader, therefore it wouldn’t work properly.