How RISC-V Platforms Use UEFI for Standard Booting

RISC-V platforms are rapidly adopting the Unified Extensible Firmware Interface (UEFI) to establish an interoperable, vendor-neutral boot sequence across diverse hardware ecosystems. Historically, early RISC-V devices depended heavily on proprietary initialization routines and tightly coupled device configurations. By adopting UEFI specifications, RISC-V aligns with established enterprise and PC architectures, enabling a single, unmodified operating system distribution to detect hardware, load bootloaders, and initialize the system cleanly.

The Role of Privilege Levels in RISC-V UEFI

The RISC-V architecture defines distinct privilege modes to isolate hardware control and execution environments. UEFI fits directly into this hierarchy by cooperating with the underlying Supervisor Binary Interface (SBI):

  • Machine Mode (M-Mode): The most privileged execution tier, typically running low-level initialization firmware such as OpenSBI. M-Mode firmware directly interfaces with the silicon, sets up basic memory controllers, and exposes standardized SBI calls.
  • Supervisor Mode (S-Mode): The execution tier where the UEFI implementation operates. S-Mode lacks direct access to low-level hardware registers governed by M-mode, relying instead on SBI calls to manage timers, inter-processor interrupts (IPIs), and core power states. Operating system kernels also execute in S-Mode.
  • User Mode (U-Mode): The unprivileged layer reserved for user-space applications.

Because the UEFI environment runs within S-mode, it interacts with platform resources predictably, relying on standard SBI calls rather than direct, platform-specific hardware manipulations.

Firmware Implementations: EDK II and U-Boot

RISC-V hardware vendors achieve UEFI compliance primarily through two open-source firmware platforms:

  1. Tianocore EDK II: The standard reference implementation for enterprise-grade UEFI. On RISC-V, EDK II executes in S-Mode to provide standard UEFI Boot Services and Runtime Services. It mimics traditional enterprise environments, making it ideal for RISC-V servers and high-performance workstations.
  2. U-Boot (with UEFI Payloads): Widely utilized in embedded and development boards, U-Boot includes a built-in UEFI subsystem. U-Boot can initialize platform devices, instantiate UEFI interfaces, and expose the standard UEFI API directly to downstream bootloaders.

Passing Platform Hardware Descriptions

Operating systems require an accurate map of system resources, including memory layouts, peripherals, and interrupt lines. In a UEFI-driven RISC-V platform, this information is supplied through standard UEFI Configuration Tables:

  • Flattened Device Tree (FDT): While common in embedded systems, the FDT is passed via a standard UEFI configuration table identifier rather than being hardcoded at a specific memory offset. This allows UEFI to dynamically adjust device trees based on runtime discoveries before handing off control to the kernel.
  • Advanced Configuration and Power Interface (ACPI): For enterprise and server-grade RISC-V environments, ACPI tables replace device trees. UEFI exposes these tables to the OS via standard root system description pointers, matching the workflow used in modern x86 and AArch64 servers.

The Unified Boot Sequence

The standardized boot sequence progresses through well-defined stages:

  1. Reset and M-Mode Execution: The CPU starts executing from ROM, transitioning to a secondary stage bootloader or OpenSBI in M-Mode. Basic hardware features and memory are initialized.
  2. UEFI Initialization (S-Mode): OpenSBI drops execution to S-Mode, launching the UEFI firmware (EDK II or U-Boot). UEFI sets up memory allocation services, protocol drivers, and configuration tables.
  3. Boot Manager Execution: UEFI scans non-volatile storage, network interfaces, or removable media for standard EFI System Partitions (ESP) to locate valid boot applications (such as EFI/BOOT/BOOTRISCV64.EFI).
  4. Bootloader Handoff: The UEFI Boot Manager launches intermediate loaders like GRUB or systemd-boot. The bootloader uses UEFI Boot Services to load the OS kernel and initial RAM disk (initramfs) into memory.
  5. ExitBootServices Call: The OS kernel calls ExitBootServices(). UEFI terminates its temporary memory allocation and boot services, hands over final control of the processor cores, and leaves only UEFI Runtime Services accessible for platform management tasks like setting non-volatile variables.

Standardization Through BRS and EBBR

To avoid vendor-specific deviations, the RISC-V ecosystem defines strict profiles:

  • Embedded Base Boot Requirements (EBBR): Tailored for single-board computers and embedded devices, EBBR mandates a subset of UEFI features combined with Device Tree handoffs, allowing low-cost platforms to boot generic distributions.
  • Boot and Runtime Services (BRS): Developed by the RISC-V International community, BRS codifies full enterprise-class boot standards. BRS requires conformant UEFI implementations, ACPI support, and standard SBI versions, ensuring enterprise distributions like Fedora, Debian, or openSUSE operate seamlessly out of the box.