[U-Boot] how to get u-boot code with arm64: core support

[Detlev Zundel]

Hi Bhupesh,

>> -----Original Message-----
>> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
>> On Behalf Of drambo
>> Sent: Thursday, January 23, 2014 12:32 AM
>> To: u-boot at 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.

Many of our customers (in the embedded market) use U-Boot in such a way
very successfully.

> 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 !

I have to admit that I'm only reading up on the complexities of the
security model of aarch64, but my gut response (cf. [1] is that "real
security" stems from "few code" rather than adding layer over layer.
With this in mind, I'd really like to see that U-Boot with its well
known and tested code base can still be the "root of trust" in an
embedded product (i.e. EL3 as far as I understand).

Many of the embedded U-Boot users who excercise full control over the
whole software stack very likely want to see the same.

The interesting question will be if we can reconcile the requirements of
"classic embedded U-Boot users" and this "OEM server market" that seems
to drive much of these new concepts here.  But I sincerely hope so.
After all, in the end we want to boot an OS to get the real work done ;)

Best wishes
  Detlev

[1] Reading one presentation I found about ATF[2] actually made my head
    hurt around page 12 which looks more like "security soup" than
    clearcut concepts, but maybe I'm just not into all the details yet.

[2] http://lcu-13.zerista.com/event/member/85121

-- 
Our choice isn't between a digital world where the NSA can eavesdrop and one
where the NSA is prevented from eavesdropping; it's between a digital world
that is vulnerable to allattackers, and one that is secure for all users.
                              -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de