QSOE Development Blog

v0.1 was a singular machine. One userspace, booting on two kernels, at one console, on the board it was tuned for. Everything difficult about it was internal — the spawn-from-disk deadlock, the libc seam, getting one set of binaries to come up under both Skimmer and seL4. v0.2 is the cycle where that machine stopped being singular. A second machine appears on a wire; a second console appears on the screen; a second silicon target, the SpaceMiT K3, stops letting the code assume the machine underneath it. None of the three is finished, which is why v0.2 is a candidate and not a release. But the shape of each is in the tree now, tagged rc1 through rc3, and the through-line is the same one every time: a thing that used to be assumed unique — a node, a terminal, a connection id, a hart — has to be made to mean the right thing once there are two of it. The userspace is still a single body. libc.so and quser are shared source; only the seam differs — taskman and a handful of kernel calls, p...

HFI BIOS version 1.3 has been released. Video demonstration: https://www.youtube.com/watch?v=GBVH-6bD9yI Main features SpaceMiT K3 Pico ITX support. The board cold-starts from NOR and boots through to a Linux desktop: the panel is driven by a VideoBIOS module, UFS storage is enumerated over SCSI, and USB host, PCIe and the on-board Ethernet all come up in firmware. The network is handed over live. The firmware takes the interface all the way to a negotiated link and leaves it running, so the operating system inherits a working interface rather than a chip to initialize from cold — and is told the address and link state through the device tree it was already reading. The board fan is started during power-on , and its speed is shown on the PC Health Status page. A machine left sitting at a firmware prompt is cooled rather than merely measured. A complete device tree is handed to the operating system , with ...

On the 2nd of July I made the first commit in a repository called fu740-bios . Its README opened with a single sentence that never changed, even after the project outgrew the board in its name: A RISC-V machine that powers on and greets you like a classic PC. Not a boot loader with a menu. A BIOS : the rainbow banner, the memory count, the hardware summary, and the immortal Press DEL to run Set-Up — on a real monitor, through a real graphics card, driven by a real USB keyboard. I had been turning that idea over for something like twenty-five years. On the 14th of August it does that on two entirely different machines, and today I am tagging 1.3. This is the story of the six weeks in between. The dead end that shaped everything The project actually starts in June, in a directory called gk208-vbios-runner , and with the obvious idea: a graphics card carries its own initialisation code in its option ROM, so let the card initialise itself. Run the NVIDIA GK208's x86 VBIO...

For a few months there has been a compiler in my tree that I have said nothing about, and it has now done the one thing that made me want to write about it at last: it compiles the whole of QSOE/N — the Skimmer microkernel, taskman, the C library, the dynamic loader, the shell, and every driver and userspace program — and the operating system it produces boots on real hardware and logs in as root, with no GCC anywhere in the toolchain that built it. The compiler is qjmcc , and it is the Portable C Compiler. If that name means nothing to you, the next part matters more than any of the engineering that follows; and if it does mean something to you, then you already understand why I have wanted to write this for months. What pcc is, and what Anders Magnusson did to it The Portable C Compiler — pcc — was written by Stephen C. Johnson at Bell Labs in the mid-1970s, the same Johnson who gave us yacc and lint, and it was one of the first compilers built deliberately to be moved from one ...

Two things happen in this release, and they turn out to be the same thing seen from opposite ends. QSOE/N boots to an interactive shell on the SpacemiT K3 — the second piece of silicon it has ever run on, after the SiFive Unmatched. And the entire operating system — kernel, taskman, libc.so , the runtime linker, every program under /bin and /sbin — now builds with a second compiler, jmcc, and boots on it too. Neither was on the roadmap as "portability work". Both were the same lesson delivered twice: stop assuming the thing you were tuned for. The K3 broke every assumption baked into the hardware — one machine, one DRAM base, one interrupt geometry. jmcc broke every assumption baked into the toolchain — position-independent code, hard-float, GCC's particular generosity about relocations. Each found bugs the other never would have, and by the end the system is more honestly portable than it was before either one started. The K3 does not resemble the machine we wer...