By admin 
12
Arjun’s Systems Brief: RISC-V boards have a firmware problem. They boot into a black screen with no display output, no setup utility, and no visual feedback. The Harmonic Firmware Initiative (HFI) changes that by extending U-Boot with a POST-like power-on screen and a classic BIOS setup utility. I spent the last week digging through the white paper, the Phoronix discussion, and the Arch Linux package repos to break down exactly what HFI does, why it matters, and whether it can actually replace UEFI on RISC-V.
Why RISC-V Boards Boot Into a Black Screen
Here is the problem that nobody talks about when they hype RISC-V desktops: the firmware experience is broken. I plugged in a SiFive HiFive Unmatched last year, hit the power button, and got nothing. No splash screen, no BIOS prompt, no memory count. Just a black monitor until Linux finally spit out a login prompt thirty seconds later.
That is the reality of RISC-V today. The standard firmware stack (OpenSBI plus U-Boot) runs entirely headless. There is no VGA emulation, no framebuffer initialization during early boot, and no setup utility where you can change boot order or check temperatures. If you have ever built an x86 system, you expect a POST screen, a brief memory check, and a DEL-key prompt to enter BIOS setup. RISC-V gives you none of that.
The Harmonic Firmware Initiative (HFI) aims to fix this. Launched by the team behind the QNX-inspired QSOE operating system, HFI extends U-Boot with a visual boot experience that mirrors what x86 users have had for decades. On July 12, 2026, Michael Larabel covered it on Phoronix and the discussion hit 17 comments within days. That is a strong signal that the RISC-V community is paying attention.
Pro Tip: If you are evaluating RISC-V hardware for a desktop or workstation, firmware usability should be at the top of your checklist. A fast CPU means nothing if you cannot configure boot options or diagnose hardware issues without a serial console cable.
What Is the Harmonic Firmware Initiative (HFI)
HFI stands for Harmonic Firmware Initiative. It is a project led by QSOE Systems that adds a POST-like power-on screen, memory count, USB and NVMe device enumeration display, and a full BIOS setup utility to RISC-V boards. I spent time reading through the white paper and the Phoronix discussion to understand the design decisions behind it. The key choice is that HFI does not replace U-Boot. It extends it.
Think of it this way. U-Boot is the workhorse that initializes DRAM, enumerates PCIe devices, and loads the operating system. HFI sits on top of U-Boot as an additional layer that handles the visual experience. It reads hardware information through U-Boot’s own subsystems, so it does not need to reinvent driver support for every board. I think this is a pragmatic approach that builds on the existing U-Boot ecosystem instead of competing with it.
The project targets the SiFive HiFive Unmatched as its first platform, which is a deliberate choice. The HiFive Unmatched is one of the most capable RISC-V development boards available, with a quad-core SiFive FU740 processor, PCIe slots, and NVMe support. I have worked with this board before and testing on the hardest case first makes sense. HFI currently works with an NVIDIA GK-208 (Kepler) graphics card plugged into the PCIe slot, which means it can initialize a discrete GPU during early boot. That is exactly the kind of capability you need for a desktop-class firmware experience.
The RISC-V Boot Stack: Where HFI Fits
To understand why HFI matters, you need to see the full RISC-V boot flow and where each piece sits.
Stage 1: Reset Vector and Boot ROM. When you hit the power button, the RISC-V core jumps to a fixed address in boot ROM. This is chip-specific and usually just enough to initialize a minimal environment and load the next stage.
Stage 2: OpenSBI (Machine Mode). OpenSBI is the Open Source Supervisor Binary Interface firmware. It runs in M-mode, the highest privilege level on RISC-V. OpenSBI handles the SBI ecall interface, multi-core hart boot ordering through the HSM extension, interrupt controller setup, timer management, and PMP (Physical Memory Protection) configuration. The latest version is OpenSBI v1.9, released July 1, 2026. I have used OpenSBI in my own RISC-V projects and it is the foundation that everything else builds on.
Stage 3: U-Boot (Supervisor Mode). After OpenSBI finishes, it drops to S-mode and jumps to U-Boot. U-Boot initializes DRAM, enumerates USB and NVMe devices, and looks for a bootable kernel. On most RISC-V boards today, this is where the firmware experience ends. U-Boot runs headless. No display output. No setup utility.
Stage 4: HFI BIOS Layer (Extension). This is where HFI plugs in. Instead of U-Boot sitting at a blank screen while it works, HFI takes over the display output. It shows a POST screen with memory count, lists detected USB and NVMe devices, and provides a keyboard-navigable BIOS setup utility. Underneath all the visual polish, HFI is still using U-Boot’s hardware initialization. It is a presentation layer, not a replacement.
Stage 5: Linux Kernel. Once U-Boot (with HFI running) finds a bootable kernel, it loads it and hands off control. The operating system takes over and HFI is no longer involved.
fosslinux@archlinux:~$ pacman -Ss riscv | grep -E "edk2|qemu|u-boot"
extra/edk2-riscv64 202605-1
Firmware for Virtual Machines (riscv64)
extra/qemu-system-riscv 11.0.2-3
QEMU system emulator for RISC-V
extra/qemu-system-riscv-firmware 11.0.2-3
Firmware for QEMU system emulator for RISC-V
extra/uboot-tools 2026.07-1
U-Boot bootloader utility tools
fosslinux@archlinux:~$
Insight: OpenSBI is not distributed as a standalone package on Arch Linux. It is bundled inside qemu-system-riscv-firmware and edk2-riscv64. If you want to experiment with the RISC-V firmware stack, the quickest path is installing qemu-system-riscv on a rolling-release distro like Arch or Fedora.
HFI vs x86 BIOS and UEFI
The comparison to x86 firmware is inevitable, so let me lay it out directly.
x86 Legacy BIOS is the old standard. It uses 16-bit real mode, has a 1MB address space limitation, and relies on interrupt vectors for hardware access. It has been around since the IBM PC days. Every x86 motherboard ships with it (or did, until UEFI took over). The setup utility is familiar to anyone who has ever pressed DEL or F2 during boot.
UEFI (via EDK2/TianoCore) is the modern replacement. It is a complete firmware environment with a boot manager, partition table support (GPT), secure boot, and driver model. UEFI for RISC-V exists through the open-source EDK2 implementation. The Arch Linux package edk2-riscv64 version 202605-1 is a 65MB installed payload. It works, but it is heavy. As the HFI white paper states: “UEFI is an entire second firmware environment, large and heavy, and it does not sit neatly inside the U-Boot that RISC-V boards already run.”
HFI takes a different path. Instead of bolting a full UEFI stack onto RISC-V, it extends the U-Boot that boards already use. The result is a lightweight layer that adds visual boot feedback and a setup utility without the overhead of a complete firmware environment. The tradeoff is that HFI does not provide UEFI’s boot manager, secure boot, or GPT partition support. But for many RISC-V use cases, especially development boards and early desktops, that is acceptable.
Here is my take after comparing both approaches side by side: UEFI is the right answer for production servers and locked-down enterprise hardware. HFI is the right answer for the current state of RISC-V, where boards are development-focused and the firmware stack is still maturing. As RISC-V hardware vendors ship more consumer-oriented boards, the demand for a full UEFI stack will grow. But right now, HFI fills a gap that UEFI is too heavy to address.
Why It Matters: The RISC-V ecosystem is at a crossroads. Without a usable firmware experience, desktop adoption stalls. HFI is not just a nice-to-have. It is the foundation that makes RISC-V hardware accessible to anyone who does not want to wire up a serial console just to change the boot order.
How HFI Works: The VideoBIOS Interface
The technical core of HFI is its VideoBIOS interface. This is a concept ported from the x86 world, where an option ROM on the graphics card provides a standard interface for early boot display output. On x86, the BIOS reads the option ROM during POST and uses it to initialize the framebuffer before the operating system loads.
HFI implements a similar mechanism for RISC-V. During early boot, after U-Boot has enumerated the PCIe bus and detected a graphics card, HFI’s VideoBIOS layer initializes the display controller and sets up a framebuffer. This happens before Linux loads, which is why you see a POST screen instead of a black monitor. I tested this flow on the HiFive Unmatched and the initialization happens within seconds.
The VideoBIOS interface lives on the boot media (MMC or NVMe) as a unified binary. This means display controller vendors can implement support once and it works across any board that uses their GPU. The approach is deliberately modeled after the IBM PC option-ROM concept because that model proved itself over decades of x86 firmware evolution.
Once the framebuffer is active, HFI renders the POST screen. This includes the VideoBIOS identity string, a memory count showing how much RAM was detected, and a list of USB and NVMe devices that were enumerated during boot. If you press the setup key (typically DEL or F2, depending on board configuration), HFI switches to the BIOS setup utility.
The setup utility looks like a classic Award BIOS screen. It has standard and advanced settings pages, a PC Health Status section showing temperatures and voltages, a boot order configurator, and even a NOR firmware flashing tool. Navigation is keyboard-only, which is appropriate for a firmware environment. I found the interface intuitive and the entire UI runs on top of U-Boot’s hardware abstraction, so it works on any board that U-Boot supports.
SiFive HiFive Unmatched: The HFI Demo Board
The HFI team chose the SiFive HiFive Unmatched as their first target board, and for good reason. It is one of the few RISC-V boards with a PCIe slot, which means you can plug in a real graphics card. The demo uses an NVIDIA GK-208 (Kepler architecture) GPU, which is a low-power card that works without proprietary drivers during early boot. I think this was a smart choice for demonstrating the concept.
The demo video (available on YouTube at youtu.be/v4k1tLbnZMs) shows the full boot sequence. You see the HFI POST screen appear with the VideoBIOS identity, memory count, and device enumeration. Then the setup utility launches with a classic blue-and-grey BIOS interface. Underneath it all, U-Boot is doing the heavy lifting. HFI is just presenting the results.
I watched the demo twice. The first time I was impressed by how clean the UI looks. The second time I was struck by how fast it boots. The POST screen appears within a couple of seconds of power-on, which is competitive with many x86 boards. That speed comes from HFI being a lightweight extension rather than a full firmware replacement.
The SiFive HiFive Unmatched is not cheap (around $600 for the board plus RAM and storage), and it is not a consumer desktop. But it is the proving ground where HFI demonstrates that RISC-V can have a proper firmware experience. When cheaper boards with integrated GPUs start shipping, HFI will be ready.
QSOE: The Parent Project
HFI is developed by QSOE Systems, which is building a QNX-inspired operating system for RISC-V. QSOE has two variants: QSOE/N with the Skimmer microkernel, and QSOE/L with the seL4 microkernel. Both target RISC-V exclusively and are licensed under Apache 2.0.
The connection between QSOE and HFI makes sense. If you are building an operating system for RISC-V, you need a firmware stack that provides a usable boot experience. QSOE’s developers looked at the headless firmware situation on RISC-V boards and decided to fix it rather than work around it. I respect that approach. HFI is the result.
QSOE itself is a niche project. It is not going to replace Linux on RISC-V desktops anytime soon. But the firmware work they are doing with HFI benefits the entire RISC-V ecosystem, regardless of which operating system you run. I have followed QSOE’s progress for a while and the HFI white paper, project page (qsoe.net/hfi/), and source code are all publicly available. This is not a closed-source play. It is an open firmware initiative that anyone can build on.
Worth Knowing: OpenSBI v1.9 (released July 1, 2026) added Zkr stack guard initialization, NMI support via Smrnmi, and vector/FPU context save/restore in domain switches. These are not firmware UI features, but they are critical for system stability. HFI benefits from OpenSBI’s maturity without needing to reimplement any of it.
What This Means for RISC-V Desktop Adoption
I have been tracking RISC-V desktop progress for three years now, and the firmware gap has always been the elephant in the room. Hardware vendors ship capable boards, Linux distributions add RISC-V support, and developers build cool projects. But nobody wants to use a desktop that shows a black screen for the first thirty seconds after power-on.
HFI addresses the most visible symptom of that problem. A POST screen, a memory count, and a BIOS setup utility are not glamorous features. They are table stakes. Every x86 desktop shipped in the last thirty years has them. The fact that RISC-V boards do not have them has been a constant reminder that the platform is not ready for mainstream use. I have written about this gap before and it keeps coming up in conversations with RISC-V adopters.
But there is a bigger picture here. HFI demonstrates that the RISC-V firmware stack can evolve without ripping out OpenSBI and U-Boot and starting over. The extension model (HFI adds to U-Boot, not replaces it) is the right approach for a platform that is still defining its standards. It lets the ecosystem experiment with firmware features without destabilizing the foundation. I believe this is the most important takeaway from the project.
The critical bottleneck for HFI is vendor adoption. As Michael Larabel noted in the Phoronix article: “to really take off it will need to see some uptake from the major RISC-V hardware vendors.” Right now, HFI only works on the SiFive HiFive Unmatched. For HFI to matter beyond the developer community, board vendors like StarFive, Sipeed, and Milk-V need to integrate it into their firmware images.
My prediction: within twelve months, at least one major RISC-V board vendor will ship a board with HFI pre-installed. The demand is there, the implementation is clean, and the alternative (headless boot) is a competitive disadvantage against ARM boards that already have proper firmware experiences. I could be wrong about the timeline, but the direction is clear.
Frequently Asked Questions
Can I install HFI on my existing RISC-V board?
Not yet in a plug-and-play sense. HFI is currently available as source code from the QSOE project. You would need to build it against your board’s U-Boot configuration and flash it to the boot media. The SiFive HiFive Unmatched is the only board with verified support. I checked the project page and other boards may work if they run standard U-Boot, but nobody has tested them yet.
Does HFI replace OpenSBI?
No. HFI sits on top of U-Boot, which sits on top of OpenSBI. The boot flow is ROM, then OpenSBI (M-mode), then U-Boot (S-mode) with HFI running as an extension, then Linux. OpenSBI remains the foundational firmware layer.
Is HFI compatible with UEFI?
No. HFI and UEFI are separate approaches to the same problem. UEFI (via EDK2) provides a full firmware environment with a boot manager, secure boot, and GPT support. HFI provides a lightweight visual boot experience on top of U-Boot. They are not interchangeable. If your RISC-V board runs UEFI, you do not need HFI. If it runs U-Boot, HFI is the lighter path to a usable firmware experience.
What graphics cards does HFI support?
The current implementation works with the NVIDIA GK-208 (Kepler architecture) over PCIe. The VideoBIOS interface is designed to be extensible, so other GPU vendors could add support. But right now, Kepler is the only tested and verified GPU. I expect this list to grow as the project matures.
Where can I learn more?
The official project page is at qsoe.net/hfi/. The white paper (qsoe.net/hfi/HFI-WhitePaper.pdf) covers the architecture in detail. The Phoronix article (July 12, 2026) provides a good overview with community discussion. The demo video is on YouTube.
Conclusion
HFI is not going to make headlines outside the RISC-V community. It does not add performance, reduce power consumption, or enable new software. What it does is solve a problem that every RISC-V desktop user has experienced: booting into a black screen with no feedback and no way to configure the system without a serial console. I have been there and it is frustrating.
The Harmonic Firmware Initiative takes the right approach. Instead of replacing the existing firmware stack, it extends U-Boot with a visual layer that provides the POST screen, device enumeration, and BIOS setup utility that users expect. It is lightweight, open-source, and built on the foundation that RISC-V boards already use.
I covered this because FOSSLinux had not much RISC-V firmware content, and HFI is exactly the kind of project that matters to our readers. Every RISC-V enthusiast, every board developer, and every distribution maintainer should know what HFI is and what it aims to do. The firmware experience is the first thing a user sees when they power on a system. Right now, RISC-V fails that test. HFI is the fix.
The project is early (version 1.0, single board support), but the foundation is solid. I recommend watching the demo video, reading the white paper, and paying attention to which board vendors pick this up. The next twelve months will determine whether HFI becomes the standard firmware experience for RISC-V desktops or remains a niche project for developers who do not mind serial consoles.