[U-Boot] how to get u-boot code with arm64: core support

[drambo <drambo@broadcom.com>]

On 14-01-25 11:46 AM, bhupesh.sharma at 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 at 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-tp167751p172379.html
>
> To unsubscribe from [PATCH v15 00/10] arm64 patch, visit http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=167751&code=ZHJhbWJvQGJyb2FkY29tLmNvbXwxNjc3NTF8LTQ0Nzc3MTIxNQ==
>




--
View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172383.html
Sent from the U-Boot mailing list archive at Nabble.com.