I have been experimenting with RISC-V emulators, QEMU and mini-rv32ima mainly, and have come across OpenSBI. The project defines itself as:
The RISC-V Supervisor Binary Interface (SBI) is the recommended interface between:...
- A hypervisor running in HS-mode and a bootloader or a general-purpose OS executing in VS-mode.
The goal of the OpenSBI project is to provide an open-source reference implementation of the RISC-V SBI specifications for platform-specific firmwares
Digging a little deeper, you see that OpenSBI is deployed as a bianry that runs before the bootloader. From this guide:
QEMU -- passes dtb --> OpenSBI -- passes dtb -->
U-Boot -- parses dtb > finds disk > partitions > filesystem > kernel file
At a high level, what features is OpenSBI providing in this deployment?
Specifically Linux already can read a device tree file and an emulator can emulate a peripheral device at that memory address (mini-rv32ima.c
shows this very cleanly by emulating a UART 8250/16550). The Linux device driver essentially defines the binary interface and the emulator implements it. Does OpenSBI enhance this interface, or allow for greater performance or flexibility in the future? Does it do something else?
From the RISC-V Supervisory Binary Interface Specification:
The SBI allows supervisor-mode (S-mode or VS-mode) software to be portable across all RISC-V implementations by defining an abstraction for platform (or hypervisor) specific functionality.
OpenSBI, being an implementation of the SBI specification, provides an abstraction for various common platform elements - especially those important for the boot-up process - such as UARTs, Timers etc.
Taking your example, it wouldn't matter which type of UART was present on the platform. OpenSBI abstracts all types of UARTs behind a common console API.
Operating system kernels use that API to implement an SBI UART driver that works on any SBI compliant platform. The same SBI UART driver would work even if the type of the UART (the manufacturer/model/design) was different. This helps immensely with aspects such as platform bring-up diagnostics.
Of course, this is not universally applicable and is typically used for the very bare minimum and important set of peripherals needed for boot up.
Note that the DeviceTree is still needed to help identify (and if needed, locate) the SBI compliant device.