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

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

[TigerLiu at viatech.com.cn]

Hi, experts:
I have tried to boot uefi bootloader with FVP model,it is ok!
./Foundation_v8 --cores=4 --no-secure-memory --visualization --gicv3
--data="./bl1.bin"@0x0 --data="./uefi.fd"@0x8000000

BL1-->BL2-->...>uefi.fd

But booting uboot.bin, it still failed.

Best wishes,

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of TigerLiu at viatech.com.cn
> Sent: Tuesday, January 14, 2014 4:13 PM
> To: fenghua at phytium.com.cn
> Cc: trini at ti.com; u-boot at lists.denx.de; Wood Scott-B07421
> Subject: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi, experts:
> I have tried to boot uefi bootloader with FVP model,it is ok!
> ./Foundation_v8 --cores=4 --no-secure-memory --visualization --gicv3
> --data="./bl1.bin"@0x0 --data="./uefi.fd"@0x8000000

Which ARMv8 foundation model version you are using. I one I have doesn't support
GiCv3. UEFI supports both GiCv3 and v2 whereas I believe uboot is only tested for GiCv2.

> 
> BL1-->BL2-->...>uefi.fd
> 
> But booting uboot.bin, it still failed.
> 
> Best wishes,
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

[TigerLiu at viatech.com.cn]

Hi, sharma:
>Which ARMv8 foundation model version you are using. I one I have
doesn't support
>GiCv3. UEFI supports both GiCv3 and v2 whereas I believe uboot is only
tested >for GiCv2.

I download FVP from ARM Ltd website:
http://www.arm.com/products/tools/models/fast-models/foundation-model.ph
p
how to identify this FVP's version number?

I tried to run :
./Foundation_v8 --cores=4 --no-secure-memory --visualization
--data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x8000000

Not use " --gicv3 " parameter, it still failed to jump to u-boot.bin

Best wishes,

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

[TigerLiu at viatech.com.cn]

Hi, sharma:
> ./Foundation_v8 --cores=4 --no-secure-memory --visualization
--data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x8000000

Is the TEXT_BASE right?

Best wishes,

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> Sent: Tuesday, January 14, 2014 4:40 PM
> To: Sharma Bhupesh-B45370; fenghua at phytium.com.cn
> Cc: trini at ti.com; u-boot at lists.denx.de; Wood Scott-B07421
> Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi, sharma:
> > ./Foundation_v8 --cores=4 --no-secure-memory --visualization
> --data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x8000000
> 
> Is the TEXT_BASE right?
> 

Can you try this command:
./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory

Regards,
Bhupesh 

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

[TigerLiu at viatech.com.cn]

Hi,Sharma:
>Can you try this command:
>./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory

Error:
terminal_1: Listening for serial connection on port 5000
terminal_2: Listening for serial connection on port 5001
terminal_0: Listening for serial connection on port 5002
terminal_3: Listening for serial connection on port 5003
ERROR: an unexpected exception error has occurred inside the model
terminate called after throwing an instance of 'ObjectLoaderError'
  what():  ./u-boot.bin: error while loading 'AXYS 'in'-file' file:
fgets: Success
./run.sh: line 3: 25702 Aborted                 ./Foundation_v8 --image
./u-boot.bin --cores=4 --no-secure-memory

So, maybe current FVP's version is newer!

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

[bhupesh.sharma at freescale.com]

Not the u-boot.bin, only u-boot:

./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory

Regards,
Bhupesh


> -----Original Message-----
> From: TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> Sent: Tuesday, January 14, 2014 4:52 PM
> To: Sharma Bhupesh-B45370; fenghua at phytium.com.cn
> Cc: trini at ti.com; u-boot at lists.denx.de; Wood Scott-B07421
> Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi,Sharma:
> >Can you try this command:
> >./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory
> 
> Error:
> terminal_1: Listening for serial connection on port 5000
> terminal_2: Listening for serial connection on port 5001
> terminal_0: Listening for serial connection on port 5002
> terminal_3: Listening for serial connection on port 5003
> ERROR: an unexpected exception error has occurred inside the model
> terminate called after throwing an instance of 'ObjectLoaderError'
>   what():  ./u-boot.bin: error while loading 'AXYS 'in'-file' file:
> fgets: Success
> ./run.sh: line 3: 25702 Aborted                 ./Foundation_v8 --image
> ./u-boot.bin --cores=4 --no-secure-memory
> 
> So, maybe current FVP's version is newer!
> 
> 

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

