[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