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

[bhupesh.sharma at freescale.com]

Hi Darwin,

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of drambo
> Sent: Thursday, January 23, 2014 12:32 AM
> To: u-boot at lists.denx.de
> Subject: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi Bhupesh,
> 
> > U-boot doesn't have ARM trusted firmware support as of now. U-boot for
> > ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware
> > itself is working in EL3.
> 
> Since the ATF software doesn't really care whether it is loading uefi or
> u-boot and since it wants to load non-secure images as EL2 or EL1
> (https://github.com/ARM-software/arm-trusted-
> firmware/blob/master/docs/user-guide.md
> See section "Normal World Software Execution"), why would we want to
> assume u-boot starts in EL3 mode by default?
> 
> If we want to support EL3 execution for convenience to those that don't
> have ATF setup, that might make sense, but then shouldn't initial EL3
> execution and subsequent switching levels be debug CONFIG options?
> Thanks.
> 

In the past I remember using u-boot as the bare-metal s/w to debug a Silicon without
any BootROM/firmware code running before the same on ARM 32-bit architectures.

The ATF is presently tested only for UEFI and UEFI comes up in EL2 while the ATF itself
is running in EL3.

I don't know what would be the popular vote on this, but personally I feel that the u-boot
for ARMv8 should also be launched by the ATF (similar to UEFI) and should start execution in EL2
so that it can launch a hypervisor (running in EL2) or Linux (running in EL1).
But this might hurt the popular premise that u-boot can be used as a bare-metal s/w to debug a silicon
without additional firmware components.

Perhaps u-boot experts can guide us on this !

Regards,
Bhupesh