| Message ID | 1484904658-31540-1-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| State | Accepted |
| Commit | 7b74c4b60bd99dcec214c96d22c74f5ba6d8a29e |
| Headers | show |
On 20 January 2017 at 02:30, Masahiro Yamada <yamada.masahiro@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@socionext.com> > --- > > common/spl/spl.c | 8 -------- > 1 file changed, 8 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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! -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
diff --git a/common/spl/spl.c b/common/spl/spl.c index 8fb8da4..d3a4ff6 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -167,14 +167,6 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) (image_entry_noargs_t)spl_image->entry_point; debug("image entry point: 0x%lX\n", spl_image->entry_point); -#if defined(CONFIG_ARMV8_SPIN_TABLE) && defined(CONFIG_ARMV8_MULTIENTRY) - /* - * Release all slave cores from CPU_RELEASE_ADDR so they could - * arrive to the spin-table code in start.S of the u-boot - */ - *(ulong *)CPU_RELEASE_ADDR = (ulong)spl_image->entry_point; -#endif - image_entry(); }
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> --- common/spl/spl.c | 8 -------- 1 file changed, 8 deletions(-) -- 2.7.4 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot