Secure Boot fails in an early phase

[tmoos]

I have trouble performing Secure Boot on a board that we built, using T1023. The board stops while verifying U-Boot, probably because I used wrong addresses somewhere.

TL;DR:

Is there documentation for the config files used by uni_sign? For example, I need to know what the addresses (e.g. ENTRY_POINT and SG_TABLE_ADDR) mean. Also, I would appreciate documentation about the exact structure of the binary CSF file.

Long version:

My current project status is

• I started with a non-secure boot RCW + U-Boot, both installed in NOR flash, which works just fine.
• I set the SB_EN bit in the RCW to enable Secure Boot (the ITS fuse is not fused)
• I added some PBI commands as follows:
  09000c10 00000000 // Map the IFC to 0xc000_0000
  09000c14 c0000000 // ...
  09000c18 81f0001b // ...
  09000d00 00000000 // Map the SRAM to 0xbff0_0000
  09000d04 bff00000 // ...
  09000d08 81000013 // ...
  090e0200 c3e20000 // Signature is at offset 0x03e2_0000 --> mapped at 0xc3e2_0000
  09010100 00000000 // Configure CPC as SRAM
  09010104 bff00009
  09010f00 08000000
  09010000 80000000
• To create the signature (or CSF, as it is called in the docs), I used uni_sign with the file input_uboot_nor_secure from the SDK, but with ENTRY_POINT=c0000000 and IMAGE_1={u-boot.bin,c0000000,ffffffff}.
• The signature is in NOR at offset 0x03e2_0000.

• The system is not booting.

I can observe the read accesses of the NOR flash by visualizing its "chip enable" and "write enable" signals. I observe the following:

• On power-up, 72 bytes are read, which is the preamble+RCW.
• After 660µs, 96 bytes are read, which is the PBI+CRC. At this point, RCW and PBI were completely consumed.
• After another 1.75ms, 64 bytes are read, supposedly the header of the CSF file.
• No more read accesses are observed.

I suppose that some information within the CSF header is wrong. In the file input_uboot_nor_secure I can set addresses like ENTRY_POINT or SG_TABLE_ADDR, but I don't know what they mean. Is there documentation about that config file? I would also appreciate documentation about the exact structure of the binary CSF file.

Thanks in advance, Tanjeff

[bpe · Accepted solution]

First of all, NXP QorIQ SDK supports Secure Boot for your processor
and, among other images generated by default, builds Secure Boot binaries
ready to sign. If you are working with an NXP development or reference board, use the SDK generated
images for booting. If you are working with a custom board, use the
same configurations with absolute minimum changes. Modifying SDK
Secure Boot configurations in steps may take less time than doing
the same from a generic non-secure boot configuration.

SDK Secure Boot support is described in all details in the online
SDK documentation:

https://nxp.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-65A50152-786D-4579-BA20-A540495...

If Secure Boot fails, the first thing you should check is ISBC error
code which is returned in SCRATCHRW2. Use a JTAG debugger to read it.
Error codes can be found here:

https://nxp.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-1D55CEF8-8762-4EE2-8CDF-CE9B536...

The same online documentation describes CSF header structure:

https://nxp.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-4D5D0916-29CC-4E11-BF82-477C40F...

and

CST input file fields:

https://nxp.sdlproducts.com/LiveContent/content/en-US/QorIQ_SDK/GUID-932D50F3-D90D-4ED0-BEFC-B1BF825...

Have a great day,
Platon

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[tmoos]

Unfortunately I have currently no access to a debugger, therefore I can't access the SCRATCHRW2 register to read the error code :smileysad:

However, I can observe the data lines of the NOR flash. I can observe that the PBI is completely read (including the RCW, of course), then the first 64 bytes of the CSF are  read, then no further NOR accesses are observed. This happens even if the signature is invalid (e.g. all FF), i.e. the 64 bytes CSF header is read in any case. Anyway, in my setup the PBL reads the CSF data that I loaded into the NOR flash, i.e. the address within the SCRATCHRW1 register is correct, and the LAW for the NOR-Flash is also correct.

Next, the PBL should read the public key and the SG-Table (to find the ESBC image) and the ESBC image and the signature. Nothing of this happens. I have the following suspicions:

• The house keeping area might be set up in the wrong way (e.g. SRAM not correctly initialized).
• Some information in the CSF header might be incorrect, e.g. the houekeeping address.

For reference, here is my PBI file as hexdump:

$ xxd -g4 -c8 rcw_data-secureboot.bin
00000000: aa55aa55 010e0100  .U.U....
00000008: 080d000c 00000000  ........
00000010: 00000000 00000000  ........
00000018: 4a800003 00000002  J.......
00000020: ec22f000 21000000  ."..!...
00000028: 00000000 00000000  ........
00000030: 00000000 0002e002  ........
00000038: 00000500 08020a08  ........
00000040: 00000000 00000006  ........
00000048: 09000c10 00000000  ........
00000050: 09000c14 c0000000  ........
00000058: 09000c18 81f0001b  ........
00000060: 09000d00 00000000  ........
00000068: 09000d04 bff00000  ........
00000070: 09000d08 81000011  ........
00000078: 090e0200 c3f3f980  ........
00000080: 09010100 00000000  ........
00000088: 09010104 bff00007  ........
00000090: 09010f00 08000000  ........
00000098: 09010000 80000000  ........
000000a0: 091380c0 00000000  ........
000000a8: 091380c0 00000000  ........
000000b0: 08138040 c7f9ea89  ...@....

The CSF header is as follows (read from running U-Boot while NOR is mapped at 0xe8000000):

=> md ebf3f980

ebf3f980: 68392781 00000200 00000100 00000600    h9'.............
ebf3f990: 00000080 00000400 00000001 c3fffffc    ................
ebf3f9a0: 00000001 00000000 00000000 00000000    ................
ebf3f9b0: bff00000 00010000 00000000 00000000    ................

Note that I don't have any problems with U-Boot here, because I don't reach the point where U-Boot is executed. It's all about PBL so far.

Since we have an U-Boot tailored for our board (including the RCW), I decided to start with this one, rather than dealing with the SDK sources. After all, I will have to integrate secureboot into our system anyway. Nevertheless, I will now build images from SDK and try if it gets me farther.

It would be helpful if you could take a look at my PBI code, especially at the SRAM setup and addresses/offsets. Did I make a mistake rendering the SRAM useless? Or did I use addresses which PBL "doesn't like"?

Kind regards, Tanjeff

EDIT: I have programmed the public key hash to the Fuse Box, but nothing else. Maybe some other information must be programmed to the Fuse Box in order to perform secure boot?

EDIT: I believe that the first 64 bytes of the CSF header read into a cache (i.e. one cache line is 64 bytes).

SOLVED:The address of the LAW registers in the PBI (09000d00, 09000d04, 09000d0c) are wrong. I changed them to 09000c00, 09000c04, 09000c0c, now my signed U-Boot starts. I got it while using the SDK and comparing its build outputs to my own binaries.