From Power Button To CPU Boot - The Complete Hardware Journey

Introduction

You press the power button on your computer every day, right? But have you ever stopped to think about what's actually happening in those first few milliseconds? I mean, really happening - at the hardware level, with electrons flowing through traces, signals bouncing between chips, and your CPU waking up from its digital slumber?

Well, I have. And honestly, it's way more fascinating than you'd think. This isn't some abstract "the CPU turns on and loads the OS" hand-wavy explanation. No, we're going full depth here - from the mechanical click of that button to the first instruction your CPU executes in real mode.

This is Part 1 of a series that will eventually take us all the way from the power button to the login screen. Today, we're focusing purely on the hardware journey: the power supply unit, the motherboard, power sequencing, and getting the CPU to boot up and execute its first instruction.

I'll explain everything step-by-step so you can follow even if you're not a hardware engineer. Just bring your curiosity and maybe a cup of coffee, and let's see what really happens when you press that button.

The Power Button: It's Just a Switch (Kind Of)

Let's start at the very beginning. Your power button is, at its core, a momentary switch. When you press it, it closes a circuit for a brief moment, and when you release it, the circuit opens again. That's it. No magic.

This button doesn't actually control the main power to your computer. That would be impractical from a safety perspective, and you'd need a button capable of switching hundreds of watts, which would be bulky and expensive.

Instead, the power button is a signal button. It sends a low-voltage signal to your Power Supply Unit (PSU) telling it: "Hey, the user wants to turn on the computer."

The Circuit

Here's a simplified view of what's happening:

 +5V Standby (from PSU)
 │
 │
 ╱│╲
 │ │ │ Pull-up resistor (typically 10kΩ)
 │ │ │
 ╲│╱
 │
 ├─────────► PS_ON# pin (to PSU)
 │
 ┌───┴───┐
 │ │
 │ PWR │ ← Power button (momentary switch)
 │ BTN │
 │ │
 └───┬───┘
 │
 GND

When the button is not pressed, the PS_ON# signal is pulled HIGH (to +5V) by the pull-up resistor. When you press the button, it connects the line to ground (GND), pulling the signal LOW. This LOW signal is what tells the PSU to start the power-up sequence.

The "#" in PS_ON# is engineering notation meaning "active low" - the signal is active when it's at a low voltage level. You'll see this convention a lot in hardware documentation.

The PSU: Always On (Sort Of)

Here's something most people don't realize: when your computer is "off," the power supply isn't actually fully off. Let me explain.

Standby Power (+5VSB)

Modern ATX power supplies have what's called a standby rail that provides +5V even when the computer appears to be off. This is the +5VSB (5 Volt Standby) rail, and it's always powered as long as the PSU is connected to AC power and the switch on the back is on.

This standby power serves several critical functions:

• Powers the power button circuit
• Keeps certain motherboard circuits alive (like USB ports for phone charging, wake-on-LAN circuits, RGB LEDs, etc.)
• Provides power to the Power Management Integrated Circuit (more on this later)

The +5VSB rail typically provides 2-3 amps of current, which is enough for these low-power functions but nowhere near what's needed to run the whole system.

Inside the PSU

Let's peek inside the PSU to understand what happens when that PS_ON# signal goes low:

AC Input (120V/240V)
 │
 ▼
┌─────────────────────────────────────────────┐
│ PSU (Power Supply Unit) │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ AC/DC │────►│ DC/DC │ │
│ │ Rectifier│ │ Converter│ │
│ │ & PFC │ │ │ │
│ └──────────┘ └────┬─────┘ │
│ │ │
│ ┌────┴─────────┐ │
│ │ Supervisory │ │
│ PS_ON# ────────►│ Controller │ │
│ │ (PWM IC) │ │
│ └──────────────┘ │
│ │
│ Outputs: │
│ • +3.3V (up to 20A+) │
│ • +5V (up to 20A+) │
│ • +12V (up to 40A+ on modern PSUs) │
│ • -12V (legacy, low current) │
│ • +5VSB (2-3A, always on) │
│ • PWR_OK (power good signal) ───────────┤
│ │
└─────────────────────────────────────────────┘
 │ │ │ │ │ │
 ▼ ▼ ▼ ▼ ▼ ▼
 To Motherboard (24-pin ATX connector)

