Hi Darwin, > -----Original Message----- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of drambo > Sent: Thursday, January 23, 2014 12:32 AM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] how to get u-boot code with arm64: core support > > Hi Bhupesh, > > > U-boot doesn't have ARM trusted firmware support as of now. U-boot for > > ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware > > itself is working in EL3. > > Since the ATF software doesn't really care whether it is loading uefi or > u-boot and since it wants to load non-secure images as EL2 or EL1 > (https://github.com/ARM-software/arm-trusted- > firmware/blob/master/docs/user-guide.md > See section "Normal World Software Execution"), why would we want to > assume u-boot starts in EL3 mode by default? > > If we want to support EL3 execution for convenience to those that don't > have ATF setup, that might make sense, but then shouldn't initial EL3 > execution and subsequent switching levels be debug CONFIG options? > Thanks. >
In the past I remember using u-boot as the bare-metal s/w to debug a Silicon without any BootROM/firmware code running before the same on ARM 32-bit architectures. The ATF is presently tested only for UEFI and UEFI comes up in EL2 while the ATF itself is running in EL3. I don't know what would be the popular vote on this, but personally I feel that the u-boot for ARMv8 should also be launched by the ATF (similar to UEFI) and should start execution in EL2 so that it can launch a hypervisor (running in EL2) or Linux (running in EL1). But this might hurt the popular premise that u-boot can be used as a bare-metal s/w to debug a silicon without additional firmware components. Perhaps u-boot experts can guide us on this ! Regards, Bhupesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
