[PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()

[Heinrich Schuchardt]

On 18.08.20 11:14, Bin Meng wrote:
> Hi Heinrich,
>
> On Tue, Aug 11, 2020 at 11:57 AM Heinrich Schuchardt <xypron.glpk at 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 at 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
>