On Fri, Jan 20, 2017 at 06:30:58PM +0900, Masahiro Yamada wrote:
This reverts commit 8c36e99f211104fd7dcbf0669a35a47ce5e154f5.
There is misunderstanding in commit 8c36e99f2111 ("armv8: release slave cores from CPU_RELEASE_ADDR"). How to bring the slave cores into U-Boot proper is platform-specific. So, it should be cared in SoC/board files instead of common/spl/spl.c. As you see SPL is the acronym of Secondary Program Loader, there is generally something that runs before SPL (the First one is usually Boot ROM).
How to wake up slave cores from the Boot ROM is really SoC specific. So, the intention for the spin table support is to bring the slave cores into U-Boot proper in an SoC specific manner. (this must be done after relocation. see below.)
If you bring the slaves into SPL, it is SoC own code responsibility to transfer them to U-Boot proper. The Spin Table defines the interface between a boot-loader and Linux kernel. It is unrelated to the interface between SPL and U-Boot proper.
One more thing is missing in the commit; spl_image->entry_point points to the entry address of U-Boot *before* relocation. U-Boot relocates itself between board_init_f() and board_init_r(). This means the master CPU sees the different copy of the spin code than the slave CPUs enter. The spin_table_update_dt() protects the code *after* relocation. As a result, the slave CPUs spin in unprotected code, which leads to unstable behavior.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!