[PATCH 1/7] Revert "riscv: Clear pending interrupts before enabling IPIs"

Sean Anderson seanga2 at gmail.com
Mon Sep 14 14:45:03 CEST 2020


On 9/13/20 11:10 PM, Rick Chen wrote:
> HI Sean
> 
>> On 9/11/20 10:45 AM, Bin Meng wrote:
>>> On Fri, Sep 11, 2020 at 6:22 PM Sean Anderson <seanga2 at gmail.com> wrote:
>>>>
>>>> On 9/11/20 3:38 AM, Bin Meng wrote:
>>>>> Hi Sean,
>>>>>
>>>>> On Tue, Sep 8, 2020 at 2:17 AM Sean Anderson <seanga2 at gmail.com> wrote:
>>>>>>
>>>>>> Clearing MIP doesn't do anything. Whoops. The following commits should
>>>>>
>>>>> Which following commits?
>>>>>
>>>>>> tackle this problem in a more robust manner.
>>>>>>
>>>>>> This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6.
>>>>>>
>>>>>> Signed-off-by: Sean Anderson <seanga2 at 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
>>>>>
>>>>> Did you mean the clearing MIP.MSIP actually does nothing, but the
>>>>> following commit is the correct fix?
>>>>
>>>> Yes, but we also need
>>>
>>> Is MIP.MSIP read-only on K210?
> 
> Since clear mip will not affect anything in K210 and it is writable
> for other RISC-V platforms.

Does it do anything for other RISC-V platforms? I checked the manuals
for the Sifive fu540 and fe310 and the Nuclei Bumblebee (the core
Gigadevice's GD32VF103 series), and none of them do anything with writes
to MIP. Does Andes do anything with writes in their cores? At the very
least I think the comment should be changed so as not to mislead
readers.

> I will prefer to keep this instruction stay here for standard startup
> initialization.

I would prefer not to, since the rest of this series should handle the
original intent of this commit in a much more robust manner.

--Sean


More information about the U-Boot mailing list