ARM Cortex-A72 GICv3 Interrupt Handling Issues During EL3 to EL1 Transition

The ARM Cortex-A72 processor, when paired with the Generic Interrupt Controller (GIC) version 3, can exhibit complex interrupt handling issues during transitions between Exception Levels (ELs), particularly when moving from EL3 to EL1. These issues often manifest as interrupts not being correctly handled after the transition, leading to system instability or unresponsiveness. This post delves into the root causes of these issues, explores the underlying mechanisms of the GICv3 and ARMv8 architecture, and provides detailed troubleshooting steps to resolve them.

GICv3 SGI Handling Mismatch Between EL3 and EL1

The core issue revolves around the handling of Software Generated Interrupts (SGIs) in the GICv3 architecture, specifically when the ARM Cortex-A72 transitions from EL3 to EL1. SGIs are interrupts generated by software, typically used for inter-processor communication (IPC). In GICv3, SGIs can be generated using different registers, such as ICC_SGI1R_EL1, ICC_ASGI1R_EL1, or GICD_SGIR, and can be grouped into Secure Group1 (SG1) or Non-Secure Group1 (NSG1). The problem arises when SGIs generated at EL3 are not correctly handled after the transition to EL1, leading to missed or improperly routed interrupts.

The root cause of this issue lies in the configuration of the GICv3 registers and the mismatch between the sender and receiver configurations. When an SGI is generated, the sender specifies the interrupt group (G0, SG1, or NSG1), and the receiver must be configured to accept interrupts from that group. If there is a mismatch between the sender and receiver configurations, the interrupt will be dropped, leading to the observed behavior where only certain SGIs are handled correctly.

For example, if an SGI is generated as NSG1 using ICC_SGI1R_EL1 at EL3, but the receiver is configured to accept only SG1 interrupts, the interrupt will be dropped. Similarly, if an SGI is generated as SG1 using ICC_ASGI1R_EL1, but the receiver is configured to accept only NSG1 interrupts, the interrupt will also be dropped. This mismatch can occur due to incorrect configuration of the GICR_IGROUR0 and GICR_IGRPMODR0 registers, which control the group and mode of the interrupts for each CPU interface.

Configuration and State Transition Issues in GICv3 and ARMv8

The second part of the issue involves the configuration of the GICv3 and ARMv8 registers during the transition from EL3 to EL1. When the Cortex-A72 transitions from EL3 to EL1, several critical registers must be configured correctly to ensure that interrupts are handled properly in the new Exception Level. These include the SCR_EL3, HCR_EL2, ICC_SRE_EL2, ICC_SRE_EL1, and ICC_IGRPEN1_EL1 registers, among others.

One common mistake is failing to set the ARE_NS and ARE_S bits in the GICD_CTLR register, which enable the Affinity Routing Extension (ARE) for Non-Secure and Secure states, respectively. Without these bits set, the GICv3 will not route interrupts correctly to the CPU interfaces in the new Exception Level. Additionally, the ICC_SRE_EL2.SRE bit must be set to enable the System Register Interface for the GICv3 at EL2, and the ICC_SRE_EL1.SRE bit must be set in both banked copies of the ICC_SRE_EL1 register to enable the System Register Interface at EL1.

Another critical step is to ensure that the NS.G1 enable bit is set in both the CPU interface (ICC_IGRPEN1_EL1) and the Distributor (GICD_CTLR). This bit enables Non-Secure Group1 interrupts, which are typically used for inter-processor communication in the Non-Secure state. If this bit is not set, the CPU will not accept NSG1 interrupts, leading to missed interrupts.

Furthermore, before leaving EL3, the ICC_PMR_EL1 register must be programmed to a value in the Non-Secure range to ensure that the CPU accepts Non-Secure interrupts. The GICx_IGROUPRn and GICx_IGRPMODn registers must also be configured to make the appropriate interrupts Non-Secure Group1. Finally, the GICR_WAKER sequence must be completed to ensure that the Redistributor is awake and ready to handle interrupts.

Detailed Troubleshooting and Configuration Steps for GICv3 and ARMv8

