Cortex-A55 Boot Process and AArch32-to-AArch64 Transition Challenges
The Cortex-A55 is a highly efficient 64-bit ARM processor that supports both AArch32 and AArch64 execution states. However, transitioning from AArch32 to AArch64 during the boot process can be complex, particularly when the system defaults to AArch32 at reset. This issue arises in scenarios where the BootROM and Bootloader operate in AArch32, but the subsequent operating system (e.g., Linux) requires AArch64. The challenge lies in the architectural constraints of ARMv8/9-A, which dictate that an AArch64 entity can host AArch32 children, but not vice versa. This means that if the BootROM or Bootloader operates in AArch32 at a higher exception level than the OS, transitioning to AArch64 becomes problematic without a reset.
The Cortex-A55’s execution state at reset is determined by a hardware signal, often controlled by a system control processor or similar management unit. If this signal is configured to boot in AArch32, the processor will start in 32-bit mode, and switching to AArch64 without a reset is not feasible. Conversely, if the processor boots in AArch64 but the BootROM or Bootloader switches to AArch32, software modifications are required to ensure a smooth transition to AArch64 for the OS. Understanding these constraints is critical for designing a boot process that successfully transitions from AArch32 to AArch64.
Hardware Signal Configuration and Bootloader Modifications
The root cause of the AArch32-to-AArch64 transition issue lies in the hardware signal configuration and the software implementation of the BootROM and Bootloader. The Cortex-A55’s execution state at reset is controlled by the RESET signal, which determines whether the processor starts in AArch32 or AArch64. This signal is typically managed by a system control processor or a similar hardware component on the SoC. If the RESET signal is configured to boot in AArch32, the processor will remain in 32-bit mode until a reset occurs, making it impossible to switch to AArch64 without restarting the system.
Additionally, the BootROM and Bootloader play a crucial role in the transition process. If the BootROM operates in AArch32 and hands control to a Bootloader that also operates in AArch32, the system will remain in 32-bit mode unless the Bootloader is explicitly designed to switch to AArch64. However, this switch is only possible if the Bootloader operates at an exception level that allows such a transition. For example, if the Bootloader runs at EL3 (Secure Monitor) or EL2 (Hypervisor), it can potentially switch to AArch64 before handing control to the OS. However, if the Bootloader operates at EL1 (OS level) in AArch32, it cannot host an AArch64 OS, as this violates the ARMv8/9-A architectural rule.
To address these challenges, it is essential to examine the hardware signal configuration and the Bootloader’s exception level and execution state. If the RESET signal is configurable, it should be set to boot in AArch64 to avoid the need for a transition. If the signal is fixed, the Bootloader must be modified to operate in AArch64 or at an exception level that permits the transition. This may involve rewriting parts of the Bootloader or introducing additional firmware components to facilitate the switch.
Implementing AArch64 Transition in Bootloader and OS Integration
To successfully transition from AArch32 to AArch64, the Bootloader must be carefully designed to handle the switch before handing control to the OS. This involves several steps, including configuring the processor state, managing exception levels, and ensuring compatibility with the OS. Below is a detailed guide to implementing the AArch64 transition:
Step 1: Verify Hardware Signal Configuration
The first step is to verify the configuration of the RESET signal that determines the Cortex-A55’s execution state at boot. This signal is typically controlled by a system control processor or a similar hardware component. If the signal is configurable, it should be set to boot in AArch64 to simplify the transition process. If the signal is fixed and defaults to AArch32, the Bootloader must handle the transition.
Step 2: Modify Bootloader to Operate in AArch64
If the Bootloader operates in AArch32, it must be modified to switch to AArch64 before handing control to the OS. This involves updating the Bootloader’s exception level and execution state. For example, if the Bootloader runs at EL3 or EL2, it can switch to AArch64 by setting the appropriate bits in the SCR_EL3 or HCR_EL2 registers. The following code snippet demonstrates how to switch from AArch32 to AArch64 at EL3:
// Switch to AArch64 at EL3
MOV X0, #0x3C5 // Set SCR_EL3.RW bit to 1 (AArch64) and SCR_EL3.NS bit to 1 (Non-secure)
MSR SCR_EL3, X0
ERET // Return to AArch64 mode
Step 3: Ensure Compatibility with the OS
Once the Bootloader has switched to AArch64, it must ensure that the OS is compatible with the new execution state. This involves configuring the memory map, setting up the exception vectors, and initializing the necessary hardware components. The Bootloader must also pass control to the OS at the correct exception level (typically EL1 for Linux).
Step 4: Test and Validate the Transition
After implementing the AArch64 transition, it is essential to test and validate the boot process to ensure that the system operates correctly. This includes verifying that the Bootloader successfully switches to AArch64, that the OS boots in 64-bit mode, and that all hardware components are properly initialized.
Step 5: Handle Edge Cases and Debugging
During testing, edge cases and potential issues may arise, such as incorrect exception level transitions or hardware initialization failures. These issues can be debugged using tools such as JTAG debuggers or serial consoles. It is also important to consult the ARM documentation for detailed information on the Cortex-A55’s behavior during state transitions.
By following these steps, developers can successfully transition from AArch32 to AArch64 on the Cortex-A55, enabling the use of 64-bit operating systems and applications. This process requires a deep understanding of the ARM architecture, careful hardware and software design, and thorough testing to ensure a reliable and efficient boot process.
