I have been testing various Secure Boot scenarios on my LS102xA board with QSPI flash. I started by generating 4 SRK and burning their hash in the SRK Hash registers. Then I tried:
- Signing all boot components using the 1st SRK => it works
- Signing U-Boot and its bootscript with the 1st SRK, signing secondary boot components using a different key whose hash is specified in the corresponding esbc_validate command => it works
- Signing U-Boot and 5 IE keys with the 1st SRK, then signing the bootscript and secondary boot components with one of the extension keys => it fails!
I have little details on the failure: after programming my flash with the secure boot components, it just freezes. Using a Lauterbach debugger, I can see that DCFG_CCSR_SCRATCHRW1 contains indeed the address of my U-Boot CSF header, but DCFG_CCSR_SCRATCHRW2 is equal to 0, which would indicate there was not secure boot failure reported by the Secure Boot ROM. So perhaps the failure is in U-Boot.
In the LS1021A SDK v0.4 documentation (section 184.108.40.206.2), it is written that:
Key Extension feature is applicable only for NOR secure Boot. It is not applicable for RAMBOOT (where data has to be copied onto RAM, eg:- NAND, SD, SPI)
I'm using QSPI NOR flash, which I assumed should support key extension. So my questions are:
- Is the LS102xA family supposed to support key extension?
- If so, do all members of that family support key extension, in particular the SEC-less LS1022A?
Thank you for your help.