On Fri, Jan 30, 2015 at 3:27 PM, FengHua fenghua@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