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.

Do you mean: when FVP run, the first instruction would be fetched from u-boot.elf?

Best wishes,

Hi Darwin,

-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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

Hi Tiger,

-----Original Message----- From: TigerLiu@viatech.com.cn [mailto:TigerLiu@viatech.com.cn] Sent: Thursday, January 23, 2014 1:25 PM To: Sharma Bhupesh-B45370; drambo@broadcom.com; u-boot@lists.denx.de Cc: trini@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support

Hi, bhupesh and drambo: I think current uboot ARMv8's start.S could handle EL2/EL1 case. I have tested it on FVP model, let arm trusted firmware boot u- boot.bin. It seemed ok. The command I used is: ./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3 --data="./bl1.bin"@0x0 --nsdata="./u-boot.bin"@0x08000000

I changed CONFIG_SYS_TEXT_BASE = 0x0800 0000 (because ARM trusted firmware will search non-secure firmware entry point at this addr).

I tried the ATF method you mentioned above which the u-boot compiled for ARMv8 foundation model, but, I ran into some issues. Can you please elaborate the steps you use to compile the ATF for ARMv8 foundation model and the command line you use to launch the ATF BL1 and u-boot on the model.

Regards, Bhupesh

Hi Tiger,

-----Original Message----- From: TigerLiu@viatech.com.cn [mailto:TigerLiu@viatech.com.cn] Sent: Wednesday, February 12, 2014 7:38 AM To: Sharma Bhupesh-B45370; drambo@broadcom.com; u-boot@lists.denx.de Cc: trini@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support

Hi, Bhupesh: I described my steps:

1. Compiled ATF Export CROSS_COMPILE=/home/lion/

gcc-linaro-aarch64/bin/aarch64-linux-gnu- make DEBUG=1 V=1 make DEBUG=1 PLAT=fvp all dump

Note: I used linaro released aarch64 compiler, not official gcc 4.7

2. Compiled Uboot (1) revised CONFIG_SYS_TEXT_BASE in vexpress_aemv8a.h CONFIG_SYS_TEXT_BASE = 0x08000000 (2) compiled Uboot export ARCH=aarch64 export

CROSS_COMPILE=/home/lion/gcc-linaro-aarch64/bin/aarch64-linux-gnu- make vexpress_aemv8a

Note: Please use u-boot.bin(about 207 KB) in below step 3. 3. Run ATF with FVP base model ./Foundation_v8 --cores=2 --no-gicv3 --data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x08000000

Note: I use Foundation_v8, a free armv8 foundation model, not a commercial licensed model.

Thanks for the steps. Actually I was following the same but I get an error " Failed to load boot loader stage 2 (BL2) firmware", although I have placed the 'bl2.bin' at the same directory level as the ARMv8 foundation model (v2 - Release 52rel06).

The complete boot log is:

Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 16:09:23, Feb 11 2014 ERROR: Cannot access 'bl2.bin' file (-1). Failed to load boot loader stage 2 (BL2) firmware.

Did you see some similar issues at your end?

Regards, Bhupesh

Hi Tiger,

On 12 February 2014 07:38, TigerLiu@viatech.com.cn wrote:

Hi, Bhupesh: I described my steps:

1. Compiled ATF Export CROSS_COMPILE=/home/lion/

gcc-linaro-aarch64/bin/aarch64-linux-gnu- make DEBUG=1 V=1 make DEBUG=1 PLAT=fvp all dump

Note: I used linaro released aarch64 compiler, not official gcc 4.7

2. Compiled Uboot (1) revised CONFIG_SYS_TEXT_BASE in vexpress_aemv8a.h CONFIG_SYS_TEXT_BASE = 0x08000000 (2) compiled Uboot export ARCH=aarch64 export

CROSS_COMPILE=/home/lion/gcc-linaro-aarch64/bin/aarch64-linux-gnu- make vexpress_aemv8a

I tried the above steps to compile vexpress_aemv8a, but i get the following errors. Any idea?