The Supervisory Controller is the brain of the PSU. When it sees PS_ON# go LOW, it initiates a carefully orchestrated power-up sequence:

1. Soft-start circuit engages: This slowly ramps up the input capacitors to prevent a huge inrush current that could trip breakers or damage components
2. Primary switching begins: The main power transistors start switching at high frequency (typically 50-150 kHz) to convert AC to DC
3. Voltage regulation stabilizes: Feedback circuits ensure each rail reaches its target voltage (+3.3V, +5V, +12V, etc.)
4. Output monitoring: The controller checks that all voltages are within specification (typically ±5%)

This whole process takes about 100-500 milliseconds. The PSU is doing a LOT of internal self-checks during this time.

The Power Good Signal (PWR_OK)

Here's a critical detail that many people miss: even after the PSU has started producing power on all its rails, it doesn't immediately let the motherboard boot. Instead, it waits until ALL voltages are stable and within specification, then it sends a signal called PWR_OK (or sometimes PG for "Power Good") to the motherboard.

PWR_OK is a +5V signal that tells the motherboard: "All power rails are stable, you're clear to boot."

This signal typically goes HIGH about 100-500ms after PS_ON# goes LOW. This delay is crucial because if the motherboard tried to boot while voltages were still ramping up or unstable, you could corrupt data, damage components, or at minimum cause very weird behavior.

The PWR_OK signal is connected to the motherboard's Platform Controller Hub (PCH) or Chipset, which is responsible for the next stage of the boot process.

The Motherboard Wakes Up

Now we're getting to the really interesting part. The PWR_OK signal has arrived at the motherboard, and the chipset springs into action. But before we dive into what the chipset does, let's understand what's actually powered on the motherboard at this point.

Power Distribution on the Motherboard

The 24-pin ATX connector delivers multiple voltage rails to the motherboard:

24-Pin ATX Connector Pinout:
┌────────────────────────────────┐
│ +3.3V │ +3.3V │ GND │ +5V │
│ GND │ +5V │ GND │ PWR_OK │
│ +5VSB │ +12V │ +12V │ +3.3V │
│ GND │ PS_ON#│ GND │ GND │
│ GND │ GND │ GND │ -12V │
│ +3.3V │ +5V │ GND │ +5V │
└────────────────────────────────┘

Most components on the motherboard don't run directly on these voltages. The CPU, for example, typically operates at around 1.0-1.4V depending on the model. The memory runs at 1.2V or 1.35V. So where do these lower voltages come from?

Voltage Regulator Modules (VRMs)

The motherboard has multiple Voltage Regulator Modules (VRMs) that convert the PSU's output voltages to the precise voltages needed by various components. The most important VRMs are:

1. CPU VRM: Typically converts +12V to 1.0-1.4V for the CPU, capable of delivering 100-300+ amps
2. DRAM VRM: Converts to 1.2V or 1.35V for DDR4/DDR5 memory
3. PCH VRM: Powers the chipset itself
4. PCIe VRMs: Power PCIe slots

Here's a simplified view of a CPU VRM:

+12V from PSU
 │
 ▼
┌─────────────────────────────────┐
│ CPU VRM (Multiphase) │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Phase│ │Phase│ │Phase│ │
│ │ 1 │ │ 2 │ │ 3 │ ...│
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ └────────┴────────┴─────────┤
│ │ │
│ ┌───────▼───────┐ │
│ │ PWM │ │
│ │ Controller │◄─────────┤ VID from CPU
│ │ (ISL69269, │ │
│ │ IR35201, │ │
│ │ etc.) │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────┘
 │
 ▼
 VCORE (1.0-1.4V) to CPU

