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
#Alt base register
#Disable CCI barrier tranaction
#USB PHY frequency sel
#flush PBI data
RCW values embedded in my SPL image:
#PBL preamble and RCW header
0810000e 0a000000 00000000 00000000
33550002 00000002 60107000 c1002000
00000000 00000000 00000000 01036ffc
20004505 00001200 00000096 00000001
Thanks in advance for any useful feedback,
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.
Did you program the OTPMK, SRK, and DRV? All must be programmed for secure boot.
I programmed the SRK and the OTPMK. But not the DRV. Will try that later today.
Programmed the DRV fuse. But SECMON still not in check state. Same error continues.
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.
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.
Are you sure the LS1043A on this board is the encrypted version, which includes the security features?
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 ?