UEFI Boot Power Management Across CPU Architectures

The Unified Extensible Firmware Interface (UEFI) manages CPU power states during the boot process to ensure system stability, control thermals, and prepare power interfaces for the operating system. While the boot environment initially operates with basic, static power configurations to avoid instability, it progressively initializes platform-specific power registers, brings up secondary cores, and builds standardized interfaces like ACPI or Device Tree. The underlying mechanics of how UEFI manipulates power levels during this sequence vary fundamentally between x86, ARM, and RISC-V architectures.

UEFI Boot Phases and Power Management

During system boot, UEFI transitions through several distinct execution phases, each with specific power constraints:

  1. Security (SEC) Phase: The system starts from a cold reset. The primary CPU core operates in a conservative, safe operational state using default voltages and base clock frequencies. Low-power idle states (C-states) and dynamic frequency scaling (P-states) are disabled to prevent timing and voltage instabilities before hardware calibration.
  2. Pre-EFI Initialization (PEI) Phase: Basic platform hardware, including the memory controller and power management ICs (PMICs), is initialized. The Primary Processor (Bootstrap Processor or BSP) establishes stable rail voltages and baseline CPU operating frequencies. Secondary cores (Application Processors or APs) remain in a reset or quiescent low-power halt state.
  3. Driver Execution Environment (DXE) Phase: Architectural power management drivers are dispatched. The firmware detects processor topology, programs thermal and power management registers, enables basic power-saving governors, and wakes secondary cores to test initialization before placing them back into low-power states.
  4. Boot Device Selection (BDS) and OS Handoff: UEFI constructs the runtime tables—primarily ACPI or Device Tree—that describe the hardware's power capabilities. When the OS loader executes ExitBootServices(), UEFI relinquishes direct power management to the Operating System-directed Power Management (OSPM) subsystem.

Implementation Across Architectures

While the high-level phases are standard across UEFI implementations (such as EDK II), the low-level execution differs depending on the processor architecture and its privilege model.

x86 and x86-64 Architectures

In x86 implementations (Intel and AMD), UEFI directly interacts with the hardware through Model-Specific Registers (MSRs) and memory-mapped I/O (MMIO):

  • Initial States: The BSP boots using standard default clock multipliers. Microcode updates applied during the SEC/PEI phase often patch voltage/frequency curves.
  • Core Management: The BSP communicates with APs using Inter-Processor Interrupts (INIT-SIPI-SIPI sequences). Cores not actively executing boot tasks are halted using low-power halt loops or architectural states like MWAIT.
  • Hardware-Controlled Performance (HWP): On modern x86 chips, UEFI can enable autonomous frequency control (such as Intel Speed Shift), allowing the CPU to manage its own voltage and frequency transitions during later boot phases.
  • Handoff Mechanism: UEFI builds ACPI tables containing static power resource descriptions, such as _PSS (Performance Supported States), _CPC (Continuous Performance Control), and _CST (C-States). Control transitions entirely to ACPI/OSPM at boot completion.

ARM64 (AArch64) Architecture

ARM systems decouple firmware power execution using a layered privilege hierarchy governed by the Power State Coordination Interface (PSCI):

  • Privilege Separation: UEFI typically executes at Exception Level 2 (EL2, hypervisor) or Exception Level 1 (EL1, OS/bootloader). UEFI does not directly write to low-level CPU power registers.
  • Firmware Coordination: Power operations are delegated to a secure runtime layer running at Exception Level 3 (EL3), such as ARM Trusted Firmware (TF-A).
  • Power Calls: When UEFI needs to wake secondary cores, adjust core power levels, or prepare for sleep, it issues Secure Monitor Calls (SMC) or Hypervisor Calls (HVC) implementing standard PSCI functions (e.g., CPU_ON, CPU_SUSPEND).
  • Handoff Mechanism: UEFI passes power topology to the OS via either ACPI tables (using the standard ARM PSCI definitions) or flattened Device Trees (psci nodes), allowing the OS kernel to call the same PSCI services established during firmware initialization.

RISC-V Architecture

RISC-V systems handle power via the Supervisor Binary Interface (SBI) and its Hart State Management (HSM) extension:

  • Privilege Model: UEFI runs in Supervisor mode (S-mode). Direct control of hardware execution states (called "harts") belongs to Machine mode (M-mode), typically managed by runtime firmware such as OpenSBI.
  • Hart State Management: The UEFI implementation uses SBI calls (via the ecall instruction) to query, start, stop, or suspend secondary harts during the PEI and DXE phases.
  • Dynamic Power States: Advanced frequency scaling and voltage regulation are performed either by SBI platform drivers or platform-specific PMIC interfaces registered prior to UEFI payload execution.
  • Handoff Mechanism: UEFI translates the initialized platform topology into standard Device Tree entries or ACPI RISC-V extensions, enabling the OS kernel to coordinate power states using SBI HSM calls post-boot.