ARM Cortex-A35 EL3 to Non-Secure EL1 Transition Failure
The core issue revolves around the inability to successfully transition from Exception Level 3 (EL3) to non-secure Exception Level 1 (EL1) on an ARM Cortex-A35 processor operating in AArch64 mode. The user attempted to switch from EL3 to non-secure EL1 by configuring the Secure Configuration Register (SCR_EL3), Saved Program Status Register (SPSR_EL3), and Exception Link Register (ELR_EL3). While the transition to secure EL1 works as expected, the transition to non-secure EL1 fails, resulting in the inability to control peripherals such as an LED. The failure manifests despite the correct configuration of system registers, including the System Control Register (SCTLR_EL1) and Hypervisor Configuration Register (HCR_EL2).
The problem is further complicated by the possibility that the peripherals, such as the GPIO controller responsible for the LED, might be configured as secure devices. This would restrict access to these peripherals when operating in non-secure EL1. The absence of a debugger exacerbates the issue, as the user relies on UART output and LED status for debugging. The discussion highlights the importance of understanding the ARM TrustZone architecture, which partitions resources into secure and non-secure worlds, and how this partitioning affects peripheral access.
Secure vs. Non-Secure Peripheral Configuration and TrustZone Implications
The primary cause of the issue lies in the configuration of the ARM TrustZone security state and its impact on peripheral access. ARM TrustZone introduces a hardware-based security mechanism that partitions the system into secure and non-secure worlds. This partitioning extends to memory, peripherals, and other system resources. By default, peripherals such as GPIO controllers are often configured as secure devices, meaning they can only be accessed when the processor is in the secure state. When the processor transitions to non-secure EL1, access to these secure peripherals is restricted, leading to the observed failure.
The Secure Configuration Register (SCR_EL3) plays a critical role in determining the security state of the processor. The user correctly sets the SCR_EL3.NS bit to transition to the non-secure state. However, the peripheral access issue suggests that the GPIO controller remains configured as a secure device. This configuration is typically managed by the SoC’s TrustZone Address Space Controller (TZASC) or TrustZone Protection Controller (TZPC), which enforce access restrictions based on the security state.
Another potential cause is the omission of necessary configurations in the Hypervisor Configuration Register (HCR_EL2). While the user attempted to set the HCR_EL2.RW bit to ensure that EL1 operates in AArch64 mode, this alone may not be sufficient. Additional configurations, such as enabling the Virtualization Extensions or configuring the Memory Management Unit (MMU), might be required to ensure proper operation in non-secure EL1.
The absence of a debugger further complicates the diagnosis, as the user cannot directly inspect the state of system registers or memory during the transition. This limitation underscores the importance of leveraging alternative debugging techniques, such as UART output or LED status changes, to infer the system’s behavior.
Verifying Peripheral Security State and Implementing Secure-to-Non-Secure Transitions
To resolve the issue, a systematic approach is required to verify the peripheral security state and ensure proper configuration of system registers during the transition from EL3 to non-secure EL1. The following steps outline the troubleshooting process and potential solutions:
Step 1: Verify Peripheral Security Configuration
The first step is to confirm whether the GPIO controller is configured as a secure device. This can be achieved by inspecting the SoC’s documentation or using a debugger to examine the TrustZone configuration registers. If a debugger is unavailable, the user can implement a software-based check by attempting to access the peripheral in both secure and non-secure states and observing the behavior.
For example, the user can modify the code to transition to non-secure EL1, attempt to access the GPIO controller, and then transition back to secure EL1 to verify the access attempt. If the access fails in non-secure EL1 but succeeds in secure EL1, this confirms that the peripheral is configured as a secure device.
Step 2: Configure Peripherals for Non-Secure Access
If the GPIO controller is confirmed to be a secure device, the next step is to reconfigure it for non-secure access. This typically involves modifying the TrustZone configuration registers, such as the TZASC or TZPC, to mark the peripheral’s memory region as non-secure. The exact procedure depends on the SoC’s implementation and should be detailed in the hardware reference manual.
For the Rockchip RK3308-based board, the user should consult the board’s documentation to identify the relevant TrustZone configuration registers. Once identified, the user can modify these registers in EL3 before transitioning to non-secure EL1. This ensures that the GPIO controller is accessible in the non-secure state.
Step 3: Validate System Register Configurations
The user should thoroughly validate the configurations of all relevant system registers, including SCR_EL3, SPSR_EL3, ELR_EL3, SCTLR_EL1, and HCR_EL2. The following table summarizes the required configurations for a successful transition to non-secure EL1:
| Register | Field | Value/Configuration | Purpose |
|---|---|---|---|
| SCR_EL3 | NS | 1 | Transition to non-secure state |
| SCR_EL3 | RW | 1 | Ensure EL1 operates in AArch64 mode |
| SCR_EL3 | ST | 1 | Enable secure timer |
| SPSR_EL3 | M[3:0] | 0b0101 (EL1h) | Set exception level and stack pointer selection |
| SPSR_EL3 | A, I, F | 1 | Mask asynchronous exceptions |
| ELR_EL3 | Return Address | Address of __el1 label |
Set return address after ERET |
| SCTLR_EL1 | M, C, I | As per reset values (e.g., 0x00C50838) | Configure MMU, cache, and instruction fetch |
| HCR_EL2 | RW | 1 | Ensure EL1 operates in AArch64 mode |
Step 4: Implement Debugging Mechanisms
In the absence of a debugger, the user should implement additional debugging mechanisms to monitor the system’s state during the transition. For example, the user can use UART output to log the values of critical registers before and after the transition. This provides visibility into the system’s behavior and helps identify any misconfigurations.
Additionally, the user can modify the code to perform a simple memory access test in non-secure EL1. For instance, the user can write a known value to a memory location and then read it back to verify that the access is successful. This test helps confirm that the processor is operating in the correct state and that memory access is functioning as expected.
Step 5: Test and Iterate
After implementing the above steps, the user should test the system to verify that the transition to non-secure EL1 is successful and that peripheral access is restored. If the issue persists, the user should revisit the configurations and repeat the validation process. It may also be helpful to consult the ARM Architecture Reference Manual and the SoC’s documentation for additional insights and troubleshooting tips.
By following this systematic approach, the user can identify and resolve the root cause of the EL3 to non-secure EL1 transition failure. The key takeaway is the importance of understanding the ARM TrustZone architecture and its impact on peripheral access, as well as the need for thorough validation of system register configurations.
