Skip to content
  • Masahiro Yamada's avatar
    Revert "armv8: release slave cores from CPU_RELEASE_ADDR" · 7b74c4b6
    Masahiro Yamada authored
    This reverts commit 8c36e99f.
    
    There is misunderstanding in commit 8c36e99f
    
     ("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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    7b74c4b6