Each "phase" is essentially a small switching power supply (buck converter) that chops the +12V input at very high frequency (300-1000 kHz) to produce the lower voltage. Multiple phases work in parallel to share the load and reduce ripple.

The PWM (Pulse Width Modulation) Controller coordinates all the phases and adjusts the output voltage based on VID (Voltage Identification) signals from the CPU, which tell it exactly what voltage the CPU needs at any given moment.

But here's the key: these VRMs don't just turn on immediately when PWR_OK arrives. There's a carefully orchestrated power sequencing that must occur.

Power Sequencing: The Critical Dance

Different components on the motherboard need to power up in a specific order. If you power things up in the wrong order, you can damage components or cause the system to fail to boot. This sequencing is managed by a chip called the Super I/O chip or the Embedded Controller (EC) on laptops.

Here's a typical power-up sequence:

Timeline: Power-On Sequence
═════════════════════════════════════════════════════════════

T=0ms: PS_ON# goes LOW (button pressed)
 │
 ▼
T=100ms: PSU voltages stabilize
 │
 ▼
T=100ms: PWR_OK goes HIGH
 │
 ▼
T=120ms: PCH receives power (1.05V rail)
 │
 ▼
T=150ms: PCH starts internal initialization
 │
 ▼
T=200ms: DRAM VRM enabled (1.2V/1.35V)
 │
 ▼
T=220ms: Memory receives power
 │
 ▼
T=250ms: CPU VRM enabled (VCORE)
 │
 ▼
T=280ms: CPU receives power
 │
 ▼
T=300ms: RESET# signal released
 │
 ▼
T=300ms: CPU exits RESET state
 │
 ▼
T=300ms+: CPU begins execution (Real Mode)
 │
 ▼
T=301ms: First instruction fetch from 0xFFFFFFF0

Let's break down what's happening at each stage:

Stage 1: PCH Initialization

The Platform Controller Hub (PCH) is essentially the motherboard's traffic controller. It manages communication between the CPU, memory, storage, USB devices, audio, network, and pretty much everything else.

When the PCH receives power and the PWR_OK signal, it:

1. Performs an internal self-test
2. Initializes its internal clock generators
3. Configures basic I/O routing
4. Prepares to communicate with the CPU

The PCH runs its own firmware stored in an internal ROM or external SPI flash chip.

Stage 2: Memory Power-Up

DDR memory is sensitive to power sequencing. The JEDEC specification (the standard for memory) requires that certain voltages come up in a specific order:

Memory Power Sequencing:
━━━━━━━━━━━━━━━━━━━━━━━━━
 VDD ─────────┐
 │
 VDDQ ─────────┤
 ├───► VPP
 │
 VTT ─────────┘

Must rise together or in this order

• VDD: Core voltage (1.2V for DDR4, 1.1V for DDR5)
• VDDQ: I/O voltage (1.2V)
• VTT: Termination voltage (VDD/2)
• VPP: Activation voltage (2.5V)

If these don't come up in the right order or with proper timing, the memory can latch up (basically short circuit internally) and be damaged.

Stage 3: CPU Power-Up

Finally, it's time to wake up the CPU. The CPU VRM receives an enable signal and begins producing VCORE (the CPU core voltage). But the CPU doesn't start executing immediately - it's held in RESET.

The RESET Signal

Every CPU has a RESET# pin (again, the # means active-low). When this pin is LOW, the CPU is held in a known state:

• All internal registers are cleared
• Instruction pipeline is flushed
• Cache is invalidated
• The CPU waits, frozen in time

The PCH holds the CPU's RESET# pin LOW until:

1. All power rails are stable
2. The PCH has completed its initialization
3. A minimum reset duration has elapsed (typically 1ms)
4. Clock generators are stable and providing clean clock signals

Then, and only then, the RESET# signal goes HIGH, and the CPU is allowed to begin executing.

