Referring the above documents, I was able to create a signed u-boot padded binary. Also I have fused the public SRT keys into the SOM OTP memory.
After that I have flashed the new signed u-boot image(tried with & without padding) and on checking the ‘hab_status’ from the u-boot, it is displaying ‘Multiple HAB events found’ instead of none.
Also it is displaying error codes like
Also on trying the ‘hab_auth_img’ command, with the address, offset and length given in the ‘.csf file’, it is shown like:
"Error: DCD pointer must be 0
Error: Invalid IVT structure "
When DCD pointer is given as 0, by modifying it in the RAM from u-boot, it does not shown any other error message on this ‘hab_auth_img’ command, but instead shows all the HAB events found.
Can you please direct me to the cause for this issue?
Also can you please tell what is the actual meaning of the values to be given under the ‘Blocks’ in ‘Authenticate Data’ section in the ‘csf’ file.
Is Padding necessary for the u-boot signing? If it has to be padded, how much padding has to be done?
Attaching the u-boot.csf file and first few lines of signed u-boot image after hexdump.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello! Thank you for your detailed message and for working with the Toradex Colibri iMX6ULL SOM. Secure Boot and HAB authentication can be challenging, so let’s walk through your questions point by point.
1. Cause for Your Issue (HAB_FAILURE, HAB_INV_ADDRESS, and IVT Errors)
The HAB_INV_ADDRESS error suggests a mismatch between the addresses/offsets provided in your CSF (Command Sequence File) and the actual memory/image layout (1).
The error “Invalid IVT structure” and “DCD pointer must be 0” also point to issues with how the IVT (Image Vector Table) and DCD (Device Configuration Data) are set up in your image.
On i.MX6ULL, IVT must be correctly positioned and DCD pointer must be 0 during authentication if you’re signing U-Boot. Make sure you are using the correct offset and that the image is properly aligned as required.
Yes, padding is usually necessary so that IVT and CSF data align properly with U-Boot and comply with HAB requirements.
The precise amount depends on your U-Boot image size and the prescribed alignment. You generally:
Pad U-Boot so that the IVT table is immediately after the image.
After the IVT, the CSF follows, and both must be aligned according to the i.MX requirements (usually multiples of 0x1000 or 0x2000, depending on your specific setup).
If you’re not aligning correctly, the authentication will fail, which seems to be the case.
Steps:
Determine your U-Boot image size.
Place the IVT at the correct offset after U-Boot (often next available aligned address).
Add the CSF immediately after the IVT.
Pad if needed to ensure addresses and offsets in memory match your CSF description.
Double-check that your U-Boot was built with HAB support enabled (4).
Carefully match CSF “Blocks” with how and where you load the binary in U-Boot for authentication (load command address, file offset, and size).
Ensure your SRK fuses are correctly programmed (see here).
If you have your CSF file and the hexdump of your image’s start, I can try to provide specific recommendations on alignment and padding if you share those details (or summaries thereof).
Edward’s assessment seems correct regarding the issue here.
Just to add though. We do provide a meta-layer for Yocto that automatically does the signing of the binaries for HAB/AHAB: GitHub - toradex/meta-toradex-security
While you don’t need to use this, it could help to debug things or just make sure you’re not forgetting something or making a user error. Since doing the HAB process manually can be a bit error prone with everything that needs to be done correctly.
Hi Edward,
Thanks for the reply. The issue here is, although the IVT.csf is pointing to ‘0x878A5000’, the actual size of the u-boot.imx is ‘A8800’ and hence the csf file will be present at ‘0x878A7800’ (877ff000+a8800) and also if you see the hexdump of the final signed u-boot image(Image attched - 1), the csf binary is appended at ‘A8800’ (length of the u-boot.imx) from start.
So when i try modifying the u-boot.csf file with the inputs told by you (877FF400 0 A5C00), on ‘hab_auth_img’, the error is:
"Error: CSF lies outside the image bounds "
(Image attched - 2).
So ,
Why is there an issue there in the ‘IVT.csf’ value (actually the value should be ‘878A7800’) in the IVT table of the image?
Padding at the end isn’t necessary. u-boot make makes image, assuming CONFIG_CSF_SIZE bytes will be attached by signing step later. You need to either set this setting to 0 and no padding will be required at all. Or you need to add specified amount or more bytes at the end, perhaps by appending your csf.bin to your u-boot image. The problem is, boot ROM reads image header and then determines image size to read from NAND. When you flash too few bytes, boot ROM will see ECC erros reading those unprogrammed bytes and won’t boot your image. This is why you need to add required CONFIG_CSF_SIZE bytes to resulting image, or use u-boot nand commands to program locations past the image your programmed.
!) hab_auth_img is for kernel and other images, in which DCD pointer is zero, which is not the case for u-boot.imx.
!!) CSF won’t succeed on image moved to different address in RAM, so you need to use original image load offset, which is 877ff000 in your case (NAND image, padded with 0x400 bytes at bottom), and your IVT offset for hab_auth_image should be 0x400. Length argument for hab_auth_image should match your image file size.
!!!) What you expect to see in hab_status since your u-boot failed HAB authentication? You should authenticate u-boot first, and only then expect hab_auth_image to succeed.
Just a info first up that the u-boot image is not secureboot locked as of now.
Now, on further analysis, what we found is that after using ‘nand write’ for the u-boot image,
on checking the csf values in the address(read from csf address from u-boot), there are small differences in the csf values to the values in hexdump of csf(before flashing) .
Can you please comment on this issue. Is it anything to do with ‘nand write’?
Just a info first up that the u-boot image is not secureboot locked as of now.
That’s the problem. Unsigned U-boot produces HAB errors. Further hab_auth_image commands will produce more HAB errors. So you get about 5 HAB errors due to booting unsigned u-boot. In some cases, when further hab_auth_image commands are run on valid signed kernel/dtb/etc images, HAB errors counter may not increase, but not always, it may just fail and produce morre errors due to unsigned bootloader. This is why I recommend not wasting your time and try signing U-boot and booting with signed U-boot first. You don’t need to burn any fuses to check validity of your HAB images (hab_status).
