2.3.4. Backwards compatibility

You can configure the Distributor part of the GIC-500 at build time to support limited backwards compatibility with GICv2. If this support is configured, the Distributor resets to backwards compatibility mode. This mode supports up to eight cores. The eight cores supported by the GIC-500 are the cores with the lowest affinity numbers.

The ARE setting in GICD_CTLR, which disables backwards compatibility, is programmable when backwards compatibility support is configured. The ARE setting is also banked by security. This allows Secure software to operate in backwards compatibility mode (ARE_S = 0) while Non-secure software enables ARE. If Secure software is not operating in backwards compatibility mode then Non-secure software cannot operate in backwards compatibility mode.

Note

A major limitation of operating with Non-secure using ARE_NS = 1 and Secure using ARE_S = 0 is that legacy Secure software is not able to control Non-secure interrupts. This means that existing Secure Monitor code that relies on having this control cannot run correctly using this mode of backwards compatibility. See the ARM® Generic Interrupt Controller Architecture Specification version 3.0 for more information on this limitation.

The GIC-500 can expose software to more race conditions than previous GIC implementations. Legacy code that relies on the stronger guarantees provided in these previous GICs might not work reliably. For example, some GIC implementations ensure that a sequence of accesses to both the CPU interface and Distributor is executed in program order. However, the ordering between the Distributor and CPU interface is not architecturally guaranteed and is not guaranteed in systems with the GIC-500.

In backwards compatibility mode, the GIC-500 ensures that the effects of all interrupt programming are eventually observable, so you only have to update software that relies on the reprogramming being observable by a specific point. Software typically only requires these ordering guarantees during operations such as retargeting SPIs, if it must be ensured that the previous target does not receive the SPI, or saving the state of a Distributor.

If your software relies on these guarantees, you must update your software using the following guidance:

The GIC-500 might also implement different implementation defined choices than previous implementations. For example, the GIC-400 did not set an interrupt pending if the interrupt group for that interrupt was disabled in the GICD_CTLR. In contrast, the GIC-500 does set interrupts pending in this scenario.

It is expected that legacy power management code is not compatible and has to be updated for operation with the GIC-500. For example, GICR_WAKER.ProcessorSleep must be set to zero after reset to enable interrupts to be sent to a core. Likewise, the powerdown sequence requires writing to GICR_WAKER. The GICR_WAKER register is new in version three of the GIC architecture and therefore you must update legacy code to use it.

Copyright © 2014 ARM. All rights reserved.ARM DDI 0516B
Non-ConfidentialID060914