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

[Sebastian Huber]

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.

> 
>> Why was the isb added?
> 
> https://github.com/freebsd/freebsd-src/blob/main/sys/arm64/arm64/gic_v3_reg.h#L458
> 
> Sorry I have no idea what specific role it plays. I just copied what they had
> and it worked.

Barrier instructions should be explicit and not hidden in some macro.

> 
>> Why was the IGRPEN0 write removed in
>> e70384d3f406251422bac64d11ff44570a678434?
> 
> Because it generates an exception to EL3 and a write does not work on aarch64
> hardware with a TF-A that secures this register.
> 
> A review of Linux and FreeBSD showed no access to this register and my brief and
> incomplete reading of the GICv3 showed they are related secure interrupts. It
> therefore makes sense they are secured and not accessible. Secure modes are the
> domain of EL3 code and not EL1.

I guess the group 0 and 1 interrupts are implementation defined from an 
architecture point of view. Are they mapped to secure/non-secure 
interrupts on your hardware? Which processor is this?

We probably have to make the initialization more flexible to work with 
multiple processor variants.

> 
> Please do not remove those calls.
> 
>> I have to check if the removed ICC_BPR0 is an issue for AArch32.
> 
> The variants do make this more complex. That arch may require a suitably
> configured vertical stack like the FPD scalar cores on the Versal does.
> 
> Chris

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/