On Fri, Jan 30, 2015 at 3:27 PM, FengHua <feng...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot