On 14-01-25 11:46 AM, bhupesh.sharma@freescale.com [via U-Boot] wrote:
<snip>
However, if we set up u-boot so that it can wake up at any security level and migrate to non-secure EL1, that might be a nice compromise. But having specific EL3 startup assumptions and code that is always present in u-boot seems like the wrong approach to me. At the very least, we should wrap the EL3 code in a CONFIG option since this is not the planned entry state for final deployment.
... You seem to miss a critical detail here, security extensions were also part of the ARMv7 architecture (although optional) and were controlled by the ID_PFR1, Processor Feature Register 1, Security Extensions, bits[7:4]:
Permitted values are: 0b0000 Not implemented. 0b0001 Security Extensions implemented.
So, there was a likelihood that some ARMv7 SoCs still didn't have security extensions enabled - I have used one and hence can vouch that a u-boot running as bare-metal s/w helped me in early SoC bringup.
In ARMv8, we still have the AArch32 state which still has a ID_PFR1_EL1 register, with the same definition for security extension bits.
I agree that for AArch64 state, it makes sense that the s/w to be launched at reset (usually a BootROM or ATF) executes in a Secure aware (i.e. is EL3 aware) and then provides control to a bootloader running in EL2 world (the case presently with UEFI).
But that binds the bootloader, in this case u-boot, with an ATF being available before the first early bootloader s/w can be used to play-around with the Pre-SoC emulators or even the SoC.
A midway solution can be still have u-boot AArch64 EL3 compliant, but under a #ifdef which gets turned-off when u-boot is launched with ATF and turned-on when u-boot is launched as the 1st s/w component on the SoC (and in this case u-boot starts up in secure EL2 and assumes that all boot-time or run-time security settings are taken care of by the ATF and in case any board/platform specific security settings need to be applied the u-boot code can do the same as it is running in secure EL2). I think that should make both the world's happy.
That's exactly what I suggested earlier when I mentioned a CONFIG option for EL3-specific code. Thanks for the detailed and clear response.
I add David Feng in cc here for his views on the same and request others as well to pitch in with their thoughts.
<snip>
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
If you reply to this email, your message will be added to the discussion below: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p17237...
To unsubscribe from [PATCH v15 00/10] arm64 patch, visit http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe...
-- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p17238... Sent from the U-Boot mailing list archive at Nabble.com.