On 3/10/20 4:20 AM, Rick Chen wrote: > Hi Sean > >> The IPI code could have race conditions in several places. >> * Several harts could race on the value of gd->arch->clint/plic >> * Non-boot harts could race with the main hart on the DM subsystem In >> addition, if an IPI was pending when U-Boot started, it would cause the >> IPI handler to jump to address 0. >> >> To address these problems, a new function riscv_init_ipi is introduced. It >> is called once during arch_cpu_init_dm. Before this point, no riscv_*_ipi >> functions may be called. Access is synchronized by gd->arch->ipi_ready. >> >> Signed-off-by: Sean Anderson <sean...@gmail.com> >> --- >> > >> Can you try to clear mip/sip in startup flow before secondary_hart_loop: >> Maybe it can help to overcome the problem of calling riscv_clear_ipi() >> before riscv_init_ipi() that you added. > > How is the verified result about trying to clear mip/sip in startup flow ? > I have asked you twice in v5, but you still have no response about it. > > [PATCH v5 27/33] riscv: Fix race conditions when initializing IPI > https://patchwork.ozlabs.org/patch/1246864/#2377119 > > Thanks > Rick
I managed to get it working, and this patch incorporates that change. However, I forgot to update the commit message. The original issue I had was related to an accidental change to my config, and not to the clearing of MIP. --Sean