I’m a Windows user get me out of here!
It’s hard to know just how much we’re handled with kid gloves these days as computer users – and this journalist says that from a Linux user’s perspective. It’s likely that many APC readers will remember children’s electronic kits from the 1970s, like Radio Shack’s Science Fair Microcomputer Trainer. You had to handwire components to create a suitable circuit, then program the CPU by inputting single commands and variables in hexadecimal. Horrifying, but fun!
It’s the sort of barebones introduction to computing electronics that will suitably traumatise a young child into wanting to learn to program. It’s also about as far away from how current children are introduced to the subject via sanitised iPads and touchscreen devices. Where’s all the fun if there’s no screaming “What do you mean I have to wire up the resistors with my bare hands just to make it go beep?”
It’s this detachment from the underlying (metaphorical) cogs, wheels, and pulleys of computing that triggered the creation of the Raspberry Pi – and let’s never forget that Eben Upton only ever expected to sell a few thousand, not 35 million, which tends to indicate that there’s some sort of pent-up demand for this low-level access.
We’re going to first look at the various parts a PC needs to power up, before it even boots an operating system. Then, once we’ve covered the building blocks, we’re going to move on to installing Arch Linux. This is one of the distros that requires a more “hands on” approach to getting it up and running, but some variants like Gentoo (that requires compiling every element from source) or Linux From Scratch (which is actually a book) take things even further.
To kick things off, the first thing to do is cheat. We’re going to presume that our dead PC has a working BIOS. We could try and argue that since this is firmware it’s actually more like hardware, as it’s baked into the EEPROM, but it’s still software. As we’ll cover later, without the BIOS you’d have a hard time doing anything: You’d have to first program the EEPROM using a dedicated system, and it’s highly tailored to the hardware.
The BIOS is the lowest level that software can interface with the hardware. At initial power on, accessing storage, display, audio, and other peripherals is only possible through the BIOS via interrupt calls. So without it we’re a bit stuck.
When you first press the power button, the PSU powers up the ATX cables, so SATA drives are directly powered, the motherboard, and GPU. The PSU can take a second or so to build a reliable power supply, and the chipset generates a reset signal for the processor (as if you’re pressing reset) until it gets a Power Good signal from the PSU. Devices such as memory have fixed logic and will initialise; more complex devices such as a GPU or network cards will have their own firmware that will initialise.
The reset signal is released, and the CPU powers up with a randomly selected single core, but requires something to run since the memory is blank. The original behavior is to have the first instruction mapped from EEPROM memory to 0xFFFF0h (1MB) – the maximum memory for 16-bit minus 16 bytes – the modern behavior is 0xFFFFFFF0h (4GB)
– the same but for 32-bit address space. That first command, called the reset vector, is always a long jump to where the BIOS is actually located – usually 0xF00000.
At this point your PC can run its Power On Self Test software. This largely initialises CPU registers, verifies the BIOS, verifies DMA, the timer and the interrupt controller, verifies system memory, and verifies boot devices. On modern systems this extends to verifying all system buses (USB, PCIe etc), devices and, displays. It also initialises the Advanced Configuration Power Interface (ACPI), setting the data in memory for use by the operating system kernel.
If a serious error is encountered that stops the system boot proceeding, the BIOS can communicate that in a number of ways: A screen error message or code; a series of audible beeps; or it can transmit an error over the PCI bus to a suitable debug card.
But if, as is often the case, everything goes well, then the BIOS is ready to hand off control of the PC to an operating system, but how? All that verifying buses and devices comes in rather handy at this point, as it’ll have a list of supported storage devices attached to detected buses. In the olden days this would just be the floppy drive, or the primary IDE hard drive. Today it could have a huge list of possibilities, as many of you might know from your own UEFI boot options.
It doesn’t matter if it’s an NMVe or a USB stick, the hand-off sequence is the same: The BIOS loads the first 512 bytes from the selected boot device – what we call the Master Boot Record (MBR) – it’s literally the first sector of a drive and is loaded into memory and directs the processor to run this code. The 512 bytes is even more limited than you’d think, as it also has to contain the basic partition table, limited to just four – one that can be marked as the “Active” boot partition, plus an end Boot Signature of 0x55, 0xAA that shows the drive is bootable.
As you can imagine, this isn’t any space to do much more than redirect the processor to where there’s more code to run. So the MBR is often called the Stage One Bootloader. On standard Windows systems the code directs the BIOS to load the first sector – so another 512 bytes – of the active-marked partition in the partition table into memory, and run that.
As an aside, be aware that UEFI firmware has supplanted the MBR on modern PCs, as the UEFI can directly understand drive and partition layouts and can store boot code on a FAT32 partition, doing away with the MBR’s limitation – a major limit to the MBR being a 2TB multi and 4TB single-partition limit, though MBR remains backwards-compatible with (U)EFI systems.
Are we there yet?
We’re getting there, the fuse is burning but the main event hasn’t quite ignited. At this point the MBR code loads the first three bytes of the active-partition’s first sector. This is a JMP command telling the system how far ahead to go to load the Second Stage Bootloader, and we can almost start our operating system kernel.
The main aim of the Second Stage bootloader is to load its configuration file, present any required user menu, and then to hand off to the operating system kernel with any required options – often recovery modes or older kernels. As this bootloader is required to access a file as part of a high-level file system (FAT32, NTFS, ext2/4) there’s a lot more complexity.
You would imagine it’d be easy to use hard-coded settings in many areas of this boot chain, but while it could work, it wouldn’t be very flexible, and a single change would cause the entire thing to fail. All the major bootloaders store a configuration file that’s loaded at boot-time from which any boot options are created.
Windows NT, 2000, and XP used the NTLDR bootloader that stores a boot.ini file on the root of the active partition. It also used the NTDETECT.COM tool to detect devices. Windows Vista and onwards use BOOTMGR, which maintains a BOOT folder with a BCD (Boot Configuration Database) binary configuration file. BOOTMGR was designed to support modern GPT and UEFI configurations, and its BCD cannot be edited by hand.
Most open-source OSes use Grub 2 (GRand Unified Bootloader). Released in 2012, this stores a grub.cfg in a /boot/ grug/ folder either on its own boot partition or in the base folder of the boot operating system.
Many Windows users won’t notice anything, and Windows will start up. However, your Second Stage Bootload can support multiple operating systems on a single system in a multi-boot format. Selecting the OS you want to boot kicks off the final stage of the bootloader process.
Depending on the OS and type of kernel, the bootloader will load the kernel image from the path specified in the configuration file into the memory. It points the CPU to JMP to a certain location within the kernel and starts running the operating system.