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

FengHua
2015-03-24T15:09:07Z

hi Linus,

> -----Original Messages-----
> From: "Linus Walleij" <linus.walleij@linaro.org>
> Sent Time: 2015-03-20 17:39:48 (Friday)
> To: FengHua <fenghua@phytium.com.cn>
> Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>, "albert.u.boot" <albert.u.boot@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@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.