hi Linus, > -----Original Messages----- > From: "Linus Walleij" <linus.wall...@linaro.org> > Sent Time: 2015-03-20 17:39:48 (Friday) > To: FengHua <feng...@phytium.com.cn> > Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>, "albert.u.boot" > <albert.u.b...@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 <feng...@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@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@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot