What I'm working on right now

Since 2024 I've wanted one specific thing: a RISC-V board that feels like a real personal computer. Not a serial console scrolling kernel logs over a USB cable — an actual screen that lights up at power-on, a boot menu, an operating system coming up on it. Power button, video BIOS, mr-bml's menu, QSOE booting on the display. That's the picture I've carried around for two years, and with Claude Code I've finally started attacking it for real.

The board is my SiFive HiFive Unmatched (FU740). The display comes from an NVIDIA GK208, a "Kepler" (nv50) card, sitting in its PCIe slot. The catch is that the card's brain is an x86 Video BIOS: 16-bit real-mode code that expects an x86 host to POST it. The Unmatched is RISC-V. So the runner I'm building, gk208-vbios-runner, executes that x86 VBIOS inside an emulator on the RISC-V host — the SciTech/U-Boot bios_emulator engine — and bridges its register and memory accesses out to the real card. The goal is deliberately humble: classic VGA text mode 3, 80×25, exactly as a legacy PC would show it at POST.

I tried a version of this in 2024 and it drowned. The old runner produced something like 7 GB of flat instruction traces with no way to see structure in them; I never could tell where the VBIOS diverged from what a real machine would do. The clean-slate successor I started this weekend leads with introspection instead — per-class tracing, register watchpoints, a branch ring that collapses a 2000-instruction NOP-slide down to the single jump that caused it. This time I can actually watch what the card's firmware is doing.

And it's gone further than I expected. Last night the card put a live analog VGA signal out on RISC-V for the first time — green monitor LED, the head scanning, the monitor syncing to our signal — from a hand-rolled minimal Kepler EVO modeset, no nouveau and no x86 BIOS in the loop at all. This morning that became a standalone first light: one command takes the card from cold to a locked 720×400@70 analog signal, with our preinit waking the priv-ring, the x86 VBIOS POST training the DRAM, and the EVO modeset driving the output on DAC-1. The monitor's own OSD confirms the mode.

What I'm doing right now is documenting the VBIOS itself, byte for byte. There's a new reconstr/ tree: NASM source that assembles back to a file identical to the ROM (build.sh verifies with cmp), built up by carving out one understood routine at a time as a named procedure with comments and re-checking exactness at every step. So far that covers the windowed PROM reader, the RMA "Real Mode Access" backdoor the VBIOS uses to reach 32-bit MMIO from 16-bit real mode, the option-ROM chain scanner, and the devinit register-descriptor decoder and its operand fetcher. It reads as clean mnemonics now, and it still assembles to the exact bytes on the card.

And about an hour ago, the wall I'd been pushing on gave way. The video_bios.rom I'd been feeding the runner was truncated. The real card PROM is 256 KB and chains four option-ROM images — a legacy x86 VBIOS, a UEFI GOP driver, and two NVIDIA data images. Image 1's NPDE field quietly overrides the "last image" bit and points the chain scanner at the next image at offset 0x20600 — which is exactly where my old dump ended. So the scanner walked off the end of what I had, read open bus, and looped forever. Once I pulled the full 256 KB dump (sha-identical to the old one over its first 0x20600 bytes, so I knew it was the same card), the chain scan terminated and execution marched straight past the wall into new code.

From here the path is clear enough to describe. Get a clean mode 3 console. Then adapt the Unmatched's own firmware — U-Boot, and the SPL underneath it if I have to — so the whole chain runs the way a PC does: the video BIOS lights the screen, mr-bml puts up its boot menu, QSOE comes up on the display.

One more thing, and it's the part I keep coming back to. Andy Valencia — yes, the author of VSTa — wrote back today, and he was encouraging about the project. I sat and read VSTa's internals in 2000 to understand how a small message-passing OS actually fits together. That was 26 years ago. The line from those evenings to QSOE is not subtle. When the RISC-V personal computer is really working — screen, menu, my own OS booting on it — I'm going to record it and show him, and the rest of the world too.

Comments

Post a Comment

Popular posts from this blog

QSOE project v0.1 is released

The first QSOE release, v0.1, is out. It bundles both kernel variants, the boot loader, the userspace, and libc into a single numbered drop, and consists of the following components: QSOE/N v0.17 , with the custom "Skimmer" kernel. QSOE/L v0.14 , which works together with seL4 version 15. mr-bml v0.5.1 , a GRUB-derived boot loader with support for Multiboot 3, RISC-V Linux-style kernels, and kernels with an EFI stub. quser v0.5 , offering an mksh-based shell (qsh). libc v0.6 . The two variants share the same userspace above the seam: quser, qsh, and libc are identical, with only taskman and libc.so differing per kernel. That shared userspace is the whole point — one QNX-compatible environment over two very different microkernels. The milestone behind this release is on the QSOE/L side: it now boots from NVMe storage to an interactive login shell on the SiFive Unmatched (FU740). Spawning the first program off a mounted disk had exposed a pair of deadlocks — taskman blocked ...
Read more

How QSOE started

It was the first of April, and work on QRV — my port of QNX to RISC-V — was in full swing. A couple of weeks earlier I had put up an open petition asking QNX Software Systems and BlackBerry to re-license the historical 2007–2009 QNX Neutrino source under Apache 2.0. Around this time a thought settled in: there's a real chance it gets ignored completely. I needed a plan B. I've kept the L4 microkernel in the back of my mind for a long time. I first read about it in the early 2000s, along with its various implementations — the ones with the nutty names (Hazelnut, Pistachio), and the one with the funny name, Fiasco, from the group in Dresden. I met those people in person about ten years ago. I never really stopped thinking about L4 after that; I knew about L4Linux and the rest. And I got particularly interested when I learned about seL4. What seL4's authors did still strikes me as a genuinely novel approach: a real microkernel with a machine-checked proof of functional corr...
Read more

QSOE/L: the same userspace, on seL4

The three QSOE/N posts ended with a promise — the other half of the umbrella, QSOE/L, the same userspace running on seL4. This is that post. It is also, in a sense, the first post, because QSOE/L is where the whole thing began. Tomorrow is one month to the day since I started the real QSOE, and the first thing that booted was an seL4 image. QSOE/N, the from-scratch-kernel variant I wrote about first, is the younger sibling. I led with it because the milestone there was loud: a microkernel I wrote myself taking its first breath on real silicon. QSOE/L's story is quieter and, for the shared userspace, more foundational. Everything that runs on Skimmer today was made to run on seL4 first. No kernel to write On seL4 there is no kernel to write, and that is the entire point. seL4 is a verified, capability-based microkernel; the job was never to build a kernel but to build a QNX-Neutrino-shape operating system on top of one. seL4 has opinions, and the strongest of them is about IPC. It...
Read more