Handling Custom Interrupts with Specific IDs in ARM Trusted Firmware

ARM Trusted Firmware Interrupt Framework Limitations and Custom Handler Requirements

The ARM Trusted Firmware (ATF) provides a robust framework for managing interrupts in secure and non-secure environments. However, one of the limitations of the ATF interrupt framework is the inability to directly register an interrupt handler with a specific interrupt ID. The framework reserves the INTR_ID_UNAVAILABLE parameter, which prevents developers from associating custom handlers with particular interrupt IDs. This limitation becomes problematic when developers need to handle specific interrupts, such as Performance Monitoring Unit (PMU) interrupts, which are critical for performance analysis and optimization in ARM-based systems.

The PMU interrupt, for instance, is often assigned a specific interrupt ID (e.g., ID 34 on the Juno board). Without the ability to register a custom handler for this ID, developers cannot directly manage PMU interrupts within the ATF framework. This limitation stems from the design philosophy of the ATF, which prioritizes security and abstraction over direct hardware manipulation. While this approach ensures a secure and stable environment, it can complicate the implementation of low-level, hardware-specific functionalities.

To address this issue, developers must understand the underlying mechanisms of the ATF interrupt framework, including how interrupts are acknowledged, identified, and routed. The framework relies on a combination of platform-specific and generic interrupt controller APIs to manage interrupts. By leveraging these APIs, developers can work around the limitation and implement custom interrupt handlers for specific IDs.

Missing Interrupt ID Registration and Platform-Specific Interrupt Handling

The inability to register custom interrupt handlers with specific IDs in the ARM Trusted Firmware is primarily due to the framework’s abstraction layer. The ATF abstracts the interrupt handling process to ensure compatibility across different ARM platforms and to maintain a secure execution environment. However, this abstraction can obscure the direct manipulation of interrupt IDs, making it challenging to implement platform-specific interrupt handling logic.

One of the key challenges is the lack of a direct API to register an interrupt handler with a specific ID. The INTR_ID_UNAVAILABLE parameter is used to indicate that the interrupt ID is not available for registration, which effectively blocks developers from associating custom handlers with specific IDs. This limitation is particularly problematic for interrupts that are critical for platform-specific functionalities, such as PMU interrupts.

To work around this limitation, developers must rely on platform-specific interrupt controller APIs. These APIs provide low-level access to the interrupt controller, allowing developers to acknowledge and identify interrupts. For example, the plat_ic_acknowledge_interrupt() and plat_ic_get_interrupt_id() APIs can be used to retrieve the raw interrupt data and extract the interrupt ID. By using these APIs, developers can implement custom interrupt handling logic that bypasses the ATF’s abstraction layer.

The plat_ic_acknowledge_interrupt() API acknowledges the interrupt and returns the raw interrupt data, which includes the interrupt ID. The plat_ic_get_interrupt_id() API extracts the interrupt ID from the raw data. By combining these APIs, developers can identify the interrupt ID and implement custom handling logic based on the ID. This approach allows developers to handle specific interrupts, such as PMU interrupts, without directly registering a handler with the ATF framework.

Implementing Custom Interrupt Handlers Using Platform-Specific APIs

To implement a custom interrupt handler for a specific interrupt ID in the ARM Trusted Firmware, developers must leverage platform-specific interrupt controller APIs. The following steps outline the process of implementing a custom interrupt handler for a specific ID, such as the PMU interrupt with ID 34 on the Juno board.

First, developers must identify the platform-specific interrupt controller APIs that provide access to the interrupt controller. These APIs are typically defined in the platform-specific code of the ATF. For example, the plat_ic_acknowledge_interrupt() and plat_ic_get_interrupt_id() APIs are used to acknowledge interrupts and retrieve the interrupt ID.

Once the appropriate APIs are identified, developers can implement a custom interrupt handler that uses these APIs to identify and handle specific interrupts. The custom handler should be implemented in the EL3 runtime firmware, which is responsible for handling secure interrupts. The following code snippet demonstrates how to implement a custom interrupt handler for the PMU interrupt with ID 34:

void custom_pmu_interrupt_handler(void) {
    uint32_t intr_raw;
    uint32_t intr_id;

    // Acknowledge the interrupt and get the raw interrupt data
    intr_raw = plat_ic_acknowledge_interrupt();

    // Extract the interrupt ID from the raw data
    intr_id = plat_ic_get_interrupt_id(intr_raw);

    // Check if the interrupt ID matches the PMU interrupt ID
    if (intr_id == 34) {
        // Handle the PMU interrupt
        handle_pmu_interrupt();
    }

    // End of interrupt handling
    plat_ic_end_of_interrupt(intr_id);
}

In this code snippet, the custom_pmu_interrupt_handler() function is the custom interrupt handler for the PMU interrupt. The function first acknowledges the interrupt and retrieves the raw interrupt data using the plat_ic_acknowledge_interrupt() API. It then extracts the interrupt ID from the raw data using the plat_ic_get_interrupt_id() API. If the interrupt ID matches the PMU interrupt ID (34), the function calls the handle_pmu_interrupt() function to handle the PMU interrupt. Finally, the function signals the end of interrupt handling using the plat_ic_end_of_interrupt() API.

To integrate the custom interrupt handler into the ATF framework, developers must register the handler with the EL3 runtime firmware. This can be done by modifying the platform-specific code in the ATF to include the custom handler. The following code snippet demonstrates how to register the custom handler:

void plat_interrupt_handler(void) {
    // Call the custom PMU interrupt handler
    custom_pmu_interrupt_handler();
}

In this code snippet, the plat_interrupt_handler() function is the platform-specific interrupt handler that is registered with the EL3 runtime firmware. The function calls the custom_pmu_interrupt_handler() function to handle the PMU interrupt. By modifying the platform-specific code in this way, developers can integrate custom interrupt handlers into the ATF framework.

In addition to implementing the custom interrupt handler, developers must also ensure that the interrupt controller is properly configured to route the PMU interrupt to the EL3 runtime firmware. This typically involves modifying the platform-specific interrupt controller configuration code in the ATF. The following code snippet demonstrates how to configure the interrupt controller to route the PMU interrupt to the EL3 runtime firmware:

void plat_configure_interrupts(void) {
    // Configure the interrupt controller to route the PMU interrupt to EL3
    plat_ic_set_interrupt_type(34, INTR_TYPE_EL3);
}

In this code snippet, the plat_configure_interrupts() function configures the interrupt controller to route the PMU interrupt with ID 34 to the EL3 runtime firmware. The plat_ic_set_interrupt_type() API is used to set the interrupt type to INTR_TYPE_EL3, which ensures that the interrupt is routed to the EL3 runtime firmware.

By following these steps, developers can implement custom interrupt handlers for specific interrupt IDs in the ARM Trusted Firmware. This approach allows developers to handle platform-specific interrupts, such as PMU interrupts, without directly registering a handler with the ATF framework. While this workaround requires a deeper understanding of the platform-specific interrupt controller APIs, it provides a flexible and powerful way to implement custom interrupt handling logic in the ATF.

Conclusion

The ARM Trusted Firmware provides a secure and abstracted framework for managing interrupts, but its limitations can complicate the implementation of custom interrupt handlers for specific IDs. By leveraging platform-specific interrupt controller APIs, developers can work around these limitations and implement custom interrupt handling logic. The process involves acknowledging and identifying interrupts using APIs such as plat_ic_acknowledge_interrupt() and plat_ic_get_interrupt_id(), and integrating custom handlers into the EL3 runtime firmware. With this approach, developers can handle platform-specific interrupts, such as PMU interrupts, while maintaining the security and stability of the ARM Trusted Firmware.