OpenSBI: Building the RISC-V Firmware Interface Layer
RISC-V Open Source Supervisor Binary Interface
At a glance
- What is it?
- OpenSBI provides an open-source implementation of the RISC-V Supervisor Binary Interface for platform firmware and M-mode integrators. Its reusable `libsbi.a` library separates common SBI behavior from board-specific hardware operations, while HSM support affects which OpenSBI version a multi-hart system needs.
- Who is it for?
- Platform vendors and firmware authors should adopt OpenSBI when they need an SBI implementation and can supply board-specific hardware operations. Developers of older S-mode software should verify HSM support or use OpenSBI v0.6, while users seeking a complete platform image should first inspect the supported platform examples and their board configuration requirements.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 25 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
OpenSBI's role between RISC-V firmware and S-mode software
OpenSBI addresses a specific interface boundary in RISC-V systems. It sits between platform-specific firmware running in M-mode and software that executes in S-mode or HS-mode, including bootloaders, hypervisors, and general-purpose operating systems. It can also sit between a hypervisor running in HS-mode and software running in VS-mode. The project is aimed at firmware authors, RISC-V platform vendors, system-on-chip vendors, and developers who need their firmware to conform to the Supervisor Binary Interface specification.
The distinction between the SBI specification and OpenSBI matters. The specification is maintained independently by the RISC-V Foundation. OpenSBI is one open-source reference implementation of that specification. It is not a general-purpose operating system, a Linux distribution, or a replacement for every piece of boot firmware. Its central reusable component is the platform-independent static library `libsbi.a`, which implements the SBI interface and exposes an integration interface for operations supplied by platform firmware.
That division gives vendors a way to keep the common SBI layer while supplying hardware-dependent functions for console access, inter-processor interrupt control, and other platform operations. The repository also contains platform-specific support examples. Their corresponding `libplatsbi.a` libraries connect `libsbi.a` to hardware manipulation code, and runtime firmware examples can be used where a complete platform implementation is available.
How OpenSBI separates common SBI logic from platform code
The repository layout reflects a two-layer design. The `lib/` and `include/` areas contain the platform-independent implementation and public interfaces, while `platform/` contains platform-specific support code and examples. `firmware/` contains firmware components built on top of those platform layers. The top-level `Makefile` selects source, build, installation, and platform directories, and its Kconfig-based build supports configuration for the target platform.
For a platform integration, the common library handles SBI call processing according to the specification. The platform library supplies the functions that cannot be implemented without knowledge of the machine, including console and interrupt-related operations. This architecture avoids requiring a single universal hardware abstraction for every SoC. It also makes `libsbi.a` usable by a bootloader or firmware implementation outside the bundled runtime examples, provided that integration supplies the expected platform operations.
The supported-platform examples are useful as integration references, not as proof that arbitrary boards are supported. Based on the repository layout, a port needs a platform directory, a build configuration, and code that maps the generic SBI operations to the board's devices. The README does not document a generic discovery process for automatically detecting an unknown RISC-V board, so adoption requires checking whether the target hardware is already represented or can be ported.
Building `libsbi.a` with a native or cross toolchain
OpenSBI can be compiled natively or cross-compiled from a host with a different base architecture. The README requires a PIE-capable toolchain because the generated firmware images must run at an appropriate arbitrary address. It specifically rejects bare-metal GNU toolchains such as `riscv64-unknown-elf-gcc`, while allowing LLVM/Clang with suitable target configuration. Host packages include `device-tree-compiler` and `python3`.
The README documents `make` as the basic build command. It says the compiled binaries and resulting `libsbi.a` static library are placed in the `build/lib` directory:
makeAn alternate build root is selected with `O`:
make O=<build_directory>The project documentation does not give a complete first-boot command for a particular board, so it would be inaccurate to present an undocumented platform image name or boot target.
Installing the platform-independent OpenSBI library
To install the headers and library for use by another project, run the install target:
make installThe Makefile defaults the installation root to `usr`, so the exact destination should be checked in the generated build output on the host.
This step produces files for integration; it does not by itself establish that a board-specific runtime image is ready to boot. A downstream firmware project must still provide the platform operations required by `libsbi.a`, compile against the installed headers, and arrange for the resulting firmware to be placed where the platform boot flow expects it. The README does not document rollback, signing, update delivery, or recovery behavior for an already deployed OpenSBI image.
HSM support changes multi-hart boot requirements
OpenSBI documents a significant compatibility boundary around Hart State Management. The README says that current OpenSBI supports SBI specification v0.2 and has supported the HSM extension since OpenSBI v0.7. HSM allows S-mode software to boot harts in a defined order instead of relying on the legacy method of booting harts randomly.
The project states that HSM is implemented in a non-backward-compatible manner to reduce maintenance burden and avoid confusion. Software that uses OpenSBI versions with HSM support cannot boot more than one hart if it does not support the HSM extension. This changes which operating systems or boot software can expect OpenSBI to start the complete hart set.
The README identifies Linux kernel support for SBI v0.2 and HSM starting with `v5.7-rc1`. For a Linux kernel older than `v5.7-rc1`, or other S-mode software without HSM support, the documented choice is OpenSBI v0.6 when all harts must boot. For a uniprocessor system, the README says the distinction does not matter. The project also clarifies that an S-mode bootloader such as U-Boot does not need HSM because it does not boot every hart. The operating system is expected to bring up the remaining non-booting harts through HSM.
This creates two different adoption paths. Up-to-date S-mode software can use current OpenSBI, while older multi-hart systems need a version choice based on the software interface they actually implement.
OpenSBI's build boundary and likely integration failure points
The clearest failure point is a mismatch between the host toolchain and the required firmware format. A toolchain without PIE support cannot produce firmware images that meet the stated arbitrary-address requirement, and a bare-metal GNU toolchain is explicitly not accepted. The host also needs the device-tree compiler and Python 3. Missing or unsuitable packages can therefore stop the build before platform logic matters.
A second boundary appears during hardware integration. `libsbi.a` is platform-independent, but it depends on a platform integration interface. Console access and inter-processor interrupt control are examples of operations that must be connected to the target system. A port can compile as a library while still failing at runtime if those functions are wired to the wrong device, interrupt route, or platform state.
A third limitation is version compatibility. Choosing the newest OpenSBI build does not guarantee compatibility with older S-mode boot software. Multi-hart systems without HSM support are the clearest case, and the README directs those users toward v0.6. Another practical limitation is documentation scope: the project does not specify a general recovery process, firmware update format, or deployment orchestration mechanism. OpenSBI is therefore closer to a reusable firmware component than to a complete device lifecycle tool.
Compared with writing firmware calls and hardware hooks independently, OpenSBI centralizes the common SBI behavior. Compared with a complete vendor boot stack, it leaves board-specific work to the integrator.
License, releases, and upgrade considerations for OpenSBI
The README identifies OpenSBI's principal code as BSD-2-Clause, with copyright notices for Western Digital Corporation or its affiliates and RISC-V International. It places the license text in `COPYING.BSD` and uses the SPDX identifier `BSD-2-Clause` in source files. It also identifies reused third-party code, including `libfdt`, which is disjunctively dual licensed under `GPL-2.0+ OR BSD-2-Clause`; contributions to that code must use both licenses according to the README. `ThirdPartyNotices.md` is the repository's place for further third-party information.
The repository metadata labels the license as a custom license that GitHub cannot classify, but the README gives concrete licensing terms and names the relevant license files. A downstream integrator should inspect those files rather than relying on the repository category alone. This is especially relevant when redistributing firmware or combining OpenSBI with code that has different license obligations.
The release history includes OpenSBI v1.9 dated 2026-07-01, v1.8.1 dated 2026-01-08, and v1.8 dated 2025-12-29. The last push was on 2026-09-28. Those facts indicate recent repository activity, but they do not establish compatibility for every platform or kernel. An upgrade should be checked against the HSM requirements, supported platform configuration, toolchain choice, and the exact SBI expectations of the S-mode software.
Editorial conclusion
Platform vendors and firmware authors should adopt OpenSBI when they need an SBI implementation and can supply board-specific hardware operations. Developers of older S-mode software should verify HSM support or use OpenSBI v0.6, while users seeking a complete platform image should first inspect the supported platform examples and their board configuration requirements.
Frequently asked questions
What is OpenSBI used for in a RISC-V system?
OpenSBI is an open-source implementation of the RISC-V Supervisor Binary Interface for platform firmware running in M-mode and bootloaders, hypervisors, or operating systems running in S-mode or HS-mode. It is intended for firmware authors, platform vendors, and SoC integrators.
How do I build OpenSBI for RISC-V?
The README documents `make` for a native build and says to set `CROSS_COMPILE` to the compiler executable prefix for a cross build. The build places compiled binaries and `libsbi.a` under `build/lib` by default, subject to the toolchain and host package requirements described by the project.
Can older Linux kernels boot all harts with current OpenSBI?
The README says Linux kernels older than `v5.7-rc1`, and other S-mode software without HSM support, should use OpenSBI v0.6 to boot all harts. Current OpenSBI versions support HSM, which changes hart startup to an ordered process and is not backward compatible with software that lacks HSM support.
Does OpenSBI include support for every RISC-V board?
The project provides platform-specific support examples and runtime firmware examples for supported platforms. The README does not claim automatic support for every board, so a new platform requires checking the repository for a matching platform implementation or supplying the platform-specific integration functions.
What license applies to OpenSBI?
The README states that OpenSBI is distributed under the BSD 2-Clause license, identified as `BSD-2-Clause`, and points to `COPYING.BSD`. It also documents separately licensed reused code, including `libfdt`, whose contributions have additional terms described in the README.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/riscv-software-src-opensbi)Was this useful?