RISC-V Boot Process: One Step at a Time
- Atish Kumar Patra [Open Source Summit EU 2019]

RISC-V aims to be a universal ISA, usable from very small to very large systems. Therefore, the boot process must also be standardised and universal.

Compared to Power and MIPS which now are also open ISAs, RISC-V also has an open community to define and extend the ISA. Power and MIPS opening their ISAs clearly shows there is a demand for this.

A typical boot flow has multiple stages.

  • ROM: on chip in the SoC
  • Loader: DDR initisalisation, loads Runtime and Bootloader
  • Runtime: SoC security setup and other “background” services that keep running while the OS is there. Cfr. ATF, BIOS, UEFI.
  • Bootloader: what you see in the boot prompt: U-Boot, grub, …
  • OS

RISC-V upstream boot flow is similar. ROM is ZSBL. FSBL loader is SoC-specific. Will be replaced by Coreboot and/or U-Boot SPL. Runtime is OpenSBI. It provides runtime services. U-Boot is a payload in OpenSBI.

First release of HiFive board had a legacy runtime, which can now be replaced by OpenSBI. OpenSBI v0.1 was released only a year later, in January 2019. U-Boot was the first bootloader supported in OpenSBI; grub and EDK2 have been added recently.

SBI stands for Supervisor Binary Interface. It’s a specification, OpenSBI is the reference implementation of that specification. It is the interface between the M-mode (the highest privilege mode) and S-mode (supervisor mode, i.e. OS). It provides common drivers for the OS which can be shared between difference platforms. It also gives a way to access resources that are not accessible to S-mode.

The SBI spec will evolve, so OpenSBI will evolve as well. This helps to give feedback to the spec. It is licensed under BSD-2c so vendors can easily extend it to add services in M-mode.

SBI library implements the SBI part only. Platform specific library has platform-specific drivers. Having it in the open helps others to develop their own platforms. It is provided as a library so it can be integrated into EDK2.

OpenSBI provides several reference firmwares.

  • FW_PAYLOAD forwards to a next boot stage, i.e. bootloader.
  • FW_JUMP jumps to a fixed address, someone else should have loaded the next loader there. This is used by QEMU.
  • FW_DYNAMIC loads the next stage based on information passed in by the previous stage. This allows U-Boot SPL to pass from which device it booted.

[Arnout lost track of the talk at this point. In summary, there’s a lot of ongoing and future work.]