Hi Scott, > -----Original Messages----- > From: "Scott Wood" <scottw...@freescale.com> > Sent Time: 2014-01-23 08:28:06 (Thursday) > To: FengHua <feng...@phytium.com.cn> > Cc: "bhupesh.sha...@freescale.com" <bhupesh.sha...@freescale.com>, > "'tr...@ti.com'" <tr...@ti.com>, "'u-boot@lists.denx.de'" > <u-boot@lists.denx.de>, rod.dor...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