aarch64-linux-gnu-gcc: error: unrecognized command line option '-marm' aarch64-linux-gnu-gcc: error: unrecognized command line option '-mno-thumb-interwork' aarch64-linux-gnu-gcc: error: unrecognized command line option '-mabi=aapcs-linux' aarch64-linux-gnu-gcc: error: unrecognized command line option '-mword-relocations'

my u-boot points to "22a240c serial/serial_arc - add driver for ARC UART".

Thanks, Inder

Note: Please use u-boot.bin(about 207 KB) in below step 3. 3. Run ATF with FVP base model ./Foundation_v8 --cores=2 --no-gicv3 --data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x08000000

Note: I use Foundation_v8, a free armv8 foundation model, not a commercial licensed model.

Best wishes, _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

On 12 February 2014 13:32, TigerLiu@viatech.com.cn wrote:

Hi, Inder:

...

aarch64-linux-gnu-gcc: error: unrecognized command line option '-marm' aarch64-linux-gnu-gcc: error: unrecognized command line option

'-mno-thumb-interwork'

...

aarch64-linux-gnu-gcc: error: unrecognized command line option

'-mabi=aapcs-linux'

...

aarch64-linux-gnu-gcc: error: unrecognized command line option

'-mword-relocations'

I didn't run into this issue.

From Google's answer:

Maybe you lost a step in the command line : "export ARCH=aarch64"

No, I did not miss this step. I also have put this in batch file :-) Could it be a toolchain issue? I used the linaro toochain gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xzhttp://releases.linaro.org/latest/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xzat [1].

[1] http://releases.linaro.org/latest/components/toolchain/binaries/

Thanks, Inder

I usually put it in batch file:

export ARCH=aarch64

export CROSS_COMPILE=/home/lion/gcc-linaro-aarch64/bin/aarch64-linux-gnu-

make vexpress_aemv8a

Best wishes,

Hi Inder,

Could you please check the output of:

$ echo $ARCH

if it set to some values, unset it using:

$ unset ARCH

Regards, Bhupesh

From: TigerLiu@viatech.com.cn [mailto:TigerLiu@viatech.com.cn] Sent: Wednesday, February 12, 2014 1:44 PM To: inderpal.singh@linaro.org Cc: Sharma Bhupesh-B45370; drambo@broadcom.com; u-boot@lists.denx.de; trini@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support

Hi, Inder:

Could it be a toolchain issue? I used the linaro toochain gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xzhttp://releases.linaro.org/latest/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xz at [1].

Maybe I use gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar Best wishes,

Hi Bhupesh,

...

-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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.

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

-----Original Message----- From: Darwin Rambo [mailto:drambo@broadcom.com] Sent: Thursday, January 23, 2014 10:35 PM To: Detlev Zundel; Sharma Bhupesh-B45370 Cc: 'u-boot@lists.denx.de'; 'Tom Rini' Subject: Re: [U-Boot] how to get u-boot code with arm64: core support

On 14-01-23 07:58 AM, Detlev Zundel wrote:

...

Hi Bhupesh,

...

...

-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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.

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

armv8 and ATF bring in a new security model and with that, secure monitor/dispatch, secure OS support and secure power control. It may not be good to assume that we can work in a historical way here.

I am not against ATF :) . Like I mentioned below, I personally favor using ATF to boot both u-boot and UEFI, but I have some reservations on the same. More on that below .....

...

...

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).

EL3 is the highest level of trust, and the new armv8 security model treats uefi/u-boot as non-secure firmware. The ATF trusted firmware needs to run, initialize secure hardware, load trusted images, and ultimately launch the non-secure OS loader (uefi or u-boot). As such, I think that running uefi or u-boot at EL3 violates the current arm security model i.e. u-boot cannot be the "root of trust" in this architecture since it is non-secure. Having non-secure firmware run at the same level as the secure dispatcher and secure monitor will fail any secure audit in my opinion.

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.

I add David Feng in cc here for his views on the same and request others as well to pitch in with their thoughts.

Note that these are just my opinions above. Any ARM security experts would be welcome to contribute thoughts here.

...

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

The ATF secure software is freely available.

...

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

;) As armv8 goes mobile, we have less of a server market issue and more of a mobile security issue.

[snip..]

Regards, Bhupesh