On 18.08.20 11:14, Bin Meng wrote: > Hi Heinrich, > > On Tue, Aug 11, 2020 at 11:57 AM Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: >> >> At least on the Kendryte K210: >> >> gd->arch.available_harts= 0x0000000000000003 >> gd->arch.ipi[0].addr= 0x0000000000000000 >> gd->arch.ipi[0].arg0= 0x0000000000000000 >> gd->arch.ipi[0].arg1= 0x0000000000000000 >> gd->arch.ipi[1].addr= 0x0000000000000000 >> gd->arch.ipi[1].arg0= 0x0000000000000000 >> gd->arch.ipi[1].arg1= 0x0000000000000000 >> >> We should not jump to 0x0 to handle an interrupt. >> >> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> >> --- >> arch/riscv/lib/smp.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c >> index ac22136314..d725fa32e8 100644 >> --- a/arch/riscv/lib/smp.c >> +++ b/arch/riscv/lib/smp.c >> @@ -96,6 +96,8 @@ void handle_ipi(ulong hart) >> return; >> } >> >> + if (!smp_function) >> + return; > > Can you trace down to why gd->arch.ipi[0].addr is set to zero? I > looked at all places that call smp_call_function() and > gd->arch.ipi[0].addr should not be zero, unless something is seriously > wrong on your board.
arch/riscv/cpu/start.S:122: jal board_init_f_init_reserve board_init_f_init_reserve(): memset(gd_ptr, '\0', sizeof(*gd)); Which code did you expect to set another value on the Kendryte K210? Best regards Heinrich > > Regards, > Bin >