HAB u-boot cannot boot

I am having trouble trying to boot with HAB (secure) nand u-boot.

I downloaded the u-boot git from official Toradex repo: git://git.toradex.com/u-boot-toradex.git
(branch 2016.11-toradex)

After compiling u-boot-nand.imx succesfully for imx6ullevk, I followed all the steps and my board cannot boot and no output appears at serial debug port, so I cannot even tell what’s wrong.

How can I debug u-boot to at least see what’s wrong?

Note: If I compile and install without HAB features, works ok.


Greetings @gasmbas,

I have a couple of questions about your issue.

What instructions are you following?

Have you tried building u-boot for the Colibri imx6ull machine w/ HAB features?

Best Regards,


The steps I took were the following.

Download u-boot-toradex from git

$: cd && git clone git://git.toradex.com/u-boot-toradex.git
$: cd u-boot-toradex/
$: git checkout 2016.11-toradex
$: export ARCH=arm
$: export CROSS_COMPILE=arm-linux-gnueabihf-
$: make colibri-imx6ull_defconfig

Add security features to .config file



$: make V=1

Take note of the output

Image Type:   Freescale IMX Boot Image
Image Ver:    2 (i.MX53/6/7 compatible)
Mode:         DCD
Data Size:    569344 Bytes = 556.00 kB = 0.54 MB
Load Address: 877ff420
Entry Point:  87800000
HAB Blocks:   877ff400 00000000 00088c00

Check that hab_status command is present in the .imx file6

$: strings u-boot-nand.imx |grep hab

hab exit function fail
hab entry function fail
hab fuse not enabled

Copy the secure u-boot to cst environment

$: cp u-boot-nand.imx ~/cst/release/linux64/bin/

Create CSF file (using HAB blocks info)

$: cd ~/cst/release/linux64/bin/
$: nano csf-uboot

Version = 4.2
Hash Algorithm = sha256
Engine = SW
Engine Configuration = 0
Certificate Format = X509
Signature Format = CMS

[Install SRK]
File = "../../crts/SRK_1_2_3_4_table.bin"
# Index of the key location in the SRK table to be installed
Source index = 0

[Install CSFK]
# Key used to authenticate the CSF data
File = "../../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate CSF]

[Install Key]
# Key slot index used to authenticate the key to be installed
Verification index = 0
# Target key slot in HAB key store where key will be installed
Target Index = 2
# Key to install
File= "../../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"

[Authenticate Data]
# Key slot index used to authenticate the image data
Verification index = 2
#    Address        Offset    Length    Data File Path    
Blocks = 0x877ff400    0x000    0x88c00    "u-boot-nand.imx"

  • I saw I had the IVT with an offset of 0x400, I changed that in the CSF file but still didn’t worked

Generate the CSF binary signature

$: ./cst --o csf-uboot.bin --i csf-uboot

Attach CSF signature to U-Boot image
The CSF binary data needs to be concatenated to the image.
• Use the cat command to attach the CSF binary to the end of the image:

$: cat u-boot-nand.imx csf-uboot-padded.bin > u-boot-nand-signed.imx

Note: u-boot-nand-signed.imx has to be 4K multiple

Also, I did this:
Pad u-boot-nand-signed.imx to 4KB multiple (4096 bytes)

Hi @gasmbas,

I recreated your issue with your steps and I think I figured out the issue.

I did two tests the first I just flashed u-boot-nand-signed.imx. This worked with me being able to boot into a u-boot prompt and the hab_status command was usable for me. The next test I did exactly as you did and padded u-boot-nand-signed.imx then flashed it. This recreated the issue you described where there was no output from u-boot at all.

In summary it seems once you attach the CSF binary to the U-Boot image you don’t need to additionally pad the resulting signed binary.

Best Regards,


I guess I may have a problem during the flashing operation to the nand.

I am using an standard Colibri image, where I replace the u-boot-nand.imx and install everything using Toradex Easy Installer, which loads the installation file from external flashdrive.

Do I need to change some of the installation files of the flashdrive?

I am using ASTER V.1.1B as carrier board.


BTW, what about the offset of 0x400? Where would the IVT header started at your side? (hexdump -C u-boot-nand.imx)

And how did you put offset in CSF file?


Hi @gasmbas,

To your first point I did exactly just that, replace the u-boot-nand.imx in the Easy Installer package with my HAB modified U-Boot binary.

To your second point my Blocks field in my csf file looks like this:

#	 Address    Offset     Length     Data File Path
Blocks = 0x877ff400 0x00000000 0x00089c00 "./u-boot-nand.imx"

