Secure Boot: [Authenticate Data] of CSF file for u-boot iMX6

[satyadamarla]

Hello Guys,

I have trouble with getting the signed u-boot to run. I successfully programmed the Fuse strictly according to the iMX6 Secure Boot guidelines. I doubt its the Authenticate Data from the CSF file thats the issue. The output of the build is as follows:

tools/mkimage -n  imxcfg.imx -T imximage \

  -e 0x17800000 -d u-boot.bin u-boot.imx

Image Type:   Freescale IMX Boot Image

Image Ver:    2 (i.MX53/6 compatible)

Mode:                 DCD

Secure Boot Mode:     ON

CSF Data Address:     1784a000

U-Boot Data Size:     332800 Bytes = 325.00 kB = 0.32 MB

U-Boot Load Address:  177fac00

U-Boot Entry Point:   17800000

arm-linux-objcopy -O srec u-boot u-boot.srec

But actually the sizes are different

-rw-r--r--   1 ds ds 120K Jun 20 08:38 u-boot.map

-rwxr-xr-x   1 ds ds 1.6M Jun 20 08:38 u-boot

-rw-r--r--   1 ds ds 294K Jun 20 08:38 u-boot.bin

-rw-r--r--   1 ds ds 4.9K Jun 20 08:38 imxcfg.imx

-rw-r--r--   1 ds ds 314K Jun 20 08:38 u-boot.imx

-rw-r--r--   1 ds ds 881K Jun 20 08:38 u-boot.srec

-rw-r--r--   1 ds ds  44K Jun 20 08:38 System.map

-rw-r--r--   1 ds ds   56 Jun 20 08:38 u-boot.sb

The authenticate data of the CSF file is as follows:

Verification index = 2

Blocks = 0x17800000 0x000 0x4A000 "u-boot.imx"

I think the first parameter is the load address on the RAM which is 17800000. The second is the offset which I checked and the IVT starts from 0x0, i.e.n there is no offset. And the third parameter is length of the image which is obviously the 1784A000-17800000=4A000. The last one is the unsigned image location.

In spite of taking care, my signed image is not working. Can anyone guide me or identify the mistake I have made?

Greets,

Satya

[Yuri]

Hello,

  is it possible to look at HAB events log ?

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[satyadamarla]

Hello Yuri,

I think thats not possible because I already locked the device. I mean, I programmed the fuse to do secure boot and nothing of any sort is displayed. Before I locked the device, the boot loader which is signed was booting which means its a valid bootloader but after locking the same boot loader which is signed is not booting and so, I think its with the CSF file's  Authenticate data where the problem could be.

Anyway the same boot loader before I locked the device, I had the following HAB info:

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------

event data:

  0xdb 0x00 0x08 0x41 0x33 0x22 0x0a 0x00

--------- HAB Event 2 -----------------

event data:

  0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00

  0x00 0x00 0x00 0x00 0x17 0x7f 0xb0 0x00

  0x00 0x00 0x00 0x20

--------- HAB Event 3 -----------------

event data:

  0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00

  0x00 0x00 0x00 0x00 0x17 0x7f 0xb0 0x2c

  0x00 0x00 0x02 0xf0

--------- HAB Event 4 -----------------

event data:

  0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00

  0x00 0x00 0x00 0x00 0x17 0x7f 0xb0 0x20

  0x00 0x00 0x00 0x01

--------- HAB Event 5 -----------------

event data:

  0xdb 0x00 0x14 0x41 0x33 0x0c 0xa0 0x00

  0x00 0x00 0x00 0x00 0x17 0x80 0x00 0x00

  0x00 0x00 0x00 0x04

Net: FEC [PRIME]

Warning: FEC MAC addresses don't match:

Address in SROM is 00:30:d6:13:48:dd

Address in environment is 00:0f:a4:06:03:64

Hope this helps for you to analyse!

Cheers,

Satya

[satyadamarla · Accepted solution]

Hello Guys,

I think no one had time to address this situation and I have found the reason why my secure boot wasn't working. It was due to the fact that flash operations mostly run on the concept of blocks than as bytes. This is very important to remember when working with flash devices like NAND, NOR and SD card. Typically one block memory is 4KB which is 0x1000 in hexadecimal.

So, the following steps have been performed to get Secure Boot running.

1. The u-boot.imx is padded with 0x00 (or 0xFF) until the last block is completely filled.

2. u-boot.imx file contains three mains parts: IVT, Bootdata, DCD and u-boot.bin. In some official documents Bootdata is after DCD but in my case it was before DCD. All the four parts must be signed. So, the signing should start from the IVT. So,

• the first parameter is the address of the IVT on RAM.
• The second one has to do with where the u-boot.imx starts. If the u-boot.imx starts with IVT table itself then there is no offset else this offset value is between the start of the file and where IVT actually starts. (hexdump -C u-boot.imx | more is the command to use)
• The third parameter is the length of the u-boot.imx to be signed including the padding starting from IVT. If the offset is 0x0 then this is the length of the file. If not then subract the length of the file with the offset.
• In my case Authenticate Data on CSF should be as follows:

Verification index = 2

Blocks = 0x177FB000 0x000 0x4F000 "u-boot.imx"

3. Create the signature usingthe cst tool

4. Add the signature to the u-boot.imx and further padd it with 0x0.

Then the secure boot works like a charm. I hope it helps with people who had the issue.

NOTE:- It always says padding is optional, I would say thats the trick that gets your secure boot running.

Greets,

Satya