UEFI Differences: 64-Bit x86 vs ARM Platforms

While the Unified Extensible Firmware Interface (UEFI) specification defines a standard abstraction layer between system firmware and the operating system, its real-world implementation diverges considerably between 64-bit x86 (x86-64) and ARM-based platforms. These differences stem primarily from hardware ecosystem design: x86-64 benefits from decades of standardized IBM-PC legacy architectures, whereas ARM platforms represent a heterogeneous landscape of diverse Systems-on-Chip (SoCs). Consequently, UEFI implementations across both architectures differ across hardware description standards, boot stages, security privilege levels, and power management workflows.

Hardware Discovery: ACPI vs. Device Tree

On 64-bit x86 systems, hardware discovery relies almost exclusively on the Advanced Configuration and Power Interface (ACPI). Because x86 platforms follow rigid platform baselines and utilize self-describing buses such as PCI Express, the UEFI environment constructs standard ACPI tables (like DSDT and SSDT) to inform the operating system about non-enumerable devices, interrupts, and power controls.

ARM platforms do not universally adhere to ACPI. Instead, the ecosystem is divided:

• Enterprise and Server ARM: Adheres to standards such as the Arm Server Base Boot Requirements (SBBR), mandating UEFI and ACPI to match the operational consistency of x86 servers.
• Embedded, Client, and Edge ARM: Frequently utilizes Device Trees (flattened device trees, or FDT) alongside or instead of ACPI. Under the Embedded Base Boot Requirements (EBBR), an ARM UEFI implementation often consumes or provides a Device Tree file to dynamically pass hardware topology and memory maps to the kernel.

Initialization Workflow and Privilege Levels

The execution flow from the moment the CPU powers on to when the UEFI application executes differs fundamentally in state management and privilege modes.

On x86-64 platforms, the CPU typically resets into a legacy 16-bit real mode state. The initial phases of UEFI—specifically the Security (SEC) and Pre-EFI Initialization (PEI) phases—are responsible for transitioning the processor through 32-bit flat protected mode before reaching 64-bit long mode during the Driver Execution Environment (DXE) phase. Proprietary Independent BIOS Vendor (IBV) code bases like AMI Aptio or InsydeH2O commonly manage this progression.

ARM platforms leverage Arm's architectural Exception Levels (EL0 through EL3):

• EL3 (Secure Monitor): The SoC resets directly into EL3. In modern implementations, this layer runs Trusted Firmware-A (TF-A), executing low-level platform security and memory controller initialization entirely outside the UEFI environment.
• EL2 / EL1 (Non-secure Hypervisor / OS Kernel): UEFI generally does not run at the highest privilege on ARM. Instead, TF-A initializes the hardware, secures cryptographic keys, and drops execution down to EL2 (or EL1 if virtualization is disabled) to launch the UEFI payload, which is frequently built upon open-source EDK II or an embedded bootloader implementing UEFI interfaces (such as U-Boot).

System Memory and Peripheral Mapping

The x86-64 platform architecture relies heavily on standardized, fixed address spaces and well-defined legacy input/output (I/O) ports. Peripherals are mapped and discovered through standard root complexes, and standard baseboards share common routing patterns for interrupt routing (APIC).

ARM SoCs possess no standardized peripheral memory map. Memory-mapped I/O (MMIO) addresses, clock generators, pin control systems, and Generic Interrupt Controllers (GIC) vary drastically from vendor to vendor (e.g., Qualcomm vs. NXP vs. Ampere). Consequently, the UEFI initialization drivers for ARM platforms must be tightly coupled with the specific silicon design or strictly abide by the Arm Base System Architecture (BSA) standard to achieve unified boot capability.

Power Management and Runtime Services

On x86-64, UEFI collaborates closely with ACPI runtime services and System Management Mode (SMM)—an execution mode invisible to the operating system—to handle platform-specific hardware faults, power routing, and thermal throttling.

ARM platforms largely bypass runtime UEFI mechanisms for power management. Instead, ARM systems delegate power tasks (such as CPU core sleep states and resets) to the Power State Coordination Interface (PSCI). The operating system issues standard Secure Monitor Calls (SMC) directly to firmware residing in EL3 (TF-A), allowing the system to sleep, wake, or manage frequencies without relying on active UEFI runtime services.