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,
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.
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 ?