From mboxrd@z Thu Jan 1 00:00:00 1970 From: drambo Date: Sat, 25 Jan 2014 17:42:27 -0800 (PST) Subject: [U-Boot] how to get u-boot code with arm64: core support In-Reply-To: References: <1384487159-43032-7-git-send-email-fenghua@phytium.com.cn> <1384487159-43032-8-git-send-email-fenghua@phytium.com.cn> <8f9181aa600e4ffcb35baa0d87e02d1f@BN1PR03MB220.namprd03.prod.outlook.com> <1390417343053-172079.post@n7.nabble.com> <0c84fe49dcae45249138a2b1ced36294@BN1PR03MB220.namprd03.prod.outlook.com> <52E14BB7.5060808@broadcom.com> Message-ID: <52E467F3.4050809@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-25 11:46 AM, bhupesh.sharma at freescale.com [via U-Boot] wrote: > > >> >> However, if we set up u-boot so that it can wake up at any security >> level and migrate to non-secure EL1, that might be a nice compromise. >> But having specific EL3 startup assumptions and code that is always >> present in u-boot seems like the wrong approach to me. At the very >> least, we should wrap the EL3 code in a CONFIG option since this is not >> the planned entry state for final deployment. > > ... You seem to miss a critical detail here, security extensions were also part > of the ARMv7 architecture (although optional) and were controlled by the > ID_PFR1, Processor Feature Register 1, Security Extensions, bits[7:4]: > > Permitted values are: > 0b0000 Not implemented. > 0b0001 Security Extensions implemented. > > So, there was a likelihood that some ARMv7 SoCs still didn't have security extensions > enabled - I have used one and hence can vouch that a u-boot running as bare-metal s/w > helped me in early SoC bringup. > > In ARMv8, we still have the AArch32 state which still has a ID_PFR1_EL1 register, with > the same definition for security extension bits. > > I agree that for AArch64 state, it makes sense that the s/w to be launched at reset > (usually a BootROM or ATF) executes in a Secure aware (i.e. is EL3 aware) and then provides > control to a bootloader running in EL2 world (the case presently with UEFI). > > But that binds the bootloader, in this case u-boot, with an ATF being available before > the first early bootloader s/w can be used to play-around with the Pre-SoC emulators or even the > SoC. > > A midway solution can be still have u-boot AArch64 EL3 compliant, but under a #ifdef which gets turned-off > when u-boot is launched with ATF and turned-on when u-boot is launched as the 1st s/w component > on the SoC (and in this case u-boot starts up in secure EL2 and assumes that all boot-time or run-time security settings > are taken care of by the ATF and in case any board/platform specific security settings need to be applied the u-boot code > can do the same as it is running in secure EL2). I think that should make both the world's happy. That's exactly what I suggested earlier when I mentioned a CONFIG option for EL3-specific code. Thanks for the detailed and clear response. > > I add David Feng in cc here for his views on the same and request others as well to pitch in with their thoughts. > > _______________________________________________ > 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-tp167751p172379.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-tp167751p172383.html Sent from the U-Boot mailing list archive at Nabble.com.