> >> > +/* 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.
FWIW in the bootwrapper we inject the relevant PSCI properties into the
DTB if the bootwrapper is configured to use PSCI, and we should really
do the same for spin-table.
Given the enable-method is entirely dependent on the FW, it would be
better for FW to fill in an appropriate value (where possible), leaving
those out of the dts.
Mark.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
