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

[Linus Walleij]

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?

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

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

I must be missing something.

Yours,
Linus Walleij