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.masah...@socionext.com>
> Reviewed-by: Simon Glass <s...@chromium.org>Applied to u-boot/master, thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
