How an operating system boots

I think you can only have one operating system in the MBR. The confusion comes from the fact that LILO is good and can boot multiple OS's. (Apologies for the short writeup.)

Update 10/01/2002: Getha pointed out that the O'Reilly reference has moved. Thanks!
Take a look at http://linux.oreillynet.com/lpt/a/linux/excerpts/linux_kernel/how_computer_boots.html for more on PC architecture from the Linux viewpoint. It highlights the similarities with the Mac description by ccunning.

Update 31/05/2001: Take a look at http://www.howstuffworks.com/operating-system2.htm (and the other pages in the article) for almost exactly what this node is about, sort of :-).

Booting is the process of a computer becoming operable when power is applied.

There are a number of stages.

First, all the hardware must be reset into a sane state. This is handled by low-level hardware design and is beyond the scope of this write-up.

Then the CPU must be given some instructions to execute. Usually this is called "bootstrap" code. It's just enough to get the next stage underway. The 6502 processor, for example, always starts execution at the same memory location. Putting ROM at this point in the address space provides the initial CPU instructions. I imagine other systems follow a similar mechanism.

On some systems (e.g. ZX81, BBC Micro, Acorn Archimedes), the operating system is held in ROM and can be started directly. However, on PCs, as the OS needs to be loaded (either from fixed (hard disk) or removable (tape, floppy, CD-ROM, etc) media), the bootstrap code must access these external devices. The code to load the OS is part of the BIOS. (Note, even on ROM-based systems, a division between "BIOS-like" layer and a higher Operating System layer can exist, allowing alternative operating systems to be loaded.)

Beyond this point generalisations become less useful. However, the following is a reasonable effort:

• the OS will install "handlers" for all the hardware devices it can identify.
• any OS-specific initialisations will be performed.
• usually some administrative shell is executed.
• processes are then executed to put the computer in a mode suitable for normal use.

On a PC, the BIOS loads and executes code from a "known location" on the boot media, called the Master Boot Record. This is also known as "second stage bootstrap", as this area isn't large enough to hold a complete operating system for the PC. The second stage bootstrap is more complex than the BIOS routines that loaded it, and can - for example - provide a choice of operating systems to load.

This process also occurs in some mainframe systems. The "BIOS" knows how to read a paper tape (a simple serial input device), for example (maybe having had the routine entered from the panel). The routine on paper tape is then general enough to load the operating system from disk.

I must disagre with what Rancid Pickle has said, all operating systems do not in fact have a similar boot process. Most notably, those machines which are based on Open Firmware (Sparc, Macintosh, PowerPC, among others) have a radically different boot procedure. As it is the only one I am really familiar with, I will describe the Macintosh boot process as an example.

When a mac is first powered on, it executes POST code in the on board ROM. This is non OS specific code which produces the startup sound and does some basic diagnostics. If it finds problems that prevent it from booting, it will display the sad mac icon. Older macs used to play the Chimes of Death, which was an unhappy sound indicating something bad has happened (usually bus or memory problems). Otherwise the happy mac icon is displayed and the boot process continues.

At this point, the Open Firmware code in the ROM is executed. Open Firmware is an abstracted method of finding and confinguring hardware to work with the computer, thus bypassing the ugliness that is the BIOS. After doing some initial checks for memory and bus type, Open Firmware will explore all attatched devices. For each device, it will look for FCode (device code written in Forth) on the device. Hardware can have both BIOS code and FCode in their ROMS, so Open Firmware needs to determine if the hardware will work with an Open Firmware system by examining the FCode. Once a suitable device is found, the Forth interperator in the Macintosh ROM executes the code found on the device ROM. The FCode on the device will initialize the device and make it's driver routines available to the OS.

Once it has found all available devices, Open Firmware will create a device tree listing all of these which are available to the OS. Open Firmware will then load a bootinfo file (I believe this is unique to Apple, there are different ways OF can proceed from here on different systems) which contains a description of the system, different operating systems available, icons for booting, and other information (I haven't found a ton of details on this, Apple's tech docs say to buy a IEEE book for more info...). This file is built from system defaults defined in the ROM and NVRAM settings. Once this is done, Open Firmware will then execute the script portion of the bootinfo file, which loads the Trampoline code (I suppose it's named because it "bounces" you to the OS...) and the Macintosh Toolbox.

At this point, the script transfers control to the Trampoline code, which acts as the transition from Open Firmware to the Operating System. Let's not get into trampoline code too much, as it is incredibly complex and I don't even claim to understand it, but basically it creates an executable on the fly that transfers control between two different code segments. The trampoline code will gather system information from Open Firmware, then load the MacOS ToolBox (much of the MacOS API) and transfer control to it, thus booting the MacOS.

At this point I should probably mention PRAM. PRAM is used to store information such as Appletalk, Printer, and Video settings. In times past, it also stored the startup disk. However, on New World macs, this is no longer done and instead the startup device is stored as variable in NVRAM for Open Firmware. When Open Firmware looks for the MacOS toolbox ROM, it will first check the device specified by this variable. Next it will go to the last booted device. If both of these fail, it will attempt to load any other bootable volume it can find. Failing to find any boot volumes, it will sit there and display a disk icon with a question mark on it.

Assuming it has found a volume to boot off of, and has loaded the Toolbox ROM, the OS will be loaded. The initialization process will load the System into memory and then load all extensions and control panels in alphabetical order. Finally, the Finder is started allowing the user to interact with the OS.

New World ROM

Newer macs, released after the first rev iMac, contain what is known as a New World ROM. The traditional mac design had a rather large ROM which in addition to Open Firmware and boot programs, also contained most of the Macintosh Toolbox. This was because way back in 1984, ROM was cheap, RAM was expensive, and disk space was small, so keeping it in the ROM was a good idea. This all changed with the New World ROM mac's, which moved the Toolbox to a file in the System Folder. I believe MacOS 8.6 was the first OS to include this ROM file. This changed the way Mac's boot somewhat, as the Trampoline code now had to load a file to initialize the boot. For the most part, however, it has little impact on the actual process of booting that I can tell.

So this is my understanding currently. Information is sketchy, and finding differences between how old world and new world macs boot is a bit tricky. I'm still seeking out resources to verify everything, I'll update this as I figure stuff out. I'm also trying to figure out how other OS's fit in this picture, on Old World machines Linux was booted by loading MacOS at which point a system extension would kill MacOS and begin loading the linux kernel from withing MacOS. On new world machines you can boot directly into linux, but I'm not sure what part of the process this occurs at...