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 <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 > >> csrs MODE_PREFIX(ie), t0 > >> #endif > >> > >> -- > >> 2.28.0 > >> >
