[PATCH] arm/gicv3: Fix building arm/r52

[Chris Johns]

On 30/6/2022 1:42 am, Sebastian Huber wrote:
> On 27/06/2022 08:27, Sebastian Huber wrote:
>> On 27/06/2022 05:02, Chris Johns wrote:
>>> On 24/6/2022 7:44 pm, Sebastian Huber wrote:
>>>> On 20.06.22 04:03, chrisj at rtems.org wrote:
>>>>> From: Chris Johns <chrisj at rtems.org>
>>>>>
>>>>> ---
>>>>>    bsps/include/dev/irq/arm-gicv3.h | 5 +++++
>>>>>    1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/bsps/include/dev/irq/arm-gicv3.h
>>>>> b/bsps/include/dev/irq/arm-gicv3.h
>>>>> index a79368ebdf..aac02fa191 100644
>>>>> --- a/bsps/include/dev/irq/arm-gicv3.h
>>>>> +++ b/bsps/include/dev/irq/arm-gicv3.h
>>>>> @@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
>>>>>      }
>>>>>        /* Enable interrupt groups 0 and 1 */
>>>>> +#ifdef ARM_MULTILIB_ARCH_V4
>>>>> +  WRITE_SR(ICC_IGRPEN0, 0x1);
>>>>> +  WRITE_SR(ICC_IGRPEN1, 0x1);
>>>>> +#else
>>>>>      gic_icc_write(IGRPEN1, 1);
>>>>> +#endif
>>>>>      WRITE_SR(ICC_CTLR, 0x0);
>>>>>    }
>>>>
>>>> I have a different patch to fix this:
>>>>
>>>> https://lists.rtems.org/pipermail/devel/2022-June/072056.html
>>>
>>> Does this change work on a real aarch64 with a suitably configured TF-A? The
>>> security profile of the TF-A needs to disable EL1 access to these registers to
>>> see the issue.
>>
>> I don't have a hardware to test this change. I can do tests on a Cortex-R52
>> hardware.
>>
>> For the Cortex-R52, group 0 interrupts are signaled through FIQ exceptions and
>> group 1 interrupts are signaled through IRQ exceptions. This processor has no
>> secore/non-secure states.
> 
> I checked the GICv3 manual. The group 0 interrupts are always Secure if the
> system has at least two Security states. So, if RTEMS runs in Non-Secure mode,
> it cannot modify group 0 interrupts. 

Thanks, this was my understanding once the exceptions made me take a look.

> We have some things to consider:
> 
> 1. Count of system security states

I think there are registers available that detail this but I have not checked in
detail what can be read and when. I prefer we avoid any runtime management.

> 2. In which state RTEMS runs

We have to be able to run non-secure in EL1. The FPD scalar cores (A72) on the
Versal require this.

I take that requirement as saying we should keep away from anything that relates
to secure operations even for those cores that allow open access. FreeBSD and
Linux do not touch these registers and I think that is a wise path to follow.

> 3. What RTEMS needs to initialize

We have to assume this is handled by the code that is responsible for
establishing the secure state. For those cores that do not have or require a
vertical software stack it may be OK for the BSP may hold that configuration.

> We cannot simply use the target architecture to determine what to do during GIC
> initialization.

Does the GiC need to handle this?

> I think we need some BSP options to control the initialization behaviour.

I am not sure this should be the responsibility of the BSP and RTEMS. I see it
as something the boot loaders and boot process should manage. For the ZynqMP and
Versal this and much much more is covered by TF-A. I recommend using TF-A for
the Versal simply because of support ARM provides in it ...

INFO:    GICv3 with legacy support detected.

INFO:    ARM GICv3 driver initialized in EL3

INFO:    BL31: Initializing runtime services
WARNING: BL31: cortex_a72: CPU workaround for 859971 was missing!
WARNING: BL31: cortex_a72: CPU workaround for 1319367 was missing!
INFO:    BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied
INFO:    BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied


I prefer we do not attempt to get involved and complicate what this code is doing.

Chris