On 9/11/20 3:38 AM, Bin Meng wrote: > Hi Sean, > > On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson <sean...@gmail.com> wrote: >> >> Clearing MIP doesn't do anything. Whoops. The following commits should > > Which following commits? > >> tackle this problem in a more robust manner. >> >> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. >> >> Signed-off-by: Sean Anderson <sean...@gmail.com> >> --- >> >> arch/riscv/cpu/start.S | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S >> index bf9fdf369b..e3222b1ea7 100644 >> --- a/arch/riscv/cpu/start.S >> +++ b/arch/riscv/cpu/start.S >> @@ -65,8 +65,6 @@ _start: >> #else >> li t0, SIE_SSIE >> #endif >> - /* Clear any pending IPIs */ >> - csrc MODE_PREFIX(ip), t0 > > Did you mean the clearing MIP.MSIP actually does nothing, but the > following commit is the correct fix?
Yes, but we also need [PATCH 3/7] riscv: Use NULL as a sentinel value for smp_call_function so the secondary harts know not to take any IPIs not raised by U-Boot. > > commit 40686c394e533fec765fe237936e353c84e73fff > Author: Sean Anderson <sean...@gmail.com> > Date: Wed Jun 24 06:41:18 2020 -0400 > > riscv: Clean up IPI initialization code > > The previous IPI code initialized the device whenever the first call was > made to a riscv_*_ipi function. This made it difficult to determine when > the IPI device was initialized. This patch introduces a new function > riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is > called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions > should be called. > > Signed-off-by: Sean Anderson <sean...@gmail.com> > Reviewed-by: Rick Chen <r...@andestech.com> > >> csrs MODE_PREFIX(ie), t0 >> #endif >> --Sean