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.
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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
