ARM Cortex-A72 GIC-500v SGI0 Triggering Failure After Initial Success

ARM Cortex-A72 SGI0 Interrupt Handling and Group Configuration Mismatch

The issue at hand involves the failure of Software Generated Interrupts (SGIs) to trigger a second time on an ARM Cortex-A72 processor using the GIC-500v interrupt controller. The initial setup and triggering of SGIs (SGI0 to SGI15) work correctly, but subsequent attempts to trigger any SGI fail. The root cause lies in the mismatch between the interrupt group configuration in the GICR_IGROUPR0 register and the group specified when generating the SGI via the ICC_SGI0R_EL1 register. This mismatch causes the GIC to drop the interrupt request, preventing it from entering the pending state.

The GIC-500v interrupt controller uses a group-based system to manage interrupts, where each interrupt can be assigned to one of two groups: Group 0 (G0) or Group 1 (G1). The group assignment is crucial because the GIC compares the group specified by the sender (via ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1) with the group configured for the interrupt in the receiver’s GICR_IGROUPR0 register. If the groups do not match, the interrupt request is discarded.

In the initial setup, the SGIs are assigned to Group 0 by default, and the first round of interrupts is successfully triggered and handled. However, after the interrupts are handled, the code modifies the GICR_IGROUPR0 register to assign the SGIs to Group 1. When the code attempts to trigger the SGIs again using ICC_SGI0R_EL1 (which specifies Group 0), the GIC detects the group mismatch and drops the interrupt request. This results in the SGIs not entering the pending state, and the interrupts are not delivered to the Cortex-A72.

GIC Group Configuration and SGI Generation Register Mismatch

The primary cause of the issue is the mismatch between the group configuration in the GICR_IGROUPR0 register and the group specified in the ICC_SGI0R_EL1 register. The GICR_IGROUPR0 register determines the group assignment for each SGI, while the ICC_SGI0R_EL1 register specifies the group when generating the SGI. If these groups do not match, the GIC will not deliver the interrupt.

Additionally, the absence of a Data Synchronization Barrier (DSB SY) between the write to the ICC_SGI0R_EL1 register and the read of the GICR_IPENDR0 register could contribute to the issue. The DSB SY instruction ensures that all previous memory accesses are completed before proceeding, which is critical when dealing with memory-mapped registers in a multi-core system. Without this barrier, the processor might read stale data from the GICR_IPENDR0 register, leading to incorrect assumptions about the interrupt state.

Another potential cause is the incorrect handling of the End of Interrupt (EOI) process. If the EOI is not correctly acknowledged by writing to the GICC_EOIR0 register, the interrupt may remain active, preventing subsequent interrupts from being triggered. This could also lead to the GIC not recognizing new interrupt requests, as it may still consider the previous interrupt as pending.

Correcting GIC Group Configuration and Implementing Proper Synchronization

To resolve the issue, the following steps should be taken:

1. Ensure Consistent Group Configuration: The GICR_IGROUPR0 register should not be modified after the initial setup if the intention is to keep the SGIs in Group 0. If the SGIs need to be in Group 1, the ICC_SGI1R_EL1 register should be used to generate the interrupts instead of ICC_SGI0R_EL1. This ensures that the group specified during SGI generation matches the group configured in the GICR_IGROUPR0 register.

2. Add Data Synchronization Barriers: Insert a DSB SY instruction after writing to the ICC_SGI0R_EL1 register and before reading the GICR_IPENDR0 register. This ensures that the write to the ICC_SGI0R_EL1 register is completed before the read operation, preventing the processor from reading stale data.

3. Correct End of Interrupt Handling: Ensure that the EOI process is correctly handled by writing to the GICC_EOIR0 register after the interrupt has been serviced. This acknowledges the interrupt and allows the GIC to clear the pending state, enabling subsequent interrupts to be triggered.

4. Verify Exception Level and Security State: Ensure that the processor remains in the same Exception Level (EL) and Security State throughout the test. Changes in EL or Security State could affect the behavior of the GIC and the interrupt handling process.

5. Review Legacy Code: Legacy code may contain unnecessary or incorrect register accesses, such as modifying the GICR_IGROUPR0 register after enabling interrupts. Review and clean up the code to ensure that only necessary and correct configurations are applied.

By following these steps, the issue of SGIs not triggering a second time can be resolved. The key is to ensure that the group configuration in the GICR_IGROUPR0 register matches the group specified during SGI generation and to implement proper synchronization and interrupt handling practices.

Detailed Explanation of GIC Group Configuration and SGI Generation

The ARM Generic Interrupt Controller (GIC) architecture provides a flexible mechanism for managing interrupts in multi-core systems. The GIC-500v, used in this scenario, supports Software Generated Interrupts (SGIs), which are interrupts generated by software for inter-processor communication. Each SGI can be assigned to one of two groups: Group 0 (G0) or Group 1 (G1). The group assignment determines how the interrupt is handled and which security state it belongs to.

The GICR_IGROUPR0 register is used to configure the group assignment for each SGI. By default, all SGIs are assigned to Group 0 at reset. The ICC_SGI0R_EL1, ICC_SGI1R_EL1, and ICC_ASGI1R_EL1 registers are used to generate SGIs, with each register specifying the group of the interrupt being generated. The GIC compares the group specified during SGI generation with the group configured in the GICR_IGROUPR0 register. If the groups match, the interrupt is delivered; otherwise, it is dropped.

In the initial setup, the SGIs are assigned to Group 0, and the first round of interrupts is successfully triggered and handled. However, after the interrupts are handled, the code modifies the GICR_IGROUPR0 register to assign the SGIs to Group 1. When the code attempts to trigger the SGIs again using ICC_SGI0R_EL1 (which specifies Group 0), the GIC detects the group mismatch and drops the interrupt request. This results in the SGIs not entering the pending state, and the interrupts are not delivered to the Cortex-A72.

To avoid this issue, the group configuration in the GICR_IGROUPR0 register should remain consistent with the group specified during SGI generation. If the SGIs need to be in Group 1, the ICC_SGI1R_EL1 register should be used to generate the interrupts instead of ICC_SGI0R_EL1. This ensures that the group specified during SGI generation matches the group configured in the GICR_IGROUPR0 register.

Importance of Data Synchronization Barriers in GIC Operations

In multi-core systems, proper synchronization is critical to ensure that memory-mapped register accesses are completed in the correct order. The ARM architecture provides several synchronization instructions, including the Data Synchronization Barrier (DSB) and Instruction Synchronization Barrier (ISB). These instructions ensure that all previous memory accesses are completed before proceeding, preventing the processor from reading stale data or executing outdated instructions.

In the context of the GIC, a DSB SY instruction should be inserted after writing to the ICC_SGI0R_EL1 register and before reading the GICR_IPENDR0 register. This ensures that the write to the ICC_SGI0R_EL1 register is completed before the read operation, preventing the processor from reading stale data from the GICR_IPENDR0 register. Without this barrier, the processor might read an incorrect value from the GICR_IPENDR0 register, leading to incorrect assumptions about the interrupt state.

For example, consider the following code sequence:

// Generate SGI0
MOV X0, #0x1
MSR ICC_SGI0R_EL1, X0

// Add DSB SY to ensure the write is completed
DSB SY

// Read GICR_IPENDR0 to check if the interrupt is pending
MRS X1, GICR_IPENDR0

In this sequence, the DSB SY instruction ensures that the write to the ICC_SGI0R_EL1 register is completed before the read of the GICR_IPENDR0 register. This prevents the processor from reading stale data and ensures that the interrupt state is correctly reflected