Boot Process

Between power button and your kernel's first instruction lies a fixed, ancient choreography. Every stage exists because the previous one was too small or too dumb to do the next job — a bootstrap chain where each link loads a bigger link. Know the order cold; your exercise is to reconstruct it from shuffled observations, and debugging a real boot means recognizing which stage died.

Stage 0: the reset vector

At power-on, an x86 CPU doesn't look for an OS. It sets CS:IP so execution begins at 0xFFFFFFF0 — the reset vector, 16 bytes below 4 GiB, hardwired to point into the firmware ROM chip. And it starts in real mode: the 16-bit, ~1 MiB-addressable, no-protection mode of the 1978 Intel 8086. Every x86 CPU ever sold — including the one in a 2026 server — wakes up pretending to be a 48-year-old chip, because the boot chain was built on that contract.

Stage 1: firmware (BIOS POST)

The firmware runs POST — Power-On Self Test: check RAM actually holds values, walk the buses to discover devices, initialize enough of the chipset to read a disk. Then it picks a boot device and reads exactly one sector — the first 512 bytes of the disk, the MBR (Master Boot Record) — into memory at address 0x7C00, checks that it ends with the magic bytes 0x55 0xAA, and jumps to it.

That's the whole BIOS→OS interface: 512 bytes at a fixed address. No filesystem, no kernel format, no negotiation.

Stage 2: the bootloader's two halves

You cannot fit a filesystem driver in 512 bytes (446 usable after the partition table). So bootloaders split:

• Stage 1 (the MBR code): knows only how to load more sectors from a fixed disk location — where stage 2 lives.
• Stage 2 (GRUB's core image): the real program. It has filesystem drivers, so it can finally read files: its config (/boot/grub/grub.cfg — GRUB 2 config, the old menu.lst died with GRUB Legacy), your kernel image, an initrd.

GRUB then performs the handshake your kernel depends on. For a Multiboot2 kernel like this course's, GRUB:

1. Loads the kernel ELF into memory at the addresses its headers request.
2. Collects the memory map (via BIOS call E820) — the list of which physical RAM ranges actually exist and which are reserved. Your kernel cannot ask the hardware this later; it gets one copy, now, from the bootloader.
3. Leaves a pointer to that info in a register and jumps to your kernel's entry point.

Stage 3: mode switching

Somewhere between GRUB and your kernel's main, the CPU has to grow up from 1978 to now:

• Real → protected mode (32-bit): enable the A20 address line, load a GDT (next lessons), set the PE bit in control register CR0, and far-jump to flush the pipeline.
• Protected → long mode (64-bit): build minimal page tables, point CR3 at them, set LME in the EFER register, enable paging. Long mode requires paging — there is no 64-bit execution without page tables.

Stage 4: kernel early init

Your kernel's entry code finally runs, and it trusts nothing:

1. Zero the .bss section (globals the ELF file doesn't store bytes for).
2. Set up a real stack.
3. Bring up an early console (serial UART or VGA text buffer) — because a kernel that can't print is a kernel you can't debug.
4. Load your own GDT and IDT — GRUB's tables were a loan.
5. Parse the memory map, start the physical allocator, then paging, then the scheduler… the rest of this course.

Last step of a full OS: mount a root filesystem and start PID 1 (init/systemd) — the first ring-3 process, parent of everything you've ever run.

The UEFI difference

Modern firmware (UEFI) replaces the MBR dance: it reads a FAT-formatted EFI System Partition, runs the bootloader as a proper executable file, and hands over a memory map through ExitBootServices(). Cleaner — but it just moves the same handshake into nicer clothes. The stages you must be able to order — POST → MBR load → stage 2 → config/kernel load → mode switch → kernel init → PID 1 — survive in both worlds, and QEMU (which you'll use to boot your kernel) will happily show you either.