FVP Base RevC Stuck When Accessing PIR_EL1 and POR_EL1 Registers
The FVP Base RevC model, specifically version 1125, is designed to emulate ARM-based systems and is widely used for pre-silicon software development and verification. A critical aspect of its functionality is the support for advanced ARM architecture extensions, such as the ARMv8.9-A Permission Indirection Extension (PIE) and Permission Overlay Extension (POE). These extensions introduce new system registers, including PIR_EL1 and POR_EL1, which are essential for managing memory permissions in a more flexible and granular manner. However, during the verification process, the FVP Base RevC model exhibits unexpected behavior when attempting to access these registers, causing the system to hang. This issue raises questions about the model’s support for ARMv8.9-A features and the correct configuration required to enable these extensions.
The problem manifests when running UEFI firmware (edk2) on the FVP Base RevC model. The firmware includes a modification to read and print the values of ID_AA64MMFR3_EL1, PIR_EL1, and POR_EL1 registers. While ID_AA64MMFR3_EL1 is successfully read, indicating support for PIE and POE, the system hangs when attempting to access PIR_EL1 and POR_EL1. This behavior suggests a potential mismatch between the expected and actual implementation of these registers in the FVP model. The issue is further complicated by the fact that enabling the has_arm_v8-9 parameter, which is required to activate ARMv8.9-A features, does not resolve the problem. This indicates that the root cause may lie deeper in the configuration or implementation of the FVP model.
Misconfiguration of ARMv8.9-A Extensions and FVP Model Limitations
One of the primary causes of the issue is the misconfiguration of the FVP Base RevC model to fully support ARMv8.9-A extensions. The has_arm_v8-9 parameter, which is necessary to enable ARMv8.9-A features, is set to 1 in the FVP configuration. However, this parameter is described as "incomplete and under development" in the documentation, suggesting that the implementation of ARMv8.9-A features in the FVP model may not be fully functional. This is further evidenced by the fact that setting has_arm_v8-9 to 2, which would imply full support, is explicitly disallowed by the FVP model, indicating a limitation in the current implementation.
Another potential cause is the interaction between the UEFI firmware and the FVP model. The UEFI firmware is designed to run on physical hardware and may include assumptions about the behavior of system registers that are not fully emulated in the FVP model. For example, the firmware may expect certain side effects or timing characteristics when accessing PIR_EL1 and POR_EL1 that are not accurately replicated in the FVP model. This mismatch between firmware expectations and model behavior can lead to undefined or unexpected system states, causing the model to hang.
Additionally, the FVP model’s handling of system registers may not fully align with the ARM architecture specification for ARMv8.9-A. The ID_AA64MMFR3_EL1 register correctly reports support for PIE and POE, but the actual implementation of PIR_EL1 and POR_EL1 may be incomplete or incorrect. This discrepancy between reported and actual support can lead to issues when software attempts to use these registers, as the model may not handle the register accesses as expected.
Enabling ARMv8.9-A Features and Debugging FVP Model Behavior
To address the issue, the first step is to ensure that the FVP Base RevC model is correctly configured to support ARMv8.9-A features. This involves setting the has_arm_v8-9 parameter to 1 for all clusters in the FVP configuration. However, given the incomplete nature of this parameter, it is also necessary to verify that the FVP model being used is the latest version, as newer versions may include updates and bug fixes related to ARMv8.9-A support. If the issue persists, it may be necessary to consult the FVP documentation and release notes for any known issues or limitations related to ARMv8.9-A.
Next, the UEFI firmware should be modified to include additional debugging information when accessing PIR_EL1 and POR_EL1. This can be achieved by adding logging statements before and after the register accesses to capture the system state and identify any anomalies. Additionally, the firmware should be compiled with debugging symbols enabled, allowing for more detailed analysis of the issue using tools such as GDB or the FVP’s built-in debugging capabilities.
The use of the TarmacTrace plugin is highly recommended for debugging this issue. TarmacTrace provides detailed trace information for each instruction executed by the FVP model, including register accesses and system state changes. By enabling TarmacTrace, it is possible to capture the exact sequence of events leading up to the system hang, providing valuable insights into the root cause of the issue. The trace output can be analyzed to determine whether the FVP model is correctly handling the PIR_EL1 and POR_EL1 register accesses and whether there are any unexpected side effects or timing issues.
If the issue is determined to be related to the FVP model’s implementation of ARMv8.9-A features, it may be necessary to work around the limitation by modifying the UEFI firmware to avoid accessing PIR_EL1 and POR_EL1 until the issue is resolved. This can be achieved by adding conditional logic to the firmware to check the value of ID_AA64MMFR3_EL1 and only attempt to access PIR_EL1 and POR_EL1 if the model is confirmed to fully support these registers. Alternatively, the firmware can be modified to use alternative methods for managing memory permissions that do not rely on PIE and POE.
Finally, if the issue cannot be resolved through configuration or firmware modifications, it may be necessary to escalate the issue to ARM support. Providing detailed information about the FVP model version, configuration, and the steps taken to reproduce the issue will help ARM engineers diagnose and address the problem. This may include submitting a bug report with the FVP trace logs and firmware source code, as well as any additional information that can assist in reproducing the issue.
In conclusion, the issue of the FVP Base RevC model hanging when accessing PIR_EL1 and POR_EL1 registers is likely due to a combination of misconfiguration, incomplete implementation of ARMv8.9-A features, and potential firmware assumptions. By carefully configuring the FVP model, adding debugging information to the firmware, and using tools such as TarmacTrace, it is possible to identify and work around the issue. However, if the problem persists, escalation to ARM support may be necessary to ensure that the FVP model fully supports the ARMv8.9-A architecture extensions.
