Hi Sean
Without these fences, it is perfectly valid for an out-of-order core to re-order memory accesses to outside of the available_harts_lock critical section.
Signed-off-by: Sean Anderson seanga2@gmail.com
arch/riscv/cpu/start.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index e3222b1ea7..ad18e746b6 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -126,12 +126,12 @@ call_board_init_f_0: #ifndef CONFIG_XIP la t0, available_harts_lock fence rw, w
amoswap.w zero, zero, 0(t0)
amoswap.w.rl zero, zero, 0(t0)
fence rw, w can also be removed.
wait_for_gd_init: la t0, available_harts_lock li t1, 1 -1: amoswap.w t1, t1, 0(t0) +1: amoswap.w.aq t1, t1, 0(t0) fence r, rw
fence r, rw can also be removed.
bnez t1, 1b@@ -143,7 +143,7 @@ wait_for_gd_init: SREG t2, GD_AVAILABLE_HARTS(gp)
fence rw, w
fence rw, w can also be removed.
Thanks, Rick
amoswap.w zero, zero, 0(t0)
amoswap.w.rl zero, zero, 0(t0) /* * Continue on hart lottery winner, others branch to-- 2.28.0