[TigerLiu at viatech.com.cn]

Hi, sharma:
>Not the u-boot.bin, only u-boot:
>./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory

FVP model print:
Simulation is started

Then not run further.

Based on arm open source firmware doc, should use Foundation_v8 as below
format:
    ./Foundation_v8                   \
    --cores=4                                 \
    --no-secure-memory                        \
    --visualization                           \
    --gicv3                                   \
    --data="<path to bl1.bin>"@0x0            \
    --data="<path to UEFI binary>"@0x8000000  \

After compiled u-boot source code, there are 3 u-boot bin files:
u-boot     : 1.4MB
u-boot.bin : 205KB
u-boot.elf : 270KB

So, we should use u-boot? Not u-boot.bin?

Best wishes,

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

[Scott Wood]

On Tue, 2014-01-14 at 05:23 -0600, Sharma Bhupesh-B45370 wrote:
> Not the u-boot.bin, only u-boot:
> 
> ./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory

You need to use u-boot.elf, not the unrelocated u-boot.

-Scott

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

[TigerLiu at viatech.com.cn]

Hi, Scott:
>You need to use u-boot.elf, not the unrelocated u-boot.
Thanks a lot!
After changing to u-boot.elf, it could be run in FVP model.

Best wishes,

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

[FengHua]

> -----Original Messages-----
> From: TigerLiu at viatech.com.cn
> Sent Time: 2014-01-15 08:45:16 (Wednesday)
> To: scottwood at freescale.com, bhupesh.sharma at freescale.com
> Cc: fenghua at phytium.com.cn, trini at ti.com, u-boot at lists.denx.de
> Subject: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi, Scott:
> >You need to use u-boot.elf, not the unrelocated u-boot.
> Thanks a lot!
> After changing to u-boot.elf, it could be run in FVP model.
> 
> Best wishes,

I make some supplement.
Foundation Model use elf header to determine the entry point, so only support loading elf(or axf) images.
Another way, gcc for aarch64 use rela relocation type and no initial value encoded in rela table. Thus, the file
'u-boot' contains wrong relocation information. Scott provided a few patches to deal with this problem. A tool
 named relocate-rela is provided to fix this problem and u-boot.elf is generated with correct relocation.

So, only u-boot.elf could be used with Foundation model. 
Currently only gicv2 is supported. I will upload a gicv3 patch in these days.

Best wishes,

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

[Inderpal Singh]

Hi Bhupesh,



On 12 February 2014 13:55, bhupesh.sharma at freescale.com <
bhupesh.sharma@freescale.com> wrote:

>  Hi Inder,
>
>
>
> Could you please check the output of:
>
>
>
> $ echo $ARCH
>

I checked, it gives aarch64.
Anyway if I don't set ARCH properly, the make command fails saying "Failed:
$ARCH=arm, should be 'aarch64' for vexpress_aemv8a".

There seems to be some other problem. I tried with Tiger's toolchain
version as well but I get same issue.

Thanks,
Inder


>
> if it set to some values, unset it using:
>
>
>
> $ unset ARCH
>
>
>
> Regards,
>
> Bhupesh
>
>
>
> *From:* TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> *Sent:* Wednesday, February 12, 2014 1:44 PM
> *To:* inderpal.singh at linaro.org
> *Cc:* Sharma Bhupesh-B45370; drambo at broadcom.com; u-boot at lists.denx.de;
> trini at 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.xz<http://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,
>

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

[bhupesh.sharma at freescale.com]

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 at viatech.com.cn]
Sent: Wednesday, February 12, 2014 1:44 PM
To: inderpal.singh at linaro.org
Cc: Sharma Bhupesh-B45370; drambo at broadcom.com; u-boot at lists.denx.de; trini at 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.xz<http://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,

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

[TigerLiu at viatech.com.cn]

Hi, Inder:

>Could it be a toolchain issue? I used the linaro toochain
gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xz
<http://releases.linaro.org/latest/components/toolchain/binaries/gcc-lin
aro-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,

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

