LS1043a: invalid SECMON state at boot

[alexandreberder]

Hi,

I'm currently working with a LS1043a based platform (miriac™ MPX-LS1043A ) with no possibility today to solder a JTAG connector.  I'm using QorIQ SDK2.0 to perform a SD boot with SPL binary.

Dumping SECMON HPSR register soon after ISBC boot in SPL, the reported SSM_STATE is "non-secure":

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

(NOTE: This is the log of a board with some fused programmed so showing OTPMK is non zero... But I have the exactly same behavior with the same platform without any fuse programmed. Then, before permanently programming OTPMK fuses I payed attention to SFP_SVHESR indicating all "0" )

I was expecting SECMON to be in CHECK state before starting SPL. Looking at SECMON's state machine the transition from CHECK to NON-SECURE may occur in case of External Boot or in case of Hardware Security Violation. 

Is there any other reason for this transition to happen during BROM execution ?

Logging all SECMON status registers, I cannot find trace of any "security violation". 

Is SD boot considered as an "External Boot" on LS1043a ?

I'm not sure about all PBL and RCW stuff done for this platform so that I provide below an abstract of u-boot config files in case something obvious can be found that may explain this SECMON scenario:

PBI commands embedded in my SPL image:

#Configure Scratch register
09570600 00000000
09570604 10000000
#Alt base register
09570158 00001000
#Disable CCI barrier tranaction
09570178 0000e010
09180000 00000008
#USB PHY frequency sel
09570418 0000009c
0957041c 0000009c
09570420 0000009c
#flush PBI data
096100c0 000fffff

and

RCW values embedded in my SPL image:

#PBL preamble and RCW header
aa55aa55 01ee0100
# RCW
0810000e 0a000000 00000000 00000000
33550002 00000002 60107000 c1002000
00000000 00000000 00000000 01036ffc
20004505 00001200 00000096 00000001

Thanks in advance for any useful feedback,

Alexandre.

[abhkr24]

Hi,
Were you able to make any progress on this? I am seeing similar behavior on ls1046a where SECMON is in non-secure state at startup.

[stadium_aquino]

Did you program the OTPMK, SRK, and DRV? All must be programmed for secure boot.

[abhkr24]

I programmed the SRK and the OTPMK. But not the DRV. Will try that later today.

[abhkr24]

Programmed the DRV fuse. But SECMON still not in check state. Same error continues.

[jeffsteinheider]

There are a couple of ways.

If the part number is readable on the top of the SoC - LS1043ASE.  The E indicates that the device supports encryption and security, or if it is N then the device does not support security features.

You can also check this register in the device:

System Version Register (DCFG_CCSR_SVR)

You will find documentation on this register in the reference manual.Section 12.3.10.

This is often printed out in either u-boot or linux during boot.

Microsys should also be able to tell you the part number on your board.

[alexandreberder]

Hi jeffsteinheider

On our platform DCFG_CCSR_SVR is with 0x8792_0610 thus indicating VAR_PER=0x06

Such value is not documented on latest available LS1043ARM, but according to Microsys support this indeed corresponds to LS1043a with encrypted version.

[jeffsteinheider]

Alexandre,

Are you sure the LS1043A on this board is the encrypted version, which includes the security features?

[alexandreberder]

Hi jeffsteinheider

We're now 100% sure LS1043A chip is the encrypted version.

So, to come back to original questions: how can we investigate this SECMON transition to "Non-Secure" state, so soon at startup ?

[vsiles]

Hi jeffsteinheider‌,

how would we check for the presence of such "security" features ?