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

[Scott Wood]

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