Ask HN: Where can I find a primer on how computers boot?

Jonathan de Boyne Pollard wrote some reasonably concise descriptions of this and related issues. His overall "FGA" index is at [1], and you might be more specifically interested in [2] and [3].

[1] http://jdebp.uk./FGA/

[2] http://jdebp.uk./FGA/pcat-boot-process.html

[3] http://jdebp.uk./FGA/efi-boot-process.html

There are some general/generic things that are the same on most platforms, but even just within Intel-based desktop computers there is a huge variety.

Most links here are very useful describing booting from a firmware perspective, CPU perspective, kernel perspective etc. but it really depends on what level of detail and level of knowledge you want to dig in to.

In general, this is what happens when you plug in the power and push the power on button:

  1. When power is applied, the hardware (so no software or firmware!) makes sure that your power supply is healthy and uses stand-by power (which is always on) to check if you are pushing the button to turn the system on

  2. Once you push the button, the circuit uses its stand-by power to turn on main power, which in turn does some hardware voltage and timing checks of its own, while also 'holding' the main processor and some other components in an endless reset state

  3. If everything checks out, the clock runs and the power is good, it releases the infinite reset and the processor is allowed to run

Those three steps are very generic, and highly dependant on standards like ATX, x86, and whatever component and mainboard vendors tack on to it. Diving deeper into this would direct you into the area of digital electronics, power management, timers, microcontrollers etc. On one hand it might not matter what the electrical details are, on the other hand, it is very much a part of 'booting' a computer. Primers on how this works haven't been shared so far, but I would dig some up.

Onwards:

  4. Only at this time does software or firmware even come in to play. When a CPU wakes up and comes out of reset, there is one pre-defined thing it was designed to do, specific to the how the CPU was built; usually it is going to have a special location in memory where it always begins to look for things to do: the reset vector. Decades ago, this was very simple, it would just expect you to connect a memory device like a BIOS memory chip to the CPU on specific pins, so that when the CPU comes out of reset it always starts at the top of the memory contained within that chip and just does what it tells the CPU to do. In a way, this could be referred to as IPL: initial program load, something that mainframes used to do (and in a way still do). You have to tell the processor what to do, otherwise if you give it power, it just sits there doing nothing. But you can't tell it what to do if there is no program running to tell it to do anything, hence the reset vector, a hard-wired first-step that it always performs. All you need to do is make sure that you have a chip put at the location it expects which contains some CPU instructions.

 5. Once the CPU has started executing whatever it found at the reset vector, it is actually doing stuff. In most cases, it starts running BIOS code. Various references to information as to how this works are specified in the comments, but also on Intel's website, on the UEFI site, Coreboot site etc. If you were to dive much deeper into this, you would get into Firmware Support Packages, BringUp code, Boot ROMs, Management Engines, SMM etc. Keep in mind that all of this is specific to x86 PCs, if you were to check out x86 servers, ARM systems, PowerPC systems, RISC-V systems, they all do similar things, but slightly different.

 6. At some point during this booting phase, the code the CPU found in the firmware chip (be it BIOS or UEFI) will have configured the DRAM so it can use the actual memory in the system, and perhaps started up the PCIe bus and some other systems like USB, PS/2 etc. This is an important moment because until now, the facilities you can use are extremely limited, there was no memory, no display, no keyboard etc. So after some of those were initialised, the primitive code gets switched out for some more advanced code which performs tasks you might be familiar with: POST codes, devices start showing some activiteit and the system starts powering up things like video output and keyboard input. At this point the system is also 'advanced' to the point where it can load your settings, such as your preferred boot device.

 7. This is the phase where it gets closer to actually using the computer, and most of the events that happened until now might collectively take 1 second to complete. A lot of stuff happens in very little time! Next, once the system has started itself to the point where it can communicate with you, and with peripherals like storage devices, it can start thinking about what to do next. In the firmware settings you can often specify the boot behaviour, for example you might want to have the system boot from a specific disk or file on a disk, or you might want to boot from a network device, or maybe you want to boot and get dropped into a shell. All of those things are essentially the same from the firmware's perspective. 

