From mboxrd@z Thu Jan 1 00:00:00 1970 From: drambo Date: Wed, 22 Jan 2014 17:06:26 -0800 (PST) Subject: [U-Boot] [PATCH v15 07/10] arm64: core support In-Reply-To: <1390436886.24905.539.camel@snotra.buserror.net> References: <1384487159-43032-6-git-send-email-fenghua@phytium.com.cn> <1384487159-43032-7-git-send-email-fenghua@phytium.com.cn> <1384487159-43032-8-git-send-email-fenghua@phytium.com.cn> <52965848.9050101@gmail.com> <1c3aa9.f1ae.142a41207d4.Coremail.fenghua@phytium.com.cn> <62872971d07d4a74a4a3d6982f4179df@BN1PR03MB220.namprd03.prod.outlook.com> <1112371.31d5.1438e7362cf.Coremail.fenghua@phytium.com.cn> <1390436886.24905.539.camel@snotra.buserror.net> Message-ID: <52E06B04.3020405@broadcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 14-01-22 04:29 PM, Scott Wood-2 [via U-Boot] wrote: > > > 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. Hi Scott, Why is any EL3 code in u-boot at all? That's not the ARM ATF approach I believe but I'm not an expert in this. Please see http://lists.denx.de/pipermail/u-boot/2014-January/171581.html and (https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md See section "Normal World Software Execution") Thanks. Darwin > > -Scott > > > _______________________________________________ > 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-tp167751p172101.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-tp167751p172102.html Sent from the U-Boot mailing list archive at Nabble.com.