Breakfast Bytes Blogs

How does an operating system get started? Obviously, if the operating system was already running, you could get it to load the operating system from the storage media. But the operating system is not running, that is the problem that you are trying to solve. Starting up the operating system is known as bootstrapping, usually reduced to booting. The word comes from a very old (nineteenth century) aphorism that "you can't pull yourself up by your bootstraps". Some boots had (and have) straps so that you can pull them on. But if you stand on the ground and pull on the straps, you are not going to levitate. The phrase was something along the lines of "you can't do the impossible". Anyway, I'll leave that to the linguists.

In the computer world, you can pull yourself up by your bootstraps. The bootstrap is a smallish program that when it runs loads the operating system. But to run the bootstrap, it has to be in memory, so we've just kicked the can down the road. So let's look at how that has been done over the ages. I'm going to look at four cases. Three computers I'm very familiar with from when I was at university (and high school!), and one which serves as a canonical example of how it is typically done today on a modern system (including smartphones).

Interdata

I forget what model number the Interdata machines that we used at Edinburgh were. But they had a front-panel somewhat similar to the one in the image. There are 16 switches as you can see. These could be used to enter an address or a dataword. It was a 16-bit machine, with a maximum of 64KB of memory. Above the switches, although you can't see them, are two rows of lights that could be used to show an address and a dataword. The switches to the left allow you to start and stop execution, single step. And, for our purposes, load a value into memory. You could enter an address on the switches and press one of the switches on the left. Then enter a data value and press a different switch. The address would increment automatically, so then you could enter the next data value.

So the answer to the question of how you get the bootstrap into memory is that you laboriously enter it a word at a time in binary using these switches. This isn't quite as bad as it sounds, since in that era memory was ferrite-core and so was non-volatile (not a word that was used back in that era since all memory was non-volatile). I did all our students a favor by rewriting the bootstrap to be about half the size by removing all the error-checking, so there was less to enter when you "lost the bootstrap" which could happen all too easily since there was no memory protection. If you decided to clear a block of memory but your code was wrong, it might clear the entire memory, and then you had to start over. Every computer (I think we had 16 plus another two that actually had disks) had the code for the bootstrap on a piece of paper taped to the front of the machine.

There was no operating system on the student machines. They were running on the bare metal, as we say today. The terminals (mechanical) that they had were connected to the central computer (with the disk) so the typical way a student would do a project would be to edit the code on the central computer, assemble it, then type a command to copy the code to the appropriate serial link. Then, on their computer, they would run the bootstrap. This would download their program over the serial link one byte at a time and store it in successive memory locations. They could then run it and debug it.

As part of my PhD, I created a diskless operating system LEGOS that ran on the same hardware, actually a derivative of the ISYS operating system that ran on the central computers with the disks on the student clusters. I also created a central fileserver that many machines could access. The bootstrap on the diskless operating system worked by sending a short message to the fileserver. The fileserver would then transmit the entire operating system. The bootstrap read it one byte at a time and copied it to memory, and then transferred control to the operating system.

Pretty much all minicomputers of that era worked something like this. The bootstrap had to be entered manually but usually would usually just be in memory when you wanted to reboot the operating system. You entered the address of the bootstrap on the front panel and started execution there.

ICL 1900

But some machines were more sophisticated than that. The ICL 1900 machines that we used when I was in high school had a button you pressed. This essentially did the same thing, it started execution of the bootstrap, the address of which was on a bank of 16 switches just inside the front panel. The systems had disk drives, but loading an operating system directly from a disk drive was far too complex and the bootstrap would be too long to enter by hand. Instead, the real bootstrap was held on paper tape. The bootstrap which ran when you pressed the button was known as the primary bootstrap. On the paper tape was the secondary bootstrap, with device drivers for the disks. When the secondary bootstrap ran, it would load the real operating system (called GEORGE) from one of the disk drives.

