On 6/27/2022 01: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, chr...@rtems.org wrote:
From: Chris Johns <chr...@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 have reverified that this code works on my ZCU102 (ZynqMP) dev board
with just the write to IGRPEN1, but I'm not sure it's what Chris would
consider a suitably configured TF-A since it's a bit stale.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
