[PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()
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.glpk@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; smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1); }
-- 2.28.0
Hi Heinrich,
On Tue, Aug 11, 2020 at 11:57 AM Heinrich Schuchardt xypron.glpk@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.glpk@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.
Regards, Bin
On 18.08.20 11:14, Bin Meng wrote:
Hi Heinrich,
On Tue, Aug 11, 2020 at 11:57 AM Heinrich Schuchardt xypron.glpk@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.glpk@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
participants (2)
-
Bin Meng -
Heinrich Schuchardt