I didn’t modify my csf in any special way other than using my particular HAB block values. Then after creating the csf binary I attached it to the U-Boot binary via cat, and that was all.

My IVT header seems to start at 0x800. I think this is because u-boot-nand.imx is already compiled with an offset for 0x400 for NAND devices and then another 0x400 for HAB.

I still believe your flashing issues is related to the final 4KB padding you do to u-boot-signed.imx. In my case I didn’t do this and the U-Boot binary flashed without issue.

Best Regards,

Hi @jeremias.tx,

Sorry, I tried both padded and non-padded, nothing works.

I also tried before burning fuses (previous step - following AN4581.pdf), and after burning them.
Also, I tried in a different pair of ASTER and colibri boards.

Hi @gasmbas,

So you’ve tried already without padding the csf too correct? How does your IVT header start point compare?

Best Regards,

od -X u-boot-nand.imx|less

0000000 00000000 00000000 00000000 00000000
0002000 402000d1 87800000 00000000 877ff42c
0002020 877ff420 877ff400 87888000 00000000
0002040 877ff000 0008b000 00000000 40e801d2
0002060 04e401cc 68400c02 ffffffff 6c400c02

So you’ve tried already without
padding the csf too correct?


I think you are asking for the output I’ve sent, right?

My IVT Header seems to start at 0x400 (octal 0002000 - as seen in previous message)

The difference in our IVT header start point is odd.

Where does your header start for u-boot-nand.imx? (The binary that is produced after you compile U-Boot). That should have a 0x400 offset as automatically added by the build.

Same, at 0x400.

So just a correction, my signed u-boot binary header starts at 0x400 not 0x800, sorry for the confusion.

Though this means both of our signed u-boot binaries have the right header offset.

The only discrepancy I can notice is in your “HAB Blocks” value where your length of 0x88c00 differs from my length of 0x00089c00. While not a huge difference you’d think if we were were building the same binaries then it’d be the same.

Maybe just as a quick sanity check can you try rebuilding the u-boot binary from scratch. Also what toolchain are you using to build U-Boot? Is it the one from Linaro as specified here (https://developer.toradex.com/knowledge-base/build-u-boot-and-linux-kernel-from-source-code#Toolchain) or a different one?

I’ve followed that without success.

Alternatively, if you did an OpenEmbedded build, you can use the
toolchain generated as part of the
build by entering the following:

export ARCH=arm export

I replaced the PATH with my own, like this:

export ARCH=arm export

The HAB blocks didn’t change compared to previous compilation, however the binary was different.

arm-fslc-linux-gnueabi-gcc --version

arm-fslc-linux-gnueabi-gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.

I also tried with gcc-linaro-5.2-2015.11-2-x86_64_arm-linux-gnueabihf and I got the same HAB blocks as you.

Then, I modified my CSF file, ./cst … , and cat, but still the u-boot doesn’t work.

This is strange since we seem to be doing all the same steps now at this point.

So just to clarify it seems like for you the point of failure is compiling U-Boot with:

At least this seems to be the case since you’ve tried with and without the fuses set, and using multiple pieces of hardware. Just a thought have you tried flashing U-Boot with HAB features compiled in but without attaching a CSF?

Just as a final sanity check could you download and try this U-Boot binary: https://share.toradex.com/8s9l1plq2ihimom

This U-Boot binary is what I used on my end. HAB features should be compiled in. The CSF/keys attached to the binary are mine but we are just trying to see if this U-Boot will work if flashed.

So just to clarify it seems like for
you the point of failure is compiling

Just a thought have you tried flashing
U-Boot with HAB features compiled in
but without attaching a CSF?
Yes, it doesn’t work.

Just as a final sanity check could you
download and try this U-Boot binary:
Yes, it works :). What can I do?

HAB features should be compiled in
It already has hab_status command available, what else are you referring to?

Q1: Which linaro/toolchain version are you using?


Yes, it works :). What can I do?

That’s good to hear!

It already has hab_status command available, what else are you referring to?

Yes that is what I was referring too

Which linaro/toolchain version are you using?

I used gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.

Just to make sure everything is consistent I used u-boot-toradex with branch 2016.11-toradex on commit 83a53c1c0c6fd813bd655b4f88fd07bf798e11d7.

And these were my only changes to the source:

diff --git a/configs/colibri-imx6ull_defconfig b/configs/colibri-imx6ull_defconfig
index f5c8987..e1ecce8 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -59,3 +59,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0x4000
 # CONFIG_EFI_LOADER is not set