CPU Boot: The First Instruction

Here's where things get really cool. When the RESET# signal is released, the CPU immediately does something very specific and predictable: it fetches an instruction from a predefined memory address.

But first, we need to understand something fundamental: What is this "4GB address space" everyone keeps talking about?

Understanding the Address Space: It's Not All RAM!

When we say a 32-bit CPU has a "4GB address space," we're NOT saying you have 4GB of RAM. The address space is more like a giant map of numbered mailboxes that the CPU can send requests to. Each mailbox has a unique number (an address) from 0x00000000 to 0xFFFFFFFF (0 to 4,294,967,295 in decimal - that's 4GB).

Here's the key insight: Not all of these mailboxes lead to RAM! Some lead to:

• Your system RAM (the memory sticks)
• Graphics card memory (VRAM)
• USB controllers
• Network card buffers
• And importantly: the firmware chip (BIOS/UEFI)

Think of it like a city where not every address is a house. Some addresses are shops, some are parks, some are government buildings. The CPU doesn't know or care what's at each address—it just sends read/write requests to addresses, and something else (the PCH) decides where to route that request.

The 4GB "Address Space" - Like a City Map:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Address What's Actually There?
─────── ──────────────────────
0xFFFFFFFF ┐
 │ Firmware Chip (BIOS/UEFI)
 │ - Not RAM!
0xFF000000 ┘ - A flash memory chip on motherboard
 ┐
 │ Memory-Mapped I/O
 │ - Graphics card, USB, PCIe devices
0xC0000000 ┘ - Not RAM!
 ┐
 │
 │ RAM (Your Memory Sticks)
 │ - This is actual system memory
 │ - Varies: 4GB, 8GB, 16GB, 32GB, etc.
0x00100000 ┘
 ┐ Legacy regions (640KB to 1MB)
0x000A0000 ┘ - Video memory, BIOS shadow
 ┐
 │ Conventional Memory (RAM)
0x00000000 ┘ - First 640KB, also system RAM

Real Mode: The CPU's Power-On State

When an x86 CPU (Intel or AMD) powers on, it starts in what's called Real Mode. This is a compatibility mode that emulates the original 8086 processor from 1978. In Real Mode:

• The CPU can only directly address 1 MB of memory (20-bit addressing)
• No memory protection (any code can access any memory)
• No virtual memory
• 16-bit registers and operations
• Segmented memory model

You might be thinking: "Wait, my CPU is a 64-bit beast with 16 cores and can address terabytes of memory. Why is it pretending to be a 40-year-old chip?"

The answer is backwards compatibility. The x86 architecture has maintained compatibility all the way back to the 8086, which means every x86 CPU must be able to run software written for that ancient processor. Later in the boot process, the CPU will switch to Protected Mode (32-bit) and eventually Long Mode (64-bit), but it always starts in Real Mode.

The Reset Vector: 0xFFFFFFF0

When the CPU exits reset, its instruction pointer (the register that points to the next instruction to execute) is set to a very specific address: 0xFFFFFFF0.

Wait, didn't I just say Real Mode can only address 1 MB (0x00000 to 0xFFFFF)? How can we access 0xFFFFFFF0, which is way up at the 4 GB mark?

Good catch. Here's what's actually happening:

In Real Mode, the CPU uses a segmented memory model with two components:

• Segment: A 16-bit base address
• Offset: A 16-bit offset from that base

The physical address is calculated as: Physical Address = (Segment × 16) + Offset

At reset, the CPU's registers are initialized to specific values:

• CS (Code Segment): 0xF000
• IP (Instruction Pointer): 0xFFF0

So normally, the physical address would be: (0xF000 × 16) + 0xFFF0 = 0xF0000 + 0xFFF0 = 0xFFFF0

