[U-Boot] [PATCH v15 07/10] arm64: core support

[FengHua]

Hi Scott,

> -----Original Messages-----
> From: "Scott Wood" <scottwood at freescale.com>
> Sent Time: 2014-01-23 08:28:06 (Thursday)
> To: FengHua <fenghua at phytium.com.cn>
> Cc: "bhupesh.sharma at freescale.com" <bhupesh.sharma at freescale.com>, "'trini at ti.com'" <trini at ti.com>, "'u-boot at lists.denx.de'" <u-boot at lists.denx.de>, rod.dorris at freescale.com
> Subject: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
> 
> On Tue, 2014-01-14 at 09:52 +0800, FengHua wrote:
> > hi bhupesh,
> > 
> > > Hi David,
> > >
> > > In reference to my mail above, I see that the transition to EL2 (from EL3) which occurs very early
> > > in start.S needs to be changed on lines of the ARMv7 code, i.e. the EL2 transition should happen just
> > > before Linux is booted up by the u-boot.
> > > 
> > > The reason for the same is that a no of ARM IPs like GIC, SMMU and TZPC/TZASC need to be configured to
> > > allow non-secure accesses from Linux world (which runs in EL1 mode). Adding the assembly code for all
> > > such IPs in 'setup_el3' function in start.S, will bloat the start.S and also increase the chances of a
> > > bug in the assembly code.
> > > 
> > > Hence, I would like to propose a strategy to shift from EL3 to EL2 to some point in u-boot code after the
> > > C Run Time has been initialized (similar to present ARMv7 u-boot code). 
> > > 
> > > If you are ok with the same, I can try to send out some RFC patches rebased against your latest v16 code-base.
> > > 
> > > Please let me know.
> > > Regards,
> > > Bhupesh
> > > 
> > Actually, patch v16 did exception level switch in the way as you said. please review the code.
> > Both master and slaves switch to el2(el1) just before jumping to linux kernel. BTW,if any good conception please feel free to patch it.
> 
> How would you handle running U-Boot under a secure firmware, or under a
> hypervisor?  Why not take the Linux approach of running most code in
> EL1, with exception handlers pointing at code to handle special
> situations (such as returning to EL2 before OS entry)?
> 
> As for bloating start.S, could leaving EL3 be done in early C code
> rather than in early asm or late C code?  Or, bundle U-Boot with a tiny
> "insecure firmware" that provides the minimum functionality needed with
> similar APIs that would be used with real secure firmware.
> 
> -Scott
> 
 
The u-boot for aarch64 are designed to support running at EL3/EL2/EL1.
The macro 'switch_el' is used to separate different exception level code.
If no secure firmware exist it runs at highest exception level processor
implemented that could be EL3 or EL2 or EL1.
Besides, theoretically it could be loaded by a secure firmware or a hypervisor and runs at EL2 or EL1
(This is not tested).

Best Regards,
David