This column is not about Coreboot yet, but about the very general problem that Coreboot solves. We are talking about the bootstrap problem of a general-purpose computer.
The figure below shows a very basic block diagram of a computer system. It consists of the CPU, a memory (RAM) and a number of I/O devices. All of these are connected by a system bus. The CPU executes instructions that are stored in RAM. These instructions can read data from RAM or from I/O devices, it can manipulate that data and it can write the result data to RAM or to I/O devices.
When the CPU is started up, it starts to read and execute instructions from a well-defined location in RAM. But wait: what instructions are stored in RAM when the computer is powered up? Probably nothing useful. From the late 1950s to the early 1970s most computers used core memory for RAM, which is non-volatile. When you powered the machine up, RAM still contained whatever was stored when the machine was last used. But of course the last time the computer was used, a runaway program might have erased the startup code. And what if the computer was started up for the very first time?
Originally the solution was to add a front panel with lights and switches, so you could manipulate the contents of RAM before the CPU would run.
In general a front panel would contain at least one row of lights and switches that was as wide as a machine word, for instance 16 switches and 16 lights for a 16-bit computer. With certain other switches you could set the memory address being examined or altered, write new data to a memory location, reset, start and stop the CPU. Most front panels offered a way to read and write individual CPU registers and to step through the program one instruction at a time. This way you always had a debugger at hand, albeit a primitive one.
In the late 1950s a computer was a rather large and expensive machine. It cost more than a luxury car or even a house. A front panel full of switches and lights added comparatively little tot he cost of such a machine. When the computer was powered up, the CPU was not yet running and the operator could use the front panel to read and write the contents of RAM without the aid of the CPU. When a suitable program was stored into RAM, the operator would set a front panel switch to the RUN position and the CPU would start to run. Most computers built before 1975 had such a front panel, as shown in the diagram below.
Each time the computer was powered up, the operator had to enter a boot program into RAM, which would read some data from an I/O device (such as a card reader, a tape or a disk). The loaded data formed a small program, which would in turn load even more data until the entire operating system or application was loaded. Depending on the machine architecture and the type of I/O device this could be a handful instructions or tens of instructions, which would have to be entered bit by bit each time the machine was powered up. This was not fun. Fortunately the instructions were often still stored in RAM.
Some computers added logic to the CPU, so it could load boot code from an I/O device all by itself without needing any instructions in RAM. The operator just had to push the correct button to select automatic boot loading from the correct device. The front panel was retained however, just in case.
When computers became cheaper, front panels with rows of lights and switches became more expensive, relative to the cost of the machine. Besides they were a distinctly user-unfriendly feature. Some early microcomputers from the 1970s still had a front panel, such as the MITS Altair 8800, but the vast majority of microcomputers came with ROM.
When the computer is powered up, the CPU starts to execute instructions from a well-defined address, which points to Read Only Memory (ROM), as shown in the figure below. The program in ROM controls what the computer will do after it is started up.
Now the functionality of a computer was determined not only by its hardware but also by the program stored in its ROM.
The scope of the software in ROM varied considerably among computer systems. In some machines the ROM would just load the first sector of a floppy disk into RAM and then jump to it. The program just loaded would load the operating system from floppy disk into RAM (typically CP/M). Such a computer would be utterly unusable without a suitable boot diskette. On the other hand it offered maximum flexibility as to what software you could run. Furthermore, the less functionality was included in the ROM, the easier it was to build a functionally equivalent computer without violating the copyright of the software included in ROM.
Other microcomputers would contain a BASIC interpreter in ROM. The ability to run arbitrary machine code programs on such a computer was often just incidental and in rare cases it was not provided at all. In many computers the program in ROM determined what a computer could do and how troublesome it was to do things differently. RAM size was often very limited, so having important programs (or the operating system) already stored in ROM meant that more RAM was available for applications or data. Furthermore, programs in ROM did not have to be loaded from slow media each time, such as cassette tapes.
So some computers had very limited firmware embedded into their ROM, some had an extensive set of programs on ROM, but practically all machines had ROM. There were certain advantages to having limited ROM functionality and there were other advantages to having extensive ROM functionality.
In the 1980s the functionality of a microcomputer was determined at least as much by its firmware in ROM as by its hardware. The Apple MacIntosh might have had a similar hardware architecture to the Atari ST, but each had its own different operating system in ROM.
Of course there were those brave people who would replace the ROM chips inside their computers by ROMs they had programmed themselves, so they could regain complete control over their machines, which was lost when the front panel had disappeared. Coreboot is just such an endeavor.