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 <sean...@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 >