[U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined

[FengHua]

hi Linus,

> -----Original Messages-----
> From: "Linus Walleij" <linus.walleij at linaro.org>
> Sent Time: 2015-03-20 17:39:48 (Friday)
> To: FengHua <fenghua at phytium.com.cn>
> Cc: "U-Boot Mailing List" <u-boot at lists.denx.de>, "albert.u.boot" <albert.u.boot at aribaud.net>
> Subject: Re: Re: [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined
> 
> On Wed, Mar 11, 2015 at 2:08 PM, FengHua <fenghua at phytium.com.cn> wrote:
> 
> (...)
> >> As asked earlier: how can I test this with FVP or the base model?
> >>
> > I usually use Foundation Model.
> 
> OK... That is the same as the FVP I'm using I guess:
> 
> $ Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 --version
> ARM V8 Foundation Model r0p0 (model build 9.0.24)
> Copyright 2013 ARM Limited.
> All Rights Reserved.
> 
> Correct?
Yes

> 
> >> I'm very interested in doing this as I guess it involves starting U-Boot
> >> at EL3 on bare metal and I really want to try this.
> >>
> >> > +/* SMP Spin Table Definitions */
> >> > +#ifdef CONFIG_BASE_FVP
> >> > +#define CPU_RELEASE_ADDR               (CONFIG_SYS_SDRAM_BASE + 0x03f00000)
> >> > +#else
> >> > +#define CPU_RELEASE_ADDR               (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
> >> > +#endif
> >>
> >> Where are these address defines coming from?
> >
> > It's just hard coded and should be the same value with that in DTS.
> 
> I look in the DTS from the Linux kernel:
> 
> arch/arm64/boot/dts/arm/foundation-v8.dts:
> 
>                 cpu at 0 {
>                         device_type = "cpu";
>                         compatible = "arm,armv8";
>                         reg = <0x0 0x0>;
>                         enable-method = "spin-table";
>                         cpu-release-addr = <0x0 0x8000fff8>;
>                         next-level-cache = <&L2_0>;
>                 };
>                 cpu at 1 {
>                         device_type = "cpu";
>                         compatible = "arm,armv8";
>                         reg = <0x0 0x1>;
>                         enable-method = "spin-table";
>                         cpu-release-addr = <0x0 0x8000fff8>;
>                         next-level-cache = <&L2_0>;
>                 };
> (...)
> 
> It's not the same addres for what I can tell,
> 
> CONFIG_SYS_SDRAM_BASE + 0x03f00000 = 0x83f00000
> 
> but the DTS cpu-release-addr is 0x8000fff8...
> 
> Curiously we also have an ontology problem here: the DTS in
> the Linux kernel does use spin tables, but there is another set of
> DTS files in the ARM Trusted Firmware distribution, for the same
> simulator, stating PSCI as CPU release mechanism. These are
> the only ones that work properly when using ARM TF.
> 
> (Well obviously you don't use these...)

PSCI is prefered by Linux.

> 
> >> Do these spin tables exist in a standard ARM FVP or base model?
> >>
> >> I get the impression that a secondary operating system is being booted
> >> on the secondary CPU at one of these addresses, but why is it running
> >> at these addresses specifically, and is that something coming with these
> >> simulators, or is it some image that is loaded on the side, that the
> >> community does not have access to?
> >>
> > PSCI is not implemented in uboot-armv8.
> 
> Nope. But it is implemented in ARM Trusted Firmware for ARMv8.
> ARM TF install the PSCI handlers before U-Boot is executed.
> 
> > If booting u-boot on bare-metal
> > only spin table can be used. All we do is describing booting
> > method(spin table) and cpu release
> > address in DTS. Linux kernel get cpu release address from DTS also.
> 
> Yep, I want to try this method...
> 
> I just cannot even get U-Boot to run on the foundation model.
> 
> I alter CONFIG_SYS_TEXT_BASE to 0x0:
> 
> #define CONFIG_SYS_TEXT_BASE        0x00000000
> 
> Then I run the simulator like so:
> 
> Foundation_v8pkg/models/Linux64_GCC-4.1/Foundation_v8 \
> --cores=4                                 \
> --no-secure-memory                        \
> --visualization                           \
> --gicv3                                   \
> --data="u-boot-fvp-semi.bin"@0x00000000
> 
> Do you do this as well? Or how do you kick your simulator to
> run U-Boot on bare metal?
> 
CONFIG_SYS_TEXT_BASE should be defined as 0x80000000.
The reset PC value is 0x80000000 on Foundation Model.
and I use "--image=u-boot.bin" instead of "--data=...".

Yours,
David.