Press the power button. Voltages stabilize, the clock begins ticking, and a cold piece of silicon is suddenly alive — but blank. It has no operating system in memory, no concept of files, no keyboard driver, no display. What happens in the next three seconds is one of the most carefully choreographed sequences in all of engineering: a relay race in which each runner knows just enough to find and pass the baton to the next.
Power-on reset
The first thing the chip does is the simplest. A small circuit detects that the supply voltage has crossed a threshold and asserts the reset line. Every flip-flop on the die — and there are billions — slams to a known state. The program counter, the special register holding the address of the next instruction, is set to a fixed boot vector. On x86 CPUs that vector is 0xFFFFFFF0. On ARM, it is configurable but typically zero.
Reset is the only moment in a CPU's life when its starting state is fully predictable. From here on, everything is contingent.
Firmware: BIOS and UEFI
The boot vector points into flash memory — a small chip on the motherboard, separate from the main DRAM and immune to power loss. There lives the system firmware. On modern PCs this is UEFI (Unified Extensible Firmware Interface); the older standard was BIOS. On Macs it is similar firmware called iBoot. On a Rubin GPU node, the BMC (baseboard management controller) plays a comparable role.
The firmware's job is to inventory and initialize the hardware: detect how much DRAM is installed and run memory training to find optimal timings, enumerate PCIe devices, set up the interrupt controller, initialize the chipset, configure the CPU's microcode, and locate bootable storage. It does this with a tiny, statically linked program that lives in flash and never trusts anything beyond what it has just measured.
Once it has a healthy machine, UEFI's last act is to find a bootloader on disk and jump to it.
The bootloader
The bootloader is a small program — GRUB on most Linux installs, systemd-boot or rEFInd on others, the Windows Boot Manager on Windows, iBoot Stage 1 on Macs. Its only purpose is to find an operating system kernel on disk, copy it into memory, set up the conditions the kernel expects, and jump to the kernel's entry point.
This is more delicate than it sounds. The kernel image on disk is usually compressed (Linux's vmlinuz is a self-extracting blob), so the bootloader must decompress it into a clean region of RAM. It must also pass the kernel a bundle of facts about the machine — where DRAM lives, which CPUs are present, what the firmware promised — via a structured boot protocol. The Linux x86 boot protocol documents this handoff in painstaking detail.
The kernel takes over
The kernel begins its life single-threaded, in physical-memory mode, on a single CPU core. Its first acts are to set up its own page tables (so it can use virtual memory — Chapter 26), enable interrupts, initialize the scheduler, mount the root filesystem, and bring the other CPU cores online.
The Linux kernel boot is a set of well-named functions: start_kernel() calls setup_arch(), mm_init(), sched_init(), rest_init(). Each one transforms a slightly more limited machine into a slightly less limited one. By the end, the kernel has multitasking, virtual memory, and a primitive process list of exactly one entry: the init process, PID 1.
Into userspace
The kernel launches PID 1 — historically /sbin/init, today usually systemd on Linux, launchd on macOS, the Service Control Manager on Windows. PID 1 is the parent of every other process. It reads its configuration, mounts remaining filesystems, brings up networking, starts daemons (sshd, the display manager, audio, Bluetooth), and finally launches your login screen.
The whole sequence — power-on to login — takes about three seconds on a modern system. Behind that small wait is a five-stage relay race, each stage trusting only what it has measured, each stage handing off a slightly more capable machine to the next. None of the runners know the whole route. Together they get you from a dark chip to a working computer.
What they hand to the user is an illusion: that the machine has always been awake, has infinite memory, runs many programs at once, and is one's own. Producing that illusion is the job of the operating system, which we meet next.