[U-Boot] Revert "armv8: release slave cores from CPU_RELEASE_ADDR"

[Tom Rini]

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 at socionext.com>
> Reviewed-by: Simon Glass <sjg at chromium.org>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170128/934e8ba4/attachment.sig>