[Inderpal Singh]

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.xz<http://releases.linaro.org/latest/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xz>at
[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,
>

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

[TigerLiu at viatech.com.cn]

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.

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

[Inderpal Singh]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

[TigerLiu at viatech.com.cn]

Hi, Bhupesh:
>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.

I did not run into this issue.
It seems semihosting broken!

Maybe this website is useful:
https://github.com/ARM-software/tf-issues/issues/10

Additional info about my running platform:
1. Ubuntu 11.10 x64 version
2. FVP model : downloaded from ARM Ltd website two weeks ago.
                Maybe your FVP model is older than mine?!

Best wishes,

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

[bhupesh.sharma at freescale.com]

Hi Tiger,

> -----Original Message-----
> From: TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> Sent: Wednesday, February 12, 2014 7:38 AM
> To: Sharma Bhupesh-B45370; drambo at broadcom.com; u-boot at lists.denx.de
> Cc: trini at 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

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

[TigerLiu at viatech.com.cn]

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.

Best wishes,

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

[bhupesh.sharma at freescale.com]

Hi Tiger,

> -----Original Message-----
> From: TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> Sent: Thursday, January 23, 2014 1:25 PM
> To: Sharma Bhupesh-B45370; drambo at broadcom.com; u-boot at lists.denx.de
> Cc: trini at 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

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

[drambo]

On 14-01-25 11:46 AM, bhupesh.sharma at freescale.com [via U-Boot] wrote:
>
>
<snip>

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


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

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Darwin Rambo [mailto:drambo at broadcom.com]
> Sent: Thursday, January 23, 2014 10:35 PM
> To: Detlev Zundel; Sharma Bhupesh-B45370
> Cc: 'u-boot at 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 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.
> 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

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

[Darwin Rambo]

On 14-01-23 07:58 AM, Detlev Zundel wrote:
> 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.
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.

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

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.

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

[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

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

[TigerLiu at viatech.com.cn]

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

Best wishes,

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

[bhupesh.sharma at freescale.com]

Hi Darwin,

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

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] how to get u-boot code with arm64: core support

[drambo]

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.

Regards,
Darwin Rambo



--
View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172079.html
Sent from the U-Boot mailing list archive at Nabble.com.

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

[TigerLiu at viatech.com.cn]

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,

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: TigerLiu at viatech.com.cn [mailto:TigerLiu at viatech.com.cn]
> Sent: Monday, January 20, 2014 4:24 PM
> To: Wood Scott-B07421; Sharma Bhupesh-B45370
> Cc: fenghua at phytium.com.cn; trini at ti.com; u-boot at lists.denx.de
> Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi, Scott:
> >After changing to u-boot.elf, it could be run in FVP model.
> If I run "./Foundation_v8 --image ./u-boot.elf --cores=4 --no-secure-
> memory", Uboot could be run with FVP model.
> But no ARM trusted firmware boot info appeared.
> Such as:
> Booting trusted firmware boot loader stage 1 ......
> 
> If I run "./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3
> --data="./bl1.bin"@0x0 --nsdata="./u-boot.elf"@0x80000000",
> ARM trusted firmware boot info could appear, but failed to load and run
> u-boot.elf.
> 
> So, if I want to use ARM trusted firmware to boot u-boot.elf, any ideas?
> 

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.

Regards,
Bhupesh

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

[TigerLiu at viatech.com.cn]

Hi, Scott:
>After changing to u-boot.elf, it could be run in FVP model.
If I run "./Foundation_v8 --image ./u-boot.elf --cores=4
--no-secure-memory", Uboot could be run with FVP model.
But no ARM trusted firmware boot info appeared.
Such as:
Booting trusted firmware boot loader stage 1
......

If I run "./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3
--data="./bl1.bin"@0x0 --nsdata="./u-boot.elf"@0x80000000",
ARM trusted firmware boot info could appear, but failed to load and run
u-boot.elf.

So, if I want to use ARM trusted firmware to boot u-boot.elf, any ideas?

Best wishes,

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

[Wolfgang Denk]

Dear Abraham,

In message <CANiE1qok5Z97JVU_bZD+k_BSzgJH5hxDvQKeVAH68AFca-qN+w@mail.gmail.com> you wrote:
>
> > It is always wrong to use an absolute path name for CROSS_COMPILE.
> > You should use "CROSS_COMPILE=aarch64-linux-gnu-" and make sure your
> > PATH is set correctly.
> 
> Actually, I also give the full path name when defining CROSS_COMPILER

Then you are also doing it incorrectly. Don't worry, you are not
alone ;-)

