summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2017-01-20 18:30:58 +0900
committerTom Rini <trini@konsulko.com>2017-01-28 14:04:38 -0500
commit7b74c4b60bd99dcec214c96d22c74f5ba6d8a29e (patch)
tree5fee9f6f659ff6ae8df64003fe83f6c1571e7f4e /arch
parent65f321966177895ecdd2bdd21f3770f1746a9f8b (diff)
Revert "armv8: release slave cores from CPU_RELEASE_ADDR"
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>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions