First in a series on building a firmware-free VideoBIOS for RISC-V — teaching a cold graphics card to speak to a monitor before any operating system exists.
There is a small moment I have loved my whole life, and I suspect I am not the only one.
You press the power button. A fan spins up. For a second the screen is black — and then, out of that black, text appears. A memory count. A board name. A line telling you which key opens the setup. Half a second of the machine simply saying hello before it goes off to find an operating system.
I have spent decades around computers that do this, and I never stopped finding it a little bit magical. Not the operating system — the operating system comes later, and everyone talks about the operating system. I mean the moment before it. The moment when the bare machine, with no disk mounted and no kernel loaded, already knows how to talk to you.
This series is the story of how I tried to give that moment to a computer that never had it. But before any of the hex and the heartbreak, I want to explain why it mattered enough to spend the better part of two years on it.
A product, not a kit
When I was young the IBM PC and its compatibles were, to me, a kind of quiet miracle of engineering — not because any single chip was brilliant, but because the whole thing was thought through as a product. Somebody had sat down and decided what a person sitting in front of this machine should experience, from the very first instant of power, and then made a hundred different manufacturers agree on it.
Think about what that actually required. A video card from one company had to light up a monitor from another company, driven by a BIOS from a third, on a motherboard from a fourth — and it all just worked, the moment you switched it on, with no software installed at all. There was a standard for how the card announced itself. A standard for the text the firmware could print. A standard for the keys you pressed to change settings. A standard for how the screen was laid out: 80 columns, 25 rows, an attribute byte for every character.
None of that was inevitable. It was designed. It was oriented, deliberately, at the human being in the chair — usability, compatibility, standardization, all in service of the idea that a personal computer is a finished product you can buy, take home, and use, not a bag of parts you must first understand.
I have carried an enormous respect for that idea ever since.
The machine always started by speaking
Here is the part that seems almost quaint now, and that I miss more than I can justify: every one of those machines started in text mode.
Before the graphical desktop, before the splash screen, before anything decorative, the computer came up talking. Plain characters on a plain background. The firmware greeted you, the boot loader offered you a menu on the monitor, and if something went wrong, it told you so — right there, in text, on the same screen you were already looking at. You did not need another computer, a serial cable, and a terminal program to find out why your machine would not boot. It told you itself.
That text-mode greeting was the machine's native voice. It was the first thing it learned to do and the last thing it would give up. You could lose the disk, lose the OS, lose almost everything — and the box would still come up and speak.
The gap I could not stop noticing
Years later I fell in love with RISC-V — the open instruction set, the idea of a truly open computer from the silicon up. I built and collected RISC-V machines. I ported operating systems to them. I wrote my own. And somewhere in all of that, a small, nagging absence started to bother me more and more.
There is no RISC-V personal computer that greets you the way an IBM PC does.
I do not mean there is no RISC-V hardware — there is plenty, and some of it is wonderful. I mean there is no RISC-V machine you can buy that is finished as a product in the old sense: no firmware setup screen on the monitor, no boot menu you can read on the display, no reassuring line of text at power-on. The early boot happens over a serial port. To watch your own computer start up, you attach a second computer to it. The monitor stays dark — often completely dark — until a full operating system has loaded a full graphics driver.
For a server in a rack, fine. But I did not want a server. I wanted a personal computer. And a personal computer that cannot say a single word to its own monitor until Linux is fully up is, to me, missing something essential — the very thing I had admired all those years.
Building my own — and meeting the dark screen
So in 2021 I did the obvious thing for a person like me: I built the machine myself. A RISC-V board (SiFive Unmatched), a real graphics card, a real monitor, a real keyboard. A personal computer, assembled on my own desk.
And it worked beautifully — with exactly one condition. The screen came
alive only after the Linux nouveau driver had
loaded. Not one instant before.
Sit with what that means day to day. Every time Linux had trouble booting, the monitor showed me nothing — I had to crawl back to the serial cable to find out what happened. And when I started developing my own operating system on that machine, the situation was worse: my OS had no graphics driver, so my beautiful personal computer, with its beautiful monitor, produced zero output on the screen, ever. Just the serial port, as always. The display sat there, powered, plugged in, and mute.
I had built the RISC-V machine I wanted — and it could not do the one small, magical thing every cheap PC from Early Days did without thinking: come up out of the black and say hello.
The question
That is where this whole adventure begins — with a question that sounds simple and turned out to be anything but:
What would it take to make a cold RISC-V machine speak to its monitor, on its own, before any operating system exists?
Not "load a driver faster." Not "port nouveau." Something closer to what a real PC has: a small, self-contained piece of firmware that wakes up the graphics card from cold silicon, puts a readable, colorful greeting on the screen, and then politely steps aside so the operating system — any operating system — can take over.
It took me down two very different roads. The first one seemed obvious, consumed months, and ended at a wall. The second one meant throwing the first away entirely — and it worked.
In the next post, I'll tell you about the idea that started the first road: the realization that the graphics card already carries a program that knows how to wake itself up… it just happens to be written for the wrong kind of processor.
Next: The Idea, and a Buried Emulator.
No comments:
Post a Comment