The first two of four steps described are often referred to 'early firmware' because the things it can do are very limited and serve mostly to prepare the system for more advanced firmware. Some of the steps are 'secret' and are delivered by the CPU manufacturer (like Intel). As a firmware developer you would get a bunch of binary data from them, and some instructions where you need to let it take control of the entire system for a bit, and hope that it gives control back to you. The x86 FSP and Coreboot teams deal a lot with this 'first steps to make the computer work' stuff, and are good starting points if you wanted to dive into that. Other resources are limited, companies like Phoenix and Inside and AMI keep their software secret and even if they would tell you about it, you'd have to pay a lot of money and sign an NDA. Other resources like the EDK and UEFI spec have been shared in other comments.

  8. Let's assume you want to run an operating system; you'd often find that the system has a bunch of files on a disk, using a filesystem. BIOS and UEFI are generally not very good at reading filesystems. The BIOS didn't really read much at all, and UEFI mostly does FAT32, with optional drivers for other filesystems. If you're on EXT4 (Linux) or NTFS (Windows), that's no good, because you can't really assume that your firmware can read that at all. What's more: the operating systems are likely using kernels that need advanced features to run, and a few of those need to be setup beforehand. This is where you'd use a boot loader: a program that is designed to bridge the gap between a firmware that can't do enough, and a kernel that wants too much.

  9. A bootloader is essentially just a program, so it can be loaded into memory, and started. This is a task the firmware can perform: BIOS would use a very rigid approach: read the first sector of the disk you picked, and hope it contains a boot loader. Not very flexible, and also very limited (one bootloader per disk for example). UEFI is a bit smarter: as long as you have a disk with a partition table of the GPT variant, and it contains a partition of the ESP type with a FAT32 filesystem, it can read directories and files all day long. So if you tell UEFI "run from disk 1 using file /efi/boot/banana.efi", it will go to the disk, go through the efi and boot directories, and load and execute the banana.efi program. It doesn't even really 'boot' anything, since an EFI program can be anything (it doesn't have to be a bootloader).

  10. At this stage the bootloader of choice has started, and the firmware can mostly be ignored. The bootloader is likely smart enough to load its own settings, for example what operating systems it knows about and on what disks they can be found. It also prepares things for the operating system, like what devices are known ahead of time, and where in the computers memory the kernel is going to be loaded.

The three steps above are mainly about control handoff and boot discovery. There are numerous standards and references on this, like the multiboot specification, but most of those (including GRUB) have been commented already. This is also the phase in which the computer does more or less what you see and use on a daily basis. Since there are many open source elements available, it is also much more open to exploration, and less 'hidden away' in proprietary secret documents.

Nearly all of this follows a relatively simple pattern: start small and primitive, do a dedicated task, start the next phase which is slightly bigger and slightly more advanced. Almost all steps in this pattern were built from manual processes; the farther back you go in time with older and more primitive computers, the more steps you'd actually be doing yourself. This can be pretty helpful to figure out why those processes or phases exist in the first place. A "manual" startup on a very old machine: https://youtu.be/PwftXqJu8hs?t=244 (edit: I made a mistake, this is not the bootup, but does include the line "powered on, because there is nothing to boot up" -- the machine essentially powers up and does nothing, no reset vector, heck, not even an actual reset! I'll try to find the reference to the actual bootup)

The 80386 System Software Writer’s Guide.

http://www.bitsavers.org/components/intel/80386/231499-001_8...

As an aside, GRUB here for general purposes is synonymous with other bootloaders such as NTLDR, Windows Boot Manager, lilo, and so on.

First, start by mentally preparing yourself that this mess is the foundation of our technologically based society.