Let me jump in here as I originally wrote the attached guide.
I can confirm what Jeremias mentioned here, this is expected.
These keys are optional according to TI documentation, but if they are not present they are automatically generated.
Therefore on these steps I chose to create them to have more control over the process.
The steps to build a signed image are part of the guide that Jeremias sent.
If the image boots normally on a module which does not have keys written by the OTP keywriter, the image has not been properly signed.
Therefore, I recommend that you double check that the steps have been followed correctly.
Ok, thank you for verifying.
Regarding the case where my image isn’t signed correctly, can you help me determine why my image isn’t being signed correctly.
My modules versions are the “Verdin AM62 Solo 512MB” V1.1B and V1.1C, which don’t match the manual but should be able to utilize secure boot (if the VPP pin is managed correctly).
I have my yocto build local.conf settings for secure boot like below (I only tried it with the “tdx-signed” class yet since BCoT is probably enough for our system):
I think the “TDX_K3_HSSE_ENABLE” and “TDX_K3_HSSE_KEY_DIR” are the only ones required, if i am missing something here, please let me know
My boot logs do show that the FIT image is being checked so that makes me think the signing step is indeed being performed correctly but perhaps only the FIT image and not the uBoot version is being signed.
boot logs: Boot_log_verdin_am62_solo_V1.1C.rtf (14.1 KB)
Thanks for sending the logs.
In the future, can you send plain text files instead of .rtf?
From there I can confirm that you have a module with an HS-FS SoC, so you should be able to use it with secure boot.
The problem here is the signing of the image, as it boots normally on your unfused module.
The check that we see on the logs is using the development keys (dev+), which are able to boot on HS-FS devices:
Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
Please see below the boot logs of a fused module for reference:
Boot Logs
U-Boot SPL 2024.04-ti-gffbbc1dd68f4 (Jan 01 1970 - 00:00:00 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
Changed A53 CPU frequency to 1250000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 9 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...
NOTICE: BL31: v2.11.0(release):v2.11.0-dirty
NOTICE: BL31: Built : 00:00:00, Jan 1 1970
U-Boot SPL 2024.04-ti-gffbbc1dd68f4 (Jan 01 1970 - 00:00:00 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 1904 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
U-Boot 2024.04-ti-gffbbc1dd68f4 (Jan 01 1970 - 00:00:00 +0000)
SoC: AM62X SR1.0 HS-SE
DRAM: 2 GiB
Core: 145 devices, 31 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... OK
In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Model: Toradex 0076 Verdin AM62 Quad 2GB WB IT V1.2A
Serial#: 15479391
Carrier: Toradex Verdin Development Board V1.1C, Serial# 10996014
am65_cpsw_nuss ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: 0x6BA81103 ale_ver: 0x00290105 Ports:2
Net:
Warning: ethernet@8000000port@1 MAC addresses don't match:
Address in ROM is 98:03:8a:76:35:cd
Address in environment is 00:14:2d:ec:32:5f
eth0: ethernet@8000000port@1 [PRIME], eth1: ethernet@8000000port@2
Hit any key to stop autoboot: 1 0
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
969 bytes read in 10 ms (93.8 KiB/s)
## Executing script at 90280000
6647 bytes read in 11 ms (589.8 KiB/s)
82 bytes read in 11 ms (6.8 KiB/s)
Applying Overlay: verdin-am62_dsi-to-hdmi_overlay.dtbo
Applying Overlay: verdin-am62_spidev_overlay.dtbo
24966733 bytes read in 147 ms (162 MiB/s)
## Loading kernel from FIT Image at 90300000 ...
Using 'conf-ti_k3-am625-verdin-wifi-dev.dtb' configuration
Verifying Hash Integrity ... sha512,rsa4096:custMpk+ OK
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x903000e8
Data Size: 11035089 Bytes = 10.5 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x80200000
Entry Point: 0x80200000
Hash algo: sha512
Hash value: 54d94bf7087db40adf22c80679294b4ee6a2140e173a17dbddbeb10e1507e0ed60e9fa480d8e4a8c20657d62928510a13f60f7dbfa3b94b6524f31712f8f82e0
Verifying Hash Integrity ... sha512+ OK
## Loading ramdisk from FIT Image at 90300000 ...
Using 'conf-ti_k3-am625-verdin-wifi-dev.dtb' configuration
Verifying Hash Integrity ... sha512,rsa4096:custMpk+ OK
Trying 'ramdisk-1' ramdisk subimage
Description: initramfs-ostree-torizon-image
Type: RAMDisk Image
Compression: uncompressed
Data Start: 0x90e3e664
Data Size: 13152084 Bytes = 12.5 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x84000000
Entry Point: 0x84000000
Hash algo: sha512
Hash value: e9292f0dbe16a0a3a7150fbc769307391001ef888db62affa61bf05871bd74eb3cc611438a21c40f96d7747900eb93b3ed4fdd08374758ebea5d5be98be6f027
Verifying Hash Integrity ... sha512+ OK
Loading ramdisk from 0x90e3e664 to 0x84000000
## Loading fdt from FIT Image at 90300000 ...
Using 'conf-ti_k3-am625-verdin-wifi-dev.dtb' configuration
Verifying Hash Integrity ... sha512,rsa4096:custMpk+ OK
Trying 'fdt-ti_k3-am625-verdin-wifi-dev.dtb' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x90def698
Data Size: 71664 Bytes = 70 KiB
Architecture: AArch64
Load Address: 0x83000000
Hash algo: sha512
Hash value: 8625853cfcde1b5a4e5ff415722fbfbfd58e551351a6b6b67758d4b226b52d5f25a5da22b816bad2350ed9e20d201d2fef6d6ea9f779c7ad1998cd89e2927511
Verifying Hash Integrity ... sha512+ OK
Loading fdt from 0x90def698 to 0x83000000
## Loading fdt from FIT Image at 90300000 ...
Using 'conf-verdin-am62_dsi-to-hdmi_overlay.dtbo' configuration
Verifying Hash Integrity ... sha512,rsa4096:custMpk+ OK
Trying 'fdt-verdin-am62_dsi-to-hdmi_overlay.dtbo' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x90e3617c
Data Size: 3050 Bytes = 3 KiB
Architecture: AArch64
Load Address: 0x83080000
Hash algo: sha512
Hash value: 5ced6b5ab11cabe4aeae808365b7164ecc5a43b15e8a8fda545db693e133ca2bfd036bce2c1d6b45456e88eadf9c6ad6521eebf9c8815f72d756c3ece4a1676f
Verifying Hash Integrity ... sha512+ OK
## Loading fdt from FIT Image at 90300000 ...
Using 'conf-verdin-am62_spidev_overlay.dtbo' configuration
Verifying Hash Integrity ... sha512,rsa4096:custMpk+ OK
Trying 'fdt-verdin-am62_spidev_overlay.dtbo' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x90e3e32c
Data Size: 560 Bytes = 560 Bytes
Architecture: AArch64
Load Address: 0x83080000
Hash algo: sha512
Hash value: 4bd8efa1ddf06d7e8fa7d3aea24a556c7745e945a554d32215f71140f637f01ed033f5bcc06b23f5ec23e046b2fe6f822927fc121ed58f76e8625d8d011a5a58
Verifying Hash Integrity ... sha512+ OK
Booting using the fdt blob at 0x83000000
Working FDT set to 83000000
Uncompressing Kernel Image to 80200000
Loading Ramdisk to 98259000, end 98ee3f54 ... OK
Loading Device Tree to 0000000098244000, end 0000000098258c2a ... OK
Working FDT set to 98244000
Starting kernel ...
[ 1.032981] ti-sci-clk 44043000.system-controller:clock-controller: recalc-rate failed for dev=81, clk=20, ret=-19
[ 1.095956] rtc-ds1307 0-0032: hctosys: unable to read the hardware clock
[ 1.369307] ti-sci-clk 44043000.system-controller:clock-controller: is_prepared failed for dev=81, clk=20, ret=-19
[ 1.818036] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[ 1.826481] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
[ 1.858872] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[ 1.867418] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
[ 1.885306] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[ 1.893778] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
[ 1.911281] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[ 1.919707] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
Starting systemd-udevd version 255.4^
sysroot.readonly configuration value: 0 (fs writable: 1)
Using legacy ostree bind mount for /
I recommend you to try the following:
If you used development keys from TI, use custom keys instead, generating them as instructed in the guide.
Double check that you are installing the newly built image and not an older build.
Add the DM_VERITY_IMAGE definition to your local.conf file. I did not test this process without this variable being defined.
Thanks for the quick response.
For future reference i’ll add normal text files .
I used custom keys for the tiboot3.bin generation (OTP keywriter application) and referenced these through the ‘TDX_K3_HSSE_KEY_DIR’ attribute.
I don’t really know why the ‘dev’ keys are used in the check other than that the default version of the ‘UBOOT_SIGN_KEYNAME’ states to ‘dev’ and i did not change this, i don’t need to link this to the generated TI keys do i?
Is it also possible to only use the BCoT secure boot option using the AM62 modules or has this not been verified yet?
I flashed a build with the " DM_VERITY_IMAGE" attribute set and the INHERIT += “torizon-signed” included. The build succeeded and correctly flashed but still automatically booted (still using the dev+ checks).
What do i need to change to link to my custom keys (i thought the ‘TDX_K3_HSSE_KEY_DIR’ attribute did this) to the yocto build?
Does this refer to the signing of the FIT image and not so much the uBoot image or am i wrong here. Also these ‘dev’ keys are automatically generated by Yocto in each new (clean) build so is it incorrect to let these be auto generated and do i need to replace these with a fixed set of keys or can i just use new keys for each build as long as the initial uBoot signing keys are the same, since these are fused into the device?
This is an interesting find.
Can you check if this is the case in the testdata file for your specific image?
As an example, in my secure boot build this file is located at build-torizon/tmp/work/verdin_am62-tdx-linux/torizon-docker/1.0/deploy-torizon-docker-image-complete/torizon-docker-verdin-am62-20241202101642.testdata.json.
There, I have:
"UBOOT_SIGN_KEYNAME": "custMpk",
It should be possible to only use BCoT with the AM62, however at this point I would like to reduce the differences between the known-working build I have here so we can better understand what may be the cause of the issue.
This is not a good indication.
Can you let me know which exact version of the Toradex BSP you are using?
The following information would be useful:
Which command was used when running repo init
Which command is being used to build the image
With that information, I will try to reproduce the problem with a fresh build here.
This refers to the signing of the FIT image.
If you are not enforcing FIT image signatures, there is no problem to use these dev keys which are used by default.
Regardless, meta-toradex-security should take care of all of this for you as long as the necessary configurations provided by the layer are made.
Lastly, are you sure that you are flashing the newly built images to the board?
I ask this because your configuration looks correct and flashing an older (not signed) image by accident would explain this behavior.
Perhaps one question from my work method, whenever i want to do a complete rebuild of the image i delete all the files in the workdir folder except the ‘build-torizon’ and the ‘layers’ folder.
from the ‘build-torizon’ folder i delete everything except the ‘conf’ folder and the ‘buildhistory’ folder. Could the build history folder have something to do with the old configuration being maintained somehow?
Regarding the last image flashing, in my last test i saw that the boot log entered the composefs loading sequence after flashing so this indicates my conversion from BCoT to ECoT was sucessfull (i think).
Thanks for the additional information.
I will test this again building with the crops container.
Your approach is good. My main worry was that you were not doing any cleanup and copying the old image by accident.
Usually just running the build again will be enough, but in some cases it is advisable to remove the tmp and cache folders.
My current guess is that the keys folder is not being found due to the use of the crops container.
However, it seems that the path you set on local.conf is correct and accessible via the container, so I will double-check this behavior on my build.
After testing a build with the crops container I concluded the following:
If the keys are not found the build will fail and not generate an image
If the keys are present and the build is configured, the image that is generated does not boot on unfused modules, as expected.
Therefore, I was not able to reproduce the problem.
I think there may be something wrong with your configuration.
Do you have any additional configurations in your image beyond the secure boot enablement?
If yes, could you try with a stock Torizon image without your modifications but with secure boot enabled?
Ok, interesting.
In previous builds i had a meta-customer layer which i used to add a custom device tree but i have excluded this in all my last build (however the files are still physically in the layers folder, just unreferenced from the bblayers.conf).
Furthermore i have added the SOTA variables for automatic image uploading to torizon cloud:
I added my local.conf file if you would like to check: local.conf (5.7 KB)
I am trying a complete re-build (with new generated keys according to the manual and the SOTA variables disabled), i’ll let you know what happens when i flash that new image.
Thanks for the additional information.
The only difference between our configurations appears to be the SOTA variables which I did not include.
This should not cause the problems we are seeing, so I will await the results of your fresh build as the keys are a more likely cause of issues here.
This morning i flashed my newly build image but it still skips through to booting.
I added my boot logs below (these logs show the previous boot session, installing of easy installer and then flashing the new image (via easy installer with USB)). Verdin AM62-bootlog.txt (25.4 KB)
Just to be sure again, my module version at the moment is “Toradex 0071 Verdin AM62 Solo 512MB V1.1C”, this 1.1 version should support the secure boot option right?
Another thing i noticed, my easy installer version is 6.7.0 and the latest version available is 7.1.0. Does this version differencing matter or is the underlying interface for updating the same, e.g. do i need easy installer version 7 to flash Torizon O.S. 7 or does this not matter?
This version does not officially support fusing as VPP must be supplied externally.
However, I understand that you know of this limitation.
Moreover, from your logs I see that the SoC on the board is an HS-FS SoC, which has support for secure boot.
Therefore, using secure boot should be possible with this board.
This should not matter, the Toradex Easy Installer is able to flash different types of images (including non-Linux images), so unless there is a bug with it, there is no need to use another version.
As the flashing procedure seems to be correct here, the problem must be elsewhere.
From these logs, it still seems that the image is signed with the dev keys.
Are you sure that you are making modifications to the configuration that is actually used to build the image?
For example, if you remove the keys from the directory which they are expected to be, does the build fail with an error?
I deleted everything, also my config files and re-ran the docker container crops (which regenerated the config files). stopped that container, added the secure boot configurations (but linked to an incorrect file path) below:
I then corrected the file path and re-ran the build, this build succeeded and produced the following tar files in the “/home/richard/yocto-workdir/torizon/build-torizon/deploy/images/verdin-am62” folder:
This is the correct procedure.
What could be the issue here is that you may be installing an image from the feeds instead of your image.
To eliminate this possibility, you could try to install the image without any internet access on the module.
Can you send me the image you built so I try it out here?
Please upload it to share.toradex.com and send me a link.
If you prefer, you can send this link via a private message here on the community.
After flashing the module did boot up through UBoot to the O.S. login prompt, i can verify it is the correct installed image by checking the ostree admin status which refers to the image name from the download link (and easy installer usb image name).
I added the boot log below, i am currently rebuilding a new image and i’ll send that to you when it is ready, if you could test it on your module i would appreciate it.
Thanks for checking this.
It is an interesting result, as we have never seen an unfused AM62 module boot a signed image.
From the logs, you can see that the image is using the custom keys on u-boot, but the module is accepting them for some reason.
This is the default behavior for NXP-based modules, but not for TI.
Do you have another Verdin AM62 to test your image with?
I had an unused module laying around (was the wrong type for us), also a verdin AM62 module but the ‘WB IT’ (V1.1B) )version (product code 0072). This one only had the initial easy installer present on it (version 6.6) and i flashed that with the image you provided and this also still booted to the login prompt.
See attached boot logs.
Also my own build image just finished, and i uploaded it to the toradex share: https://share.toradex.com/cr5duq3qeafms91
If you could test this on one of your target boards i would appreciate it, i flashed this on my module and it booted straight through uBoot to the login prompt.
.