But wait, that's still only 1 MB. Here's the trick: on the first instruction fetch after reset, the CPU actually has a hidden internal register (called a shadow or descriptor cache) where the CS segment base is set to 0xFFFF0000, not 0xF0000. This allows it to fetch from 0xFFFFFFF0 in the full 4 GB address space. After the first instruction, it reverts to normal Real Mode behavior.

This address 0xFFFFFFF0 is exactly 16 bytes below the 4 GB boundary. It's called the Reset Vector.

What's at the Reset Vector? How the CPU Reads This Address

So what lives at address 0xFFFFFFF0? How does the CPU know what instruction to execute? And more importantly: how does the CPU actually access this address?

Let's break this down step by step, like following a letter from sender to recipient.

Step 1: The CPU Wants to Read Memory

When the CPU exits reset and wants to fetch the instruction at 0xFFFFFFF0, it doesn't directly reach into RAM or a chip. Instead, it puts a request on the memory bus. Think of the memory bus as the CPU's postal system.

The CPU has physical pins (tiny metal connectors) organized into groups:

• Address Bus (32 pins for a 32-bit CPU): These pins output the address the CPU wants to read from
• Data Bus (64 pins on modern CPUs): These pins receive the data back
• Control Bus (various pins): These tell other components "I want to READ" vs "I want to WRITE"

The CPU's Request on the Bus:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 CPU
 │
 ├──► Address Bus (32 wires)
 │ Sets each wire to HIGH (1) or LOW (0)
 │ to represent address: 0xFFFFFFF0
 │ 
 │ Wire 31: 1 ┐
 │ Wire 30: 1 │
 │ Wire 29: 1 │ These form the
 │ Wire 28: 1 │ binary number
 │ ... │ 11111111111111111111111111110000
 │ Wire 3: 0 │ which equals 0xFFFFFFF0
 │ Wire 2: 0 │
 │ Wire 1: 0 │
 │ Wire 0: 0 ┘
 │
 ├──► Control Bus
 │ READ signal: HIGH
 │ WRITE signal: LOW
 │ M/IO#: HIGH (accessing Memory, not I/O port)
 │
 └──► Data Bus (waiting to receive data)
 Currently in "listening" mode

The CPU literally energizes specific wires with voltage (+3.3V or +5V = 1, 0V = 0) to transmit the address. It's pure electrical signals on physical copper traces on the motherboard!

Step 2: The PCH Sees This Request

The memory bus connects to the PCH (Platform Controller Hub), which is a large chip on the motherboard that acts as the "post office sorting facility." The PCH is constantly monitoring the memory bus, watching for read/write requests from the CPU.

When the PCH sees address 0xFFFFFFF0 appear on the address bus, it has an internal address decoder (just a bunch of logic gates) that asks:

PCH's Decision Process:
━━━━━━━━━━━━━━━━━━━━━━━

Address received: 0xFFFFFFF0

Is it in range 0x00000000 - 0x0009FFFF? NO → Not conventional RAM
Is it in range 0x000A0000 - 0x000FFFFF? NO → Not legacy video/ROM area
Is it in range 0x00100000 - 0xBFFFFFFF? NO → Not extended RAM
Is it in range 0xC0000000 - 0xFEFFFFFF? NO → Not PCIe/Memory-mapped I/O
Is it in range 0xFF000000 - 0xFFFFFFFF? YES → This is FIRMWARE territory!

Decision: Route this request to the SPI Flash Controller

This decision happens in hardware logic gates - no software involved! It's pure electronics comparing voltage levels to predetermined ranges. The PCH was designed (at the factory) to know "addresses above 0xFF000000 mean firmware."

Step 3: The SPI Controller Accesses the Flash Chip

The PCH has a built-in SPI (Serial Peripheral Interface) controller that knows how to talk to the firmware flash chip. This is a separate physical chip on your motherboard—you can actually see it if you look closely! It's usually an 8-pin chip labeled something like "Winbond 25Q128" or "Macronix MX25L".