> variable. This is because I find myself juggling between different
> compilers, located in different locations for the same build (personal
> experimentation). Is there some dependency on the PATH variable that
> I'm missing? Or is this just convention?

Using a full path name is bad style, and there is actually no
guarantee that it will work correctly.


If you are dealing with multiple tool chains you should always set up
your PATH correctly; there are scripts available that will help doing
that for you (like "eldk-switch" [1] for our ELDK).

[1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.8.3.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Well I don't see why I have to make one man  miserable  when  I  can
make so many men happy."              - Ellyn Mustard, about marriage

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

[Abraham Varricatt]

On Wed, Jan 15, 2014 at 12:07 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear TigerLiu at viatech.com.cn,
>
> In message <FE7ADED5C2218B4786C09CD97DC4C49FD122B6@exchbj02.viatech.com.bj> you wrote:
>>
>> CROSS_COMPILE=/home/lion/ARMv8/gcc-linaro-aarch64/bin/aarch64-linux-gnu-
>
> Side note:
>
> It is always wrong to use an absolute path name for CROSS_COMPILE.
> You should use "CROSS_COMPILE=aarch64-linux-gnu-" and make sure your
> PATH is set correctly.

Actually, I also give the full path name when defining CROSS_COMPILER
variable. This is because I find myself juggling between different
compilers, located in different locations for the same build (personal
experimentation). Is there some dependency on the PATH variable that
I'm missing? Or is this just convention?

-Abraham V.

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

[Wolfgang Denk]

Dear TigerLiu at viatech.com.cn,

In message <FE7ADED5C2218B4786C09CD97DC4C49FD122B6@exchbj02.viatech.com.bj> you wrote:
>
> CROSS_COMPILE=/home/lion/ARMv8/gcc-linaro-aarch64/bin/aarch64-linux-gnu-

Side note:

It is always wrong to use an absolute path name for CROSS_COMPILE.
You should use "CROSS_COMPILE=aarch64-linux-gnu-" and make sure your
PATH is set correctly.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only perfect science is hind-sight.

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

[TigerLiu at viatech.com.cn]

Hi, Fenghua:
>     Albert has merged arm64 patch set. I have tested and it works fine
on >Foundation Model.

I have downloaded the latest u-boot source code.
And compiled it with linaro released gcc:
export ARCH=aarch64
export
CROSS_COMPILE=/home/lion/ARMv8/gcc-linaro-aarch64/bin/aarch64-linux-gnu-
make vexpress_aemv8a
------

Then copy u-boot.bin to Foundation_v8's directory, and runs:
./Foundation_v8 --cores=4 --no-secure-memory --visualization --gicv3
--data="./bl1.bin"@0x0 --data="./u-boot.bin"@0x8000000

But it failed to jump to u-boot.
It seems the Foundation_v8 has hang.

What is wrong with it?

Best wishes,

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

[TigerLiu at viatech.com.cn]

Hi, Jagan and other experts:
Thanks a lot!
I will try it at ARM Ltd released Foundation Model.

Best wishes,

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

[Jagan Teki]

On Sat, Jan 11, 2014 at 12:14 PM, FengHua <fenghua@phytium.com.cn> wrote:
> hi Tiger,
>      Sorry! It's a little late.
>      Albert has merged arm64 patch set. I have tested and it works fine on Foundation Model.
>      So, you could get it from git tree of u-boot-arm branch.
>
> Regards,
> David
>
>> Hi, fenghua:
>> How to get u-boot code with arch/arm/cpu/armv8 directory?
>> I used "git://www.denx.de/git/u-boot.git " to get latest code, but not
>> find armv8 dir.

Tom enqueued this on u-boot/master few back, please check!

-- 
Thanks,
Jagan.

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

[FengHua]

hi Tiger,
     Sorry! It's a little late.
     Albert has merged arm64 patch set. I have tested and it works fine on Foundation Model.
     So, you could get it from git tree of u-boot-arm branch.

Regards,
David

> Hi, fenghua:
> How to get u-boot code with arch/arm/cpu/armv8 directory?
> I used "git://www.denx.de/git/u-boot.git " to get latest code, but not
> find armv8 dir.
> 
> Best wishes,

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

[TigerLiu at viatech.com.cn]

Hi, fenghua:
How to get u-boot code with arch/arm/cpu/armv8 directory?
I used "git://www.denx.de/git/u-boot.git " to get latest code, but not
find armv8 dir.

Best wishes,