No Output in U-Boot Console

[bryceferguson]

I am attempting to secure boot using the T1040RDB (rev 1.0) and U-boot.  Here is what I have been able to accomplish:

RCW from SDK (rcw_sben_1400MHz.bin) and a modified U-Boot that does not define CONFIG_SECBOOT but simply added #define CONFIG_CMD_ESBC_VALIDATE.  When I boot, I am able to verify secure boot is working by and read from 0xfe314014 which says everything is secure and trusted.

RCW (without SB_EN enabled or rcw_14000MHz.bin from SDK) and modified U-Boot with #define CONFIG_SECBOOT.  In this case, the ISBC process does not happen, but I am able to manually check my bootscript and ensure that the steps of the ESBC process are occurring. 

What I am having trouble with is putting everything together.  At this point when I try to use both the RCW with SB_EN enabled (rcw_sben_1400MHz.bin) and U-Boot with #define CONFIG_SECBOOT, rebooting the serial console results in the system immediately locking up (I get no output back whatsoever).  I have tried waiting for a while thinking that it needs some time to make it to the Kernel, but it never happens.  To be clear, if I build U-Boot with just CONFIG_SECBOOT (no real modifications) and use the provided RCW with SB_EN bit set, then the system locks up entirely.

I was wondering if anyone happens to know a good way to debug this or has any suggestions as to why the secure boot doesn't reach the console.

Thanks. 

[yipingwang]

Hello Bryce Ferguson,

Since you are in the testing phase, I suggest you work on bank 0 and flash secure images on bank4.

1. For running secure boot, you need to blow OTPMK and SRK, for these register address you could refer to T1040 Reference Manual.

OTPMKR(0-7) Address : E_8000h base + 21Ch offset + (4d × i), where i=0d to 7d

SRKHRn Address: E_8000h base + 23Ch offset + (4d × i), where i=0d to 7d

You could write these registers from bank 0 u-boot, CCSR begins at 0xFFE00000.

SRK hash value should be same as the hash of the key pair being used to sign the ESBC u-boot.

OTPMK key could be generated by generated by gen_otpmk utility in cst package.

2. You need to flash all the signed images at locations as described in the address map in SDK 1.7 User Manual.

Please flash these image in alternate bank, and also flash uImage, dts, rootfs, CSF header, bootscript,  because the secure u-boot can be stopped to let you enter commands.

For signing images, probably you know the process, you could refer to "Signing the images using same key pair" section in Linux SDK 1.7 document.

3. Switch to alternate bank from bank0, the secure boot would execute.

You could refer to the section "Running secure boot (Chain of Trust)" in SDK User Manual.

Previous I created a document about "Secure boot on Non-PBL Platform" Secure boot for Non-PBL Platform, you also could get the main process of secure boot from it.

If further assistance is needed, please feel free to let me know.

Have a great day,
Yiping

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

[bryceferguson]

Yiping,

Thank you for responding to my inquiry. So far I have done everything that you described the only difference being that I am in bank 4 and am flashing to bank 0.  Though this is not recommended, could it have anything to do with the fact that I still cannot perform secure boot?

Thanks,

-Bryce

[yipingwang · Accepted solution]

Hello Bryce,

Please use the following procedure to check you system step by step.

1. Check the status register of sec mon block (location CCSRBAR +0x314014). Refer to the details of the register from the Reference Manual. Bits OTPMK_ZERO, OTMPK_SYNDROME and PE should be 0 otherwise there is some error in the OTPMK fuse blown by you.

2. If OTMPK fuse is correct (see Step 1), check the SCRATCHRW2 register for errors. Refer to Section for error codes. If Error code = 0 then check the Security Monitor state in HPSR register of Sec Mon.

3. Please check SSM_ST filed of the Security Monitor state in HPSR register of Sec Mon.

Sec Mon in Check State (0x9)

It means ISBC code has reset the board. This may be due to the following reasons:

Hash of the public key used to sign the ESBC u-boot doesn't match with the value in SRK Hash Fuse

Or

Signature verification of the image failed Sec Mon in Trusted State (0xd) or Non Secure State (0xb)

Check the entry point field in the ESBC header, the address is 0xcffffffc.

If entry point is correct, ensure that u-boot image has been signed with the correct input file.

If your problem remains, please let me know the above checking result, and also provide your input file used to signing u-boot.

Have a great day,
Yiping

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

[bryceferguson]

Success!

My problem was the entry point address in the input file.  I made the changes and am now able to secure boot properly.

Thank you very much,

-Bryce