No output in U-Boot console (p4080 secure boot)

cancel
Showing results for 
Search instead for 
Did you mean: 

No output in U-Boot console (p4080 secure boot)

1,287 Views
tschutte
Contributor III


Hello,

So I have been working on getting secure boot working with a p4080 and U-Boot, and right now I seem to be having issues with the validation of my image.  The sec_mon register is in the check state, which according to the trouble shooting means that the

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. I followed the steps listed in the 1.9 SDK documentation when creating the CSF and signing the image with my generated keys, so I am not sure what the next step is to try with verification / troubleshooting.  Is there a way to see what hash it is generating when it compares the two hashes? Or is it possible I am still missing a step or file?

Thanks,

- Tom

Labels (1)
Tags (2)
0 Kudos
7 Replies

569 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Tom,

Do you blow ITS fuse or configure SB_EN = 1 in RCW when set up secure boot? The value of Sec Mon in Check State is 0x9?

Would you please provide the log about how you signed the image and create CSF header, and wrote SRK Hash Fuse through CCS?


Have a great day,
Yiping

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

0 Kudos

569 Views
tschutte
Contributor III

Hello, so I was able to debug my issue.. secure boot was still expecting a scatter gather table, despite the optional tag in the input file comments.  This led to a new error however,

0x100000

BAD_ADDRESS

A Data / Instruction TLB Exception occurred during ISBC execution

we are not sure where this error could be occurring, are there any common things that may cause this?

569 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Tom,

I checked SDK 1.9 u-boot source, the macro CONFIG_FSL_ISBC_KEY_EXT is enabled in arch/powerpc/include/asm/fsl_secure_boot.h by default for CORENET platform. This key is used for verification of next level images is picked up from an Extension Table which has been verified by the ISBC (Internal Secure boot Code) in boot ROM of the SoC.

So please use the input files in input_files/uni_sign/p3_p4_p5/ie_keys/ in cst source folder to sign images and use CST tool with the --key_ext option.

If you still want to use the original secure boot process, you could disable CONFIG_FSL_ISBC_KEY_EXT in arch/powerpc/include/asm/fsl_secure_boot.h and rebuild u-boot.


Have a great day,
Yiping

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

0 Kudos

569 Views
tschutte
Contributor III

I am using u-boot 2014.01, so the macro CONFIG_FSL_ISBC_KEY_EXT doesnt exist, will this still work using the other cst file?

0 Kudos

569 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Tom,

Please use cst tool and input signed files from the same version SDK with u-boot, because the cst input signed file should be compatible with u-boot image. If you use u-boot from SDK 1.6, please also use cst input signed files from SDK 1.6.

If your problem remains, would you please provide your cst input file used to sign u-boot?


Have a great day,
Yiping

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

0 Kudos

569 Views
tschutte
Contributor III

Hi Yiping,

Currently we only have SB_EN bit set as this is the first time we are trying to enable secure boot on one of our products.  The Sec Mon is in the check state (0x9), and I generated all my needed values and files using the latest SDK1.9 off the freescale git. Here were my steps:

Get latest code signing tool from freescale git, then run make to generate the binaries needs to run the Code Signing Tool.

Copy in the u-boot binary into the top level directory fsl-sdk-v making sure U-Boot was compiled with proper Secure_boot defines

generate a key pair for use in the code signing "./gen_keys 1024 -k pub_key -p priv_key"

Obtain hash string of the key pair generated to be programmed in SFP and create CSF header for u-boot image ./uni_sign input_files/uni_sign/p3_p4_p5/input_uboot_secure (Which I modified the input file to suit our board)

Added to the RCW some PBL commands to set up SCRATCHRW1 with the address of the place we put the CSF header, and a law to make sure we can access that part of memory.

----

From our debug tools, I am able to see that scratchrw1 is set up right, the CSF header is where I expect it and visible, and U-Boot is where I expect it and visible. so I am not sure where in these steps I may have gone wrong

0 Kudos

569 Views
tschutte
Contributor III

So I finally found a description of the error reported in SCRATCHRW2 in the SDK 1.6 documentation no less. 0x2000, which states "0x2000 ESBC_HEADER_SG_ESBC_EP ESBC entry point in header not within ESBC address range" but the tlb that is set up should cover the range that we are attempting to load U-boot from, so this shouldnt be possible?