This two-phase approach is now standard. The primary bootstrap has to be very small, either because you had to enter it from switches on the front panel (in the stone-age era), or because it is in ROM and so can never practically be altered. If the secondary bootstrap was in ROM, you could never get it to support a new type of disk drive, for example. Halfway between the front-panel switch era, and how things work today, is our next example.

VAX 11/780

The VAX 11/780 was a 32-bit machine built by Digital Equipment Corporation (DEC). When the computer science department at Edinburgh purchased one, it came with one DEC disk drive and we bought a couple (or maybe three) disk drives from a company called System Industries. Unfortunately, System Industries didn't actually have a device driver for their disks for the VAX. This was not a very wise purchase. Anyway, I was challenged by my PhD supervisor to create a driver and get the disks working. One challenge was that the information about how to write a device driver was sparse (the VAX was still very new). Luckily, and somewhat surprisingly, DEC also supplied the source code to the entire operating system on microfiche. So the first thing I had to do was find some of the drivers DEC had created for their own disks and find out how they worked. Long story short, I got the disks running fairly quickly.

But this is a post on bootstraps. Just because the operating system now contained a device driver for the disks didn't mean you could boot from them because the bootstrap didn't contain my device driver. Here's how the VAX actually booted. Inside the front door to the main CPU was a little box that actually contained a 16-bit DEC computer of a previous generation with an 8" floppy disk drive. This was the first time I came across a computer that had a little baby computer just (well, mostly) to handle booting the main computer. This is standard today.

To boot the system, you pressed the rightmost of those two white switches, the one labeled "boot" (the switch on the left determined whether, if the system crashed, it rebooted automatically or just sat there waiting for someone to do something manually).

I don't really remember, if I ever knew, how the little 16-bit computer booted but once it was up and running, it would read the secondary bootstrap off the floppy disk and load it into the VAX's memory. The secondary bootstrap would then load the operating system (VMS) off the disk and then transfer control to it. With a fair bit of detective work, I learned how to link a disk device driver into the bootstrap and copy it onto an 8" floppy disk. Now, when my modified secondary bootstrap was loaded into memory, it could load VMS off the System Industries' disks.

Google Servers

I've written before about how a Google server boots in my post Google's Titan: How They Stop You Slipping a Bogus Server into Their Datacenter. However, this is a good example of how a modern system, even your phone, boots.

The primary bootstrap is held in a boot ROM. This is ROM and so can't be changed (you really do not want to change the ROM chips on every server in a hyperscale data center!). Since it can never be changed, it has to be pretty small. Its sole purpose is to verify the cryptographic key for the secondary bootstrap, and, all being well, transfer control to the secondary bootstrap (the yellow boot loader in the diagram). The reason that there are two bootloaders is so that if updating a bootloader fails and leaves the flash corrupted, the server isn't bricked forever. The secondary bootstrap cryptographically verifies the operating system itself, and again, all being well, loads it into the main memory of the server and transfers control to it.

This process is economical because we have ROM, flash memory, small processors, and these are all cheap in silicon. We can afford to have a special computer just to take care of the boot process, just as the VAX 11/780 had a small 16-bit computer in it.

IBM 1401

I never used the IBM 1401. It dates back so far, 1959, that it didn't even use silicon-based transistors, it was still individual germanium transistors. Obviously, every extra transistor increased cost quite a bit. This computer used 80-column punched cards and, obviously, had a card reader. By the way, since on a punched card the characters (columns) are encoded left to right, you might assume they are read that way. First the first character, then the second character, and so on. Actually, card readers work in the orthogonal direction and all 80 characters are read into memory at the same time.

Here is a description of the byzantine method that the IBM 1401 used to boot up. There was no operating system, so every individual program had to contain its own bootstrap mechanism to get the program into memory to be run. The only capability that the hardware had was that you could press a button on the card reader and it would read a single card into the computer's memory at address 0 and then start to execute code at address 0. I'll leave you to read the piece at the link if you really want to go deep down the rathole.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.