Debugging Secure Boot on NXP 1043

[Tlabs]

Hi all,

i am trying to debug my secure boot implementation. And it looks like that OTMK and SRKH has been written successfull:

=> md 0x1e80234
01e80234: ffffffff ffffffff ffffffff ffffffff
01e80244: ffffffff ffffffff ffffffff ffffffff 
01e80254: 6348455f e12a27d5 49968d2b 77ab26b1
01e80264: 25a8f2d7 47f364af 6442d2aa d8efea8

01e80274: 00000000 00000000 00000000 00000000 
01e80284: 00000000 ffffffff ffffffff ffffffff
01e80294: ffffffff ffffffff ffffffff ffffffff
01e802a4: ffffffff 00000000 00000000 00000000 

But if i look to the SecMon_HP Status Register i can see:

=> md.b 0x1e90014 4
01e90014: 80 00 29 00

ZMK_ZERO: 1

OTPMK_ZERO: 0

OTPMK_SYNDROME: 0

SECURITY_CONFIG: 0010

SSM_STATE: 1001 --> looks like the ISBC reset the board due to a SRKH hash mismatch. 

The 

=> md.b 0x1ee0204
01ee0204: 00 00 00 00 --> no errors

Anyone an idea how i can move forward?

[Tlabs]

Thank you for the answer.

1. I used the CST provisioning image. I configured the SRKH in the provisioning configuration file exactly like the output of the make script. i hope this is correct?

2. I tried to read the SECMON_HP register with u-boot using md.b is this correct?

3. What is the bit 15-12 SECURITY_CONFIG in the SECMON_HP standing for exactly? I couldnt find it in the documentation.

4. In my case the SSM_STATE is 1001 what does this mean?

5. When i read the SCRATCHHW2 register (with SBEN=1, BOOT_HO=0 in the RCW) it is the adress of the CSF Header of the ESBC image correct?

[yipingwang]

SRK (Public Key) Hash:

a0f283ace4cf3c8fa893950ea69b74992bf065b042b15fc9a1f3860e47b6bb02

         SFP SRKHR0 = a0f283ac

         SFP SRKHR1 = e4cf3c8f

         SFP SRKHR2 = a893950e

         SFP SRKHR3 = a69b7499

         SFP SRKHR4 = 2bf065b0

         SFP SRKHR5 = 42b15fc9

         SFP SRKHR6 = a1f3860e

         SFP SRKHR7 = 47b6bb02

The fuse provisioning utility is running on the ARM core, so it is same as uboot. The SRKH value needs to be in "reverse order_1".

i.e. customer  input_fuse_file.txt should be # Super root key hash [Optional]

SRKH_0=ac83f2a0

SRKH_1=8f3ccfe4

[Tlabs]

So means this is wrong?

Is there a way testing the SRKH without fusing it?

[yipingwang]

Your fuse provisioning input file is correct, no need to do byte swapping, atf will do the swapping work.

Secure boot u-boot cannot be stopped at all, in your previous description, you stopped u-boot to read registers value. So it means you are not using secure boot image(atf+u-boot) at all.

[yipingwang]

Please configure the following options in RCW.

SB_EN=1 
BOOT_HO=1

Then refer to section "6.1.1.5.2.4.1 Program SRKH mirror registers in CodeWarrior environment" in the attached document to program SRKH mirror registers with CCS + CodeWarrior TAP.

[Tlabs]

Can anyone give me a short feedback please

[yipingwang]

SRKH and OTPMK should be carefully written keeping in mind the SFP Block Endianness. If SRKH and OTPMK are written using Core, SRKH and OTPMK need to be swapped. However, if SRKH and OTPMK are written using DAP or SFP, swap is not required.
Refer the following table for details.

For example:
Assuming following SRKH values are generated:
SRK (Public Key) Hash:
fdc2fed4317f569e1828425ce87b5cfd34beab8fdf792a702dff85e132a29687
SFP SRKHR0 = fdc2fed4
SFP SRKHR1 = 317f569e
SFP SRKHR2 = 1828425c
SFP SRKHR3 = e87b5cfd
SFP SRKHR4 = 34beab8f
SFP SRKHR5 = df792a70
SFP SRKHR6 = 2dff85e1
SFP SRKHR7 = 32a29687
Execute following commands at the CCS console to permanently write SRKH using DAP/SFP:
ccs::write_mem 32 0x1e80254 4 0 0xfdc2fed4
ccs::write_mem 32 0x1e80258 4 0 0x317f569e
ccs::write_mem 32 0x1e8025c 4 0 0x1828425c
ccs::write_mem 32 0x1e80260 4 0 0xe87b5cfd
ccs::write_mem 32 0x1e80264 4 0 0x34beab8f
ccs::write_mem 32 0x1e80268 4 0 0xdf792a70
ccs::write_mem 32 0x1e8026c 4 0 0x2dff85e1
ccs::write_mem 32 0x1e80270 4 0 0x32a29687

Execute following commands at the U-Boot console to permanently write SRKH using core:
mw.l 0x1e80254 0xd4fec2fd
mw.l 0x1e80258 0x9e567f31
mw.l 0x1e8025c 0x5c422818
mw.l 0x1e80260 0xfd5c7be8
mw.l 0x1e80264 0x8fabbe34

mw.l 0x1e80268 0x702a79df
mw.l 0x1e8026c 0xe185ff2d
mw.l 0x1e80270 0x8796a232
mw.l 0x1e80020 0x2