T4240 Secure Boot - SCRATCHRW(n) Registers

[abaker]

I am working on getting secure boot enabled and working on the T4240.

The manuals that I am referencing are:

•   QorIQ T4240 Family Reference Manual, Rev 1, 02/2015
• Note that the latest version of that document has the Secure Boot section removed and references to other documents are in its place
•   Freescale Linux SDK v1.7, Rev B, Mar 2015
•   PBL Configuration Tool User Guide, Rev 4.0, 07/2014
• Setting up Secure Boot on PBL bassed Platforms in Prototype Stage (no revision or date)

During the configuration of the PBI Data, I see that I need to write to SCRATCHRW1 for the address of the ESBC so ISBC can pass control to ESBC.  However, in the T4240 Reference Manual, section 27.3, there is no longer a definition for the SCRATCHRW(n) registers.

Can it please be confirmed that the SCRATCHRW(n) registers still are defined for the T4240 and that is the correct process for the T4240?

Thank you!

[marcboillot]

#LAW for ESBC
09000c10 00000000
09000c14 c0000000           <-- 0xc0000000 region used b/c its < 3.5GB address space required by ISBC
09000c18 81f0001b                  It will effectively map to uBoot in NOR
# LAW for CPC/SRAM
09000d00 00000000
09000d04 bff00000             <-- needed for the House Keeping area of ISBC
09000d08 81000013
# Scratch Registers
090e0200 c0b00000           <- 0xc0b0000 maps to ESBC UBoot header 0xe8b00000
090e0208 c0c00000           <-- 0xc0c0000 maps to ESBC Uboot header 0xecb00000
# CPC SRAM
09010100 00000000
09010104 bff00009           
# CPC Configuration
09010f00 08000000
09010000 80000000

The LAW and Scratch registers are in the 0xCxxxxxxx space because ISBC requires the ESBC to be within the 0-3.5GB address space (< 0xD0000000). The PBI commands are required to map the 0xE0000000 region of NOR (where uBoot resides) into this lower region. So, the scratch registers include this mapping as well. Its also necessary to ensure your header file created by the CSF script points to the reset vector (cffffffc) and the entry point of uBoot in this mapped space (0xcff40000).

With these changes ISBC should validate uBoot and begin executing in the lower 4K of uBoot in secure mode (stage 1 of 4 of secure boot in NOR). Check the DCFG_CCSR_SCRATCHRW2=0 to confirm ISBC validated and SECMON_HPSR =0x8000AD00 showing it entered trust state.

Update RCW to include SB_EN=1. Secure Boot also requires that the fuses are burned. Take caution before programming the fuses and check the hamming codes are zero. See the Trust Architecture document for Secure Fuse Programming (SFP).

see also current discussion on

https://community.nxp.com/message/822000#comment-822000

[analim_gt]

Why do we need to map UBoot heard to two places?

090e0200 c0b00000           <- 0xc0b0000 maps to ESBC UBoot header 0xe8b00000
090e0208 c0c00000           <-- 0xc0c0000 maps to ESBC Uboot header 0xecb00000

Is it a typo?

I am trying to perform secure boot on a P5020 and have so many questions regarding this process.

The addresses are different between these PBI command and what is on my system.

Setting up Secure Boot       |    RCW in QorIQ 1.9 for p5020

#LAW for ESBC
09000c10 00000000          ->    09000cd0
09000c14 c0000000          ->    09000cd4
09000c18 81f0001b           ->    09000cd8 81f0001d (not 'b')... Why?

----------------------------This section doesn't exist in this rcw file  ------------------------
# LAW for CPC/SRAM
09000d00 00000000          ->    no idea what these addresses would be on my system.
09000d04 bff00000          
09000d08 81000013

# Scratch Registers     
090e0200 c0b00000           ->  090E0200
090e0208 c0c00000           ->  doesn't exist

----------------------------These sections doesn't exist in this rcw file  ------------------------
# CPC SRAM
09010100 00000000
09010104 bff00009           
# CPC Configuration
09010f00 08000000
09010000 80000000

[abaker]

Thank you for this information, but the question was in regard to the documentation in the T4240 Reference Manual regarding the presence of the SCRATCHRW(n) registers.

The reference manual does not list these registers in the DCFG_CCSR Memory Map in section 27.3

I am wondering if this is an oversight in the Reference Manual or if the SCRATCHRW(n) registers really don't exist in the T4240.  If they don't exist, that changes the workflow process for Secure Boot.

Peeking and poking of those locations <imply> that they are present, but I would like confirmation if possible.

Thank you.

[ufedor]

> Can it please be confirmed that the SCRATCHRW(n) registers still are

> defined for the T4240 and that is the correct process for the T4240?

Confirmed.

Please create a Technical Case to obtain additional information concerning the Trust Architecture:

https://community.freescale.com/thread/381898