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

[Simon Glass]

On 20 January 2017 at 02:30, Masahiro Yamada
<yamada.masahiro at socionext.com> 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>
> ---
>
>  common/spl/spl.c | 8 --------
>  1 file changed, 8 deletions(-)

Reviewed-by: Simon Glass <sjg at chromium.org>