IN Brief:
- HFI extends U-Boot with a BIOS-style power-on, configuration, and boot-selection environment.
- Version 1.0 is being developed around the SiFive HiFive Unmatched platform and PCIe graphics hardware.
- A shared firmware layer could reduce board-specific fragmentation across RISC-V development systems.
The Harmonic Firmware Initiative is developing an open BIOS-style environment intended to provide more consistent hardware initialisation, configuration, and boot control across RISC-V systems.
HFI is being implemented as an extension to U-Boot rather than as a replacement for the established bootloader. It obtains machine information through U-Boot subsystems and presents hardware status, setup options, and boot controls through its own graphical environment.
Planned version-one functions include power-on self-test information, memory reporting, USB and NVMe enumeration, system configuration, boot-device selection, access to a console, and firmware flashing. Configuration and boot data can be stored on MMC or NVMe media.
Initial development uses the SiFive HiFive Unmatched board with an NVIDIA GK208 PCIe graphics card. A VideoBIOS interface is intended to abstract graphics initialisation so that support can later be extended to different display hardware and additional RISC-V platforms.
The project follows the U-Boot licence and is open to contributions from board vendors and developers. Wider adoption will depend on validated platform support rather than the graphical interface alone, since each board has its own memory, clock, storage, interrupt, peripheral, and recovery requirements.
Current RISC-V systems vary considerably in firmware behaviour, device-tree handling, boot media, console access, and operating-system installation. Experienced developers can navigate those differences, although repeated platform-specific work increases the effort required to maintain several board designs.
A BIOS-style setup environment provides a familiar route to inspect detected hardware, change selected configuration parameters, choose a boot target, and diagnose the machine before the operating system loads. It does not make the underlying platform identical to an x86 PC, but it can present a more predictable operational layer above diverse hardware.
Firmware sits between the processor platform and the operating system, initialising enough of the machine to hand over control reliably. Incomplete or inconsistent early initialisation can affect memory, PCIe, storage, graphics, networking, and security before an operating-system driver has an opportunity to intervene.
Platform maturity extends below the operating system
The open RISC-V instruction set allows vendors to combine different processor extensions, memory arrangements, peripherals, and security architectures. That freedom supports hardware differentiation, although it also increases the volume of platform software required around the processor core.
A common user interface will be useful only where the underlying firmware services behave consistently. Hardware enumeration, configuration storage, error reporting, recovery, and handover to the next boot stage need stable interfaces if one operating-system image is to function across several boards without extensive customisation.
Security becomes central once the environment can alter boot order, flash firmware, or start from external media. Signature verification, authenticated updates, measured boot, rollback protection, and controlled access to configuration are required if the system progresses from development hardware into deployed equipment.
Recovery mechanisms must be designed with equal care. A failed firmware update should not leave the board permanently unusable, while a recovery path that bypasses normal verification can create a persistent route around the security architecture.
Long-term maintenance will require reproducible builds, version control, regression testing, vulnerability response, and clear ownership for platform-specific code. Similar disciplines are appearing elsewhere in embedded development through software bills of materials, compliance checks, reproducible operating-system builds, and maintained industrial Linux platforms.
HFI operates earlier in the boot chain, but the provenance of its source, toolchain, configuration, and binary output will be no less important. A fault introduced during initialisation can remain outside the visibility of operating-system monitoring while affecting every subsequent software layer.
Vendor participation will determine the available hardware coverage because each board needs validated drivers, storage support, graphics behaviour, and recovery procedures. A shared framework can reduce duplication, but the final enablement work remains tied to the physical platform.
The HiFive Unmatched implementation provides a practical starting point through its PCIe expansion, conventional storage, and established place in RISC-V development. Porting the environment to additional boards will test whether the interfaces are sufficiently portable to support a broader ecosystem.
RISC-V already has mature compilers, operating systems, and a growing range of processors and development boards. Increasingly, the remaining friction lies in the less visible platform infrastructure that joins those elements together and maintains them through updates, failures, and hardware revisions.
HFI addresses that layer by creating a consistent route from power-on to operating-system handover. A dependable implementation could reduce repeated board-specific work, although production use will require the same security, traceability, and lifecycle discipline expected from any other privileged firmware.