Physical Connection:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Motherboard:
 ┌──────────┐
 │ PCH │
 │ │
 │ [SPI │
 │ CTRL] │
 └────┬─────┘
 │ SPI Bus (4 wires)
 │ CLK (clock signal)
 │ MOSI (data out)
 │ MISO (data in)
 │ CS# (chip select)
 │
 ┌────┴─────┐
 │ Flash │
 │ Memory │ ← Physical chip!
 │ Chip │ 8-32 MB
 │ (8-pin) │ Non-volatile
 └──────────┘ (keeps data when power off)

The SPI controller converts the memory read request into an SPI command:

SPI Transaction:
━━━━━━━━━━━━━━━━━━━━━━━

1. PCH activates CS# (Chip Select) - tells flash "I'm talking to you"
2. PCH sends command byte: 0x03 (READ command in SPI protocol)
3. PCH sends 3 address bytes: 0xFF 0xFF 0xF0
 (note: the flash chip uses its own internal addressing)
4. Flash chip responds by sending data bytes back
5. PCH receives: EA 5B E0 00 F0 (the instruction at that address!)
6. PCH deactivates CS#

This takes about 400-500 nanoseconds (the SPI bus runs at ~50-100 MHz).

Step 4: Data Returns to the CPU

The PCH takes the data it received from the flash chip (EA 5B E0 00 F0) and puts it on the data bus for the CPU to read:

Data Bus Response:
━━━━━━━━━━━━━━━━━━━━━━━

 PCH
 │
 └──► Data Bus (64 wires to CPU)
 
 Wire 7-0: 11101010 (0xEA) ← First byte
 Wire 15-8: 01011011 (0x5B) ← Second byte
 Wire 23-16: 11100000 (0xE0) ← Third byte
 Wire 31-24: 00000000 (0x00) ← Fourth byte
 Wire 39-32: 11110000 (0xF0) ← Fifth byte
 
 CPU reads these voltages and interprets
 them as the instruction: JMP FAR

The CPU's front-end (instruction fetch unit) receives these bytes, stores them in the instruction queue, and passes them to the decode unit.

Step 5: What the CPU Received

So the answer is: firmware. Specifically, the motherboard's firmware (BIOS or UEFI) is stored in that flash memory chip, and the PCH makes it appear as if that chip exists at address 0xFFFFFFF0 in the CPU's address space.

This is called memory mapping - making non-RAM devices accessible through memory addresses.

Memory Map at Power-On:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What the CPU Sees What's ACTUALLY There
───────────────── ─────────────────────

0xFFFFFFFF ┌─────────────────────────┐
 │ │
 │ Firmware "Memory" │ ← Not real memory!
 │ (BIOS/UEFI Flash) │ It's a chip on SPI bus
 │ │ PCH routes requests here
0xFFFF0000 │ ◄── Reset Vector @ │
 │ 0xFFFFFFF0 │
 ├─────────────────────────┤
 │ │
 │ (Memory Hole) │
 │ Not Mapped │
 │ │
 ├─────────────────────────┤
0x000FFFFF │ Extended BIOS Area │
0x000F0000 ├─────────────────────────┤
 │ Video RAM │
0x000A0000 ├─────────────────────────┤
 │ │
 │ Conventional Memory │
 │ (RAM) │
 │ │
0x00000000 └─────────────────────────┘

The firmware is stored in a SPI flash chip (typically 8-32 MB in size) on the motherboard. The PCH has a built-in SPI controller that reads from this flash chip and presents it to the CPU as memory at the high addresses.

