[U-Boot] [PATCH v2] armv8/vexpress64: make multientry conditional
Linus Walleij
linus.walleij at linaro.org
Tue Feb 3 13:31:34 CET 2015
On Fri, Jan 30, 2015 at 3:27 PM, FengHua <fenghua at phytium.com.cn> wrote:
>> While the Freescale ARMv8 board LS2085A will enter U-Boot both
>> on a master and a secondary (slave) CPU, this is not the common
>> behaviour on ARMv8 platforms. The norm is that U-Boot is entered
>> from the master CPU only, while the other CPUs are kept in
>> WFI (wait for interrupt) state.
>
> According to fsl-lsch3 source code,
> Freescale LS2085A master cpu enter u-boot first, then it kick slaves up.
> That's right?
I don't know, I don't have access to this system.
However it doesn't matter to the code.
> There's ATF in Juno, so all slaves are held up.
Yep. Also in FVP and the base model.
But generally I don't see why this multientry exists at all,
it seems more natural for me to keep all CPUs in WFI and
let the OS start them.
>> Make the single entry default and add a special
>> ARMV8_MULTIENTRY KConfig option to be used by the
>> platforms that need multientry and set it for the LS2085A.
>> Delete all use of the CPU_RELEASE_ADDR from the Vexpress64
>> boards as it is just totally unused and misleading, and
>> make it conditional in the generic start.S code.
>
> It's better to retain CPU_RELEASE_ADDR usage with
> CONFIG_ARMV8_MULTIENTRY.
> It still useful when ATF or other PSCI service do not exist.
Yes and this is exactly what this patch does.
CPU_RELEASE_ADDR is still used on the fsl machine.
Yours,
Linus Walleij
More information about the U-Boot
mailing list