To resolve the issues described above, follow these detailed troubleshooting and configuration steps:

  1. Verify SGI Configuration at EL3:

    • Ensure that the GICR_IGROUR0 and GICR_IGRPMODR0 registers are correctly configured for each SGI (INTID 0-15). These registers control the group and mode of the interrupts for each CPU interface. For example, if you want to generate NSG1 interrupts, ensure that the corresponding bits in GICR_IGROUR0 and GICR_IGRPMODR0 are set to Non-Secure Group1.

  2. Check Sender and Receiver Agreement:

    • When generating an SGI, ensure that the sender and receiver configurations match. For example, if the sender generates an SGI as NSG1 using ICC_SGI1R_EL1, the receiver must be configured to accept NSG1 interrupts. If there is a mismatch, the interrupt will be dropped.

  3. Configure GICv3 Registers for EL3 to EL1 Transition:

    • Set the ARE_NS and ARE_S bits in the GICD_CTLR register to enable Affinity Routing for Non-Secure and Secure states.
    • Set the ICC_SRE_EL2.SRE bit to enable the System Register Interface for the GICv3 at EL2.
    • Set the ICC_SRE_EL1.SRE bit in both banked copies of the ICC_SRE_EL1 register to enable the System Register Interface at EL1.
    • Set the NS.G1 enable bit in both the CPU interface (ICC_IGRPEN1_EL1) and the Distributor (GICD_CTLR).
    • Program the ICC_PMR_EL1 register to a value in the Non-Secure range before leaving EL3.
    • Configure the GICx_IGROUPRn and GICx_IGRPMODn registers to make the appropriate interrupts Non-Secure Group1.
    • Complete the GICR_WAKER sequence to ensure that the Redistributor is awake and ready to handle interrupts.

  4. Verify Interrupt State After Transition:

    • After transitioning to EL1, check the GICx_ISPENDRn register to ensure that the interrupt is pending. If the interrupt is not pending, it will not be sent to the CPU.
    • Check the GICx_ISACTIVERn register to ensure that the interrupt is not active. If the interrupt is active or active and pending, it will not be signaled.
    • Check the individual enable, group, priority, and target configuration for the interrupt.
    • Check the ICC_HPPIR0_EL1 and ICC_HPPIR1_EL1 registers to see if the interrupt was forwarded to the CPU. These registers are not affected by the Priority Mask Register (PMR) or Running Priority Register (RPR).
    • Check the ICC_RPR_EL1 register to ensure that it is in the "idle" state. If it is not idle, a new interrupt will only be signaled if it meets the preemption rules.
    • Ensure that the interrupt priority is numerically lower than the value in the ICC_PMR_EL1 register. If the priority is not lower, the interrupt will not be signaled.

  5. Handle FIQ and IRQ Correctly:

    • Ensure that the SCR_EL3.FIQ bit is not cleared while in Non-Secure state. In GICv3, FIQ is used for Group0 interrupts and interrupts for the other Security state. Clearing this bit can lead to missed interrupts in Non-Secure state.

By following these steps, you can ensure that the ARM Cortex-A72 and GICv3 are correctly configured to handle interrupts during the transition from EL3 to EL1, avoiding the issues described in this post.

Similar Posts

ARM Cortex-A53 Cache Invalidation Blocking Issue During DC IVAC Operation

ARM Cortex-A53 Cache Invalidation Blocking Issue During DC IVAC Operation

BySystem on Chips

ARM Cortex-A53 Cache Invalidation Blocking Issue During DC IVAC Operation The ARM Cortex-A53 processor, a widely used 64-bit ARMv8-A core, is known for its efficiency and performance in embedded systems. However, a specific issue has been observed when performing cache invalidation operations using the DC IVAC (Data Cache Invalidate by Virtual Address to PoC) instruction.

Write Interleaving Exclusion in AXI4 Protocol: Performance and Complexity Trade-offs

Write Interleaving Exclusion in AXI4 Protocol: Performance and Complexity Trade-offs

BySystem on Chips

Write Interleaving Exclusion in AXI4: Impact on Bandwidth and Throughput The exclusion of write data interleaving in the AXI4 protocol is a design decision that has significant implications for system performance, particularly in scenarios involving multiple masters with varying transmission speeds. Write interleaving, which was supported in the earlier AXI3 protocol, allows data from different

ARM Cortex-A53 Memory Access Latency Jitter During Multi-Core Computation

ARM Cortex-A53 Memory Access Latency Jitter During Multi-Core Computation

BySystem on Chips

ARM Cortex-A53 Cache Contention and Memory Access Latency Variability The ARM Cortex-A53 is a widely used processor core in embedded systems, known for its balance of power efficiency and performance. However, when executing computationally intensive tasks across multiple cores, particularly those involving large memory arrays, users may encounter significant variability in execution times. This variability,

tlm_quantumkeeper::set_global_quantum Impact on ARM Fast Models

tlm_quantumkeeper::set_global_quantum Impact on ARM Fast Models

BySystem on Chips

ARM Fast Models and tlm_global_quantum Synchronization Mechanism The synchronization mechanism in ARM Fast Models is heavily reliant on the SystemC TLM-2.0 standard, which introduces the concept of quantum-based synchronization to balance simulation performance and accuracy. The tlm_global_quantum API is a critical component of this mechanism, as it defines the global quantum size, which is the

Converting ARM DS Startup Files to IAR-Compatible Format for Cortex-R52

Converting ARM DS Startup Files to IAR-Compatible Format for Cortex-R52

BySystem on Chips

ARM Cortex-R52 Startup File Conversion Challenges Between ARM DS and IAR Toolchains The process of converting a startup assembly file from ARM DS (Arm Development Studio) to an IAR-compatible format for the Cortex-R52 processor involves understanding the differences in syntax, directives, and toolchain-specific requirements between the two environments. The Cortex-R52 is a high-performance, real-time processor

Cortex-A53 L2 Cache Invalidation and Performance Testing

Cortex-A53 L2 Cache Invalidation and Performance Testing

BySystem on Chips

Cortex-A53 L2 Cache Invalidation Mechanism The Cortex-A53 processor, part of ARM’s Cortex-A series, is a widely used 64-bit ARMv8-A core that features a multi-level cache hierarchy, including L1 and L2 caches. The L1 cache is split into instruction (L1 I-cache) and data (L1 D-cache) caches, while the L2 cache is typically unified, meaning it stores

Leave a Reply

Your email address will not be published. Required fields are marked *