At address 0xFFFFFFF0, there's always a jump instruction (JMP) that redirects execution to the actual start of the firmware code, which lives somewhere else in the ROM. There's only room for a 16-byte instruction at the reset vector (since we're only 16 bytes from the 4 GB boundary), so it's always just a jump.

A typical instruction might be:

JMPF F000:E05B ; Far jump to segment F000, offset E05B

Or in machine code:

EA 5B E0 00 F0 ; JMPF opcode followed by offset:segment

The First Few Microseconds

Let's trace through exactly what happens in those first few microseconds after RESET# is released:

CPU Execution Timeline:
═══════════════════════════════════════════════════════════════

T=0ns: RESET# released
 │
 ├─► CPU internal state initialized:
 │ • CS = 0xF000 (base = 0xFFFF0000 hidden)
 │ • IP = 0xFFF0
 │ • All other registers = 0
 │ • Flags = 0x0002
 │ • Real Mode enabled
 │
T=10ns: CPU requests instruction fetch from 0xFFFFFFF0
 │
 ├─► Address sent to memory bus
 │ • Memory request propagates to PCH
 │ • PCH routes to SPI controller
 │
T=100ns: SPI controller reads from flash chip
 │
 ├─► SPI clock cycles out (typical SPI: 50 MHz)
 │ • Command byte: 0x03 (READ)
 │ • Address bytes: 0xFF 0xFF 0xF0
 │ • Data clocked back from flash
 │
T=500ns: Data returns to CPU
 │
 ├─► CPU receives: EA 5B E0 00 F0
 │ (Far jump instruction)
 │
T=510ns: CPU decodes instruction
 │
 ├─► Instruction: JMPF 0xF000:0xE05B
 │ • CS loaded with 0xF000 (base now 0xF0000)
 │ • IP loaded with 0xE05B
 │ • Physical address: 0xFE05B
 │
T=520ns: Next instruction fetch from 0xFE05B
 │
 ▼
 Firmware initialization code begins...

And just like that, your CPU has executed its first instruction and jumped to the firmware!

Power-On Self-Test (POST) Begins

Once the CPU has jumped into the firmware code, the Power-On Self-Test (POST) begins. This is the firmware's job, not the CPU's, but I'll give you a quick overview since it's part of the boot sequence.

POST is a series of diagnostic tests that verify hardware is working:

1. CPU self-test: Verify CPU registers and basic operations
2. Memory test: Check that RAM is responding (usually just a quick test, not the full memory)
3. Keyboard controller: Initialize the keyboard interface
4. Video initialization: Set up basic video output so errors can be displayed
5. Device enumeration: Discover what hardware is connected (storage, PCIe devices, USB, etc.)

During POST, the firmware communicates status through:

• POST codes: Two-digit hex codes sent to I/O port 0x80 (readable with a POST code card)
• Beep codes: Sequences of beeps for different errors (remember those?)
• Screen output: Text messages once video is initialized

A typical POST sequence might send these codes:

POST Code Sequence:
───────────────────
0x01 - CPU test
0x02 - Verify real mode
0x03 - Disable NMI
0x04 - Test chipset
0x05 - Initialize keyboard
0x08 - Initialize video
0x0B - Test memory
0x0E - Test cache
...
0xFF - Ready to boot OS

Memory Initialization: The Most Complex Part

One of the most time-consuming parts of the boot process is memory training. Modern DDR4 and DDR5 memory requires extensive calibration to achieve high speeds.

The firmware must:

1. Read SPD data: Each memory stick has a SPD (Serial Presence Detect) chip that stores timing information
2. Configure timings: Set CAS latency, RAS-to-CAS delay, refresh rate, etc.
3. Train the memory bus: Adjust signal timing to compensate for PCB trace lengths and impedance
4. Test signal integrity: Run eye diagram tests to verify data is being read correctly

This process involves thousands of read/write cycles with different voltage and timing settings to find the optimal configuration. It's why your computer takes a few seconds to boot even before you see anything on screen.

The Transition to Protected Mode

Eventually, the firmware needs to switch the CPU from Real Mode to Protected Mode (or Long Mode for 64-bit). This involves:

1. Setting up the GDT (Global Descriptor Table): Defines memory segments for protected mode
2. Enabling the A20 line: Allows addressing beyond 1 MB (legacy compatibility thing)
3. Setting the PE bit in CR0: Control Register 0, bit 0 enables Protected Mode
4. Far jump to flush pipeline: Loads new code segment and switches mode

The actual instruction sequence looks like:

; Load GDT
lgdt [gdt_descriptor]
 
; Enable protected mode (set PE bit in CR0)
mov eax, cr0
or eax, 1
mov cr0, eax
 
; Far jump to load CS and enter protected mode
jmp 0x08:protected_mode_start

Once in Protected Mode, the CPU has:

• 32-bit addressing (4 GB address space)
• Memory protection
• Virtual memory support via paging
• Privilege levels (Ring 0-3)

Modern 64-bit systems eventually switch again to Long Mode, which enables:

• 64-bit addressing (theoretically 16 EB, practically 256 TB with current CPUs)
• 64-bit registers (RAX, RBX, etc.)
• More registers (R8-R15)
• Additional features like NX bit for security

Summary: The Journey So Far

Let's recap the incredible journey we've traced:

1. Mechanical switch closes → Signal sent to PSU
2. PSU receives PS_ON# → Begins power-up sequence
3. PSU stabilizes voltages → Sends PWR_OK to motherboard
4. Motherboard sequences power → PCH, memory, and CPU powered in order
5. RESET# released → CPU exits reset state
6. CPU fetches from 0xFFFFFFF0 → Reads jump instruction from firmware
7. Jump to firmware code → POST begins
8. POST tests hardware → Memory initialized, devices enumerated
9. Mode transitions → Real Mode → Protected Mode → Long Mode

And all of this happens in less than a second, typically around 300-500 milliseconds from button press to firmware execution, and a few more seconds for POST and memory training.

What's Next?

In the next part of this series, we'll follow the boot process through the firmware (BIOS/UEFI), watch it load the bootloader from disk, see how the bootloader loads the kernel, and eventually watch the operating system initialize all the way to displaying the login screen.

We'll cover:

• UEFI Secure Boot and how it verifies the bootloader
• The bootloader (GRUB or Windows Boot Manager)
• Kernel decompression and relocation
• Driver initialization
• Init system startup (systemd/init)
• Display manager and login screen

There's so much more to explore, and we've only scratched the surface!

Going Deeper: References and Further Reading

If you want to dive even deeper into these topics, here are some excellent resources:

Specifications and Standards:

• ATX Power Supply Design Guide - Intel's official spec
• JEDEC DDR4 Specification - Memory standards
• Intel 64 and IA-32 Architectures Software Developer's Manual - The CPU bible
• UEFI Specification - Modern firmware standard

Books:

• "Computer Organization and Design" by Patterson and Hennessy - Computer architecture fundamentals
• "Understanding the Linux Kernel" by Bovet and Cesati - Goes into boot process details
• "Modern Operating Systems" by Andrew Tanenbaum - OS fundamentals including boot

Online Resources:

• OSDev Wiki - Community wiki for OS development, excellent boot process documentation
• Coreboot Documentation - Open-source firmware project with detailed docs
• PCIe Base Specification - PCI Express specs

Videos and Courses:

• Ben Eater's YouTube channel - Excellent hardware fundamentals
• "Computer Architecture" course on Coursera

Closing Thoughts

I hope this post has given you a newfound appreciation for what happens in those first few hundred milliseconds after you press that power button. It's easy to take for granted, but there's an incredible amount of engineering that goes into making this process reliable, fast, and safe.

The coordination between the mechanical switch, power supply, motherboard, chipset, and CPU is a carefully choreographed dance that happens millions of times a day across billions of computers worldwide. And when you think about the fact that all of this has to work perfectly every single time (or your computer won't boot), it's pretty impressive.

Next time you press that power button, take a moment to appreciate the hardware symphony that's about to unfold. From mechanical switch closure to firmware execution in under a second - that's pretty damn cool.

Stay curious, keep learning, and I'll see you in Part 2!

Got questions or found an error? Feel free to reach out. And if you built something cool based on this knowledge, I'd love to hear about it!