Hi Sean
On 9/9/20 3:50 AM, Rick Chen wrote:
Hi Sean
Clearing MIP doesn't do anything. Whoops. The following commits should tackle this problem in a more robust manner.
I still not catch your points about that this commit 947263033 really help to fix pending IPIs not clean problem on k210 platform at that time, but you just said it do nothing and remove it here currently.
After refactoring the original smp patch to remove the null check, I neglected to re-test with a debug uart enabled. Without doing that test, it is impossible to catch the pending IPI bug. The secondary hart will crash before the serial driver is initialized. I didn't do that test at the time, because I was mostly worried about the secondary hart corrupting the device tree and causing the boot to fail. That failure mode was fixed by 40686c394. So I saw that and thought that the pending IPI issue was solved as well.
Can you describe more clearly why with a debug uart enabled will trigger the pending IPI bug ?
And why the pending IPI be raised and not clear before jump to U-Boot ?
Why the csrc MODE_PREFIX(ip), t0 don't help to fix this bug ?
Thanks, Rick
--Sean
This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6.
Signed-off-by: Sean Anderson seanga2@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 csrs MODE_PREFIX(ie), t0#endif
-- 2.28.0