I downloaded that linaro and also checkout to that specific commit.
Still not working.
git diff throws the same:
diff --git a/configs/colibri-imx6ull_defconfig b/configs/colibri-imx6ull_defconfig
index f5c8987503..e1ecce89cd 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -59,3 +59,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0x4000
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_FDT_FIXUP_PARTITIONS=y
# CONFIG_EFI_LOADER is not set
+CONFIG_SECURE_BOOT=y
Here goes my u-boot
Hmm now I’m stumped.
I can confirm that your U-Boot binary doesn’t work on my i.MX6ULL. There definitely seems to be some difference between our binaries outside of just the CSF that was attached. As for what is causing this difference I can’t tell, as we seem to be using the same source and toolchain at this point.
The only thing I can think of is the build environment you are using vs what I am using. Though I don’t understand what difference this would make as you are able to compile a working U-Boot without CONFIG_SECURE_BOOT
What Linux distro/version are you running on the PC where you are building U-Boot?
What Linux distro/version are you
running on the PC where you are
building U-Boot?
Linux 4.18.0-25-generic #26~18.04.1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux
Hmm it might be worth trying on an older version of Ubuntu.
I’ve tried the U-Boot build on these versions:
Linux 4.4.0-131-generic #157-Ubuntu SMP Thu Jul 12 15:51:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Linux 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
I can’t imagine this would make a significant difference but I believe our build environments are the same in nearly every other respect. The only recourse outside of this would be an extensive diff debug of our binaries which may or may not give definite answers.
I will try in a Linux Mint 64bit.
I also tried with u-boot commit HEAD of 2016-11 withouth success.
BTW, I am uploading my CSF file too, so you can check that. What about your cst version? Mine is Code Signing Tool release version 3.1.0
This is my CSF:
[Header]
Version = 4.2
Hash Algorithm = sha256
Engine = ANY
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]
# Keys used to authenticate the CSF data
File = "../crts/CSF1_1_sha256_4096_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_4096_65537_v3_usr_crt.pem"
[Authenticate Data]
# Key slot index used to authenticate image data
Verification index = 2
# Address Offset Length Data File Path
Blocks = 0x877ff400 0x00000000 0x00089c00 "./u-boot-nand.imx"
The version of my CST is 3.1.0.
I will try in a Linux Mint 64bit.
Didn’t work either. (Linux 4.8.0-53-generic)
Regarding CSF, I have Engine = SW because AN4581 says that about imx6ull. However, your u-boot worked on my board.
Can you share your csf binary? so I can concatenate it to my u-boot-nand.imx and see what happens.
Thanks
Here is my csf binary: https://share.toradex.com/08knexl7w1gpp53
Yes I saw that errata too but that should only effect authorization of images if I understand. It shouldn’t affect whether U-Boot even boots up or not.
Partial Good News!
If I attach your csf.bin to my u-boot-nand.imx, it works 
I did some tests:
Then, there should be an error during the certificates creation process (pki tree)
How did you do it?
In my case, I did the following (as in An4581)
:~$ tar xzf cst-2.3.2.tar.gz
$: ~/cst-2.3.2/keys$ ./hab4_pki_tree.sh
...
Do you want to use an existing CA key (y/n)?: n
Do you want to use Elliptic Curve Cryptography (y/n)?: n
Enter key length in bits for PKI tree: 2048
Enter PKI tree duration (years): 10
How many Super Root Keys should be generated? 4
Do you want the SRK certificates to have the CA flag set? (y/n)?: y
...
Create the fuse table and binary to be flashed later.
~/cst-2.3.2/keys$ cd ../crts/
~/cst-2.3.2/crts$ ../linux64/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c \
./SRK1_sha256_2048_65537_v3_ca_crt.pem,./SRK2_sha256_5048_65537_v3_ca_crt.pem,./SRK3_sha256_2048_65537_v3_ca_crt.pem,./SRK4_sha256_2048_65537_v3_ca_crt.pem
When creating my certs I did everything the same as you the only difference is that my key length was 4096 instead of 2048. There was no real reason for this, it was just an arbitrary decision on my end.
Also I did another test on my end where I signed my U-Boot binary with a CSF that had Engine = SW like yours. My U-Boot still works with that change so I don’t think that is the issue.
Can you try appending my csf.bin to your signed u-boot and see what happens?
i guess that if my csf.bin is bad, then your uboot should work.
Hmm your csf.bin when attached to my U-Boot binary causes it to fail (i.e. no boot output at all).
Actually, maybe the key length is the issue, in regards to the byte alignment requirement of u-boot-nand.imx. Though you did mention you have padded your csf.bin before to account for this. Still might be worth a test on your end to try 4096 key length.
Though you did mention you have padded your csf.bin before to account for this.
No, I haven’t padded it.
Still might be worth a test on your end to try 4096 key length.
It doesn’t work either. I am attaching all the folder structure so you can check of [2048keylength][1] and [4096keylength][2] [1]: https://share.toradex.com/q2xw3ccszt2lgf4?direct [2]: https://share.toradex.com/g53w5wrd0nafsz5?direct
After some more testing here’s what I got.
It still seems like the issue is your u-boot-nand.imx. This binary should still be able to boot with or without a CSF attached. The question is why does your u-boot-nand.imx suddenly work if my CSF gets attached to it.
My u-boot-nand.imx with your csf attached does work if I recompile the csf with my u-boot-nand.imx.
Therefore, the problem should be in my certs, right?
Which openssl version are you using?
Mine is OpenSSL 1.1.1 11 Sep 2018
My version: OpenSSL 1.0.2g 1 Mar 2016
Ok, what else can we do?
According to the CST user guide it claims OpenSSL versions 1.1.0 and later should work.
Are you able to test with a 1.0.2 version like in my environment?
If this still doesn’t work I think we’ve reached in impasse in terms of answers I can provide from the Toradex side.
If the issue really is weirdness with the CST then perhaps NXP can provide better guidance than I.