The CPU has been released from reset. The clock is ticking. Voltages are stable. The processor is now expected to do something -- but what?
A CPU does not know what an operating system is. It does not know about hard drives, keyboards, or screens. It has no awareness of what it is or what it is supposed to do. It knows exactly one thing: an address. A specific, hardwired location in its address space where it must look for its first instruction.
That address is called the reset vector.
What Is an Address Space?
Before we can talk about the reset vector, we need to talk about how a CPU sees memory. The CPU does not interact with physical RAM chips directly by name. Instead, it sees a flat, numbered sequence of memory locations called the address space.
Think of the address space as a very long row of numbered post office boxes. Box 0 is at one end. The last box is at the other. The CPU can read from or write to any box by specifying its number. That number is the address.
On an x86 CPU (the architecture used in most PCs and servers), the address space at power-on is not what you might expect. Not every address maps to RAM. Some addresses map to ROM chips, some map to hardware device registers, and large regions may map to nothing at all.
This mapping of addresses to physical devices is called the memory map, and understanding it is essential to understanding the reset vector.
The Memory Map at Power-On
When an x86 CPU first starts, it operates in a mode called real mode. In real mode, the processor can address 1 MB of memory (addresses 0x00000 through 0xFFFFF). This is a legacy constraint inherited from the original 8086 processor from 1978, and modern CPUs maintain backward compatibility with it.
But the CPU does not start fetching instructions from the bottom of that 1 MB range. It starts from near the top.
The top 64 KB (addresses 0xF0000 to 0xFFFFF) is mapped to a ROM chip -- specifically, the chip that contains the BIOS firmware. Below that are option ROMs (like the video card's built-in firmware), video memory, and then 640 KB of conventional RAM that is mostly empty at this point.
The Reset Vector on x86
On an x86 processor, the reset vector is at address 0xFFFFFFF0 -- sixteen bytes below the 4 GB boundary. Yes, you read that correctly. Even though the CPU is supposedly in real mode (which can only address 1 MB), the very first fetch after reset reaches up to the top of the 32-bit address space.
How is this possible? The answer is a quirk of x86 design. At reset, the CPU sets its code segment (CS) base to 0xFFFF0000, not the usual real-mode value. The instruction pointer (IP) is set to 0xFFF0. The combination gives a physical address of 0xFFFFFFF0. This trick allows the CPU to find the BIOS ROM, which the motherboard's chipset maps to the top of the 4 GB address space.
The first instruction at this address is almost always a jump (JMP) instruction. It jumps to the main body of the BIOS code, which might be at a completely different address. The reset vector is just the entry point -- a signpost that says "go over there to find the real startup code."
Why a Fixed Address?
Why does the CPU need a hardwired starting address? Why not let the user configure it?
The answer is simple: at the moment of reset, there is no configuration. There are no settings. There is no software running to read a configuration file. The CPU needs to start somewhere, and that somewhere must be knowable without any prior setup. A fixed address baked into the silicon is the only practical solution.
Every CPU architecture has its own reset vector:
- x86 (Intel/AMD): 0xFFFFFFF0
- ARM Cortex-A: 0x00000000 (or 0xFFFF0000 with high-vector configuration)
- RISC-V: Implementation-defined, commonly 0x80000000
- MIPS: 0xBFC00000
The address itself is arbitrary -- what matters is that the CPU designer and the board designer agree on it. The CPU will fetch from that address, and the board must ensure that a ROM containing valid code is mapped there.
How the Chipset Makes It Work
The CPU does not physically wire itself to a ROM chip. Between the CPU and any memory or I/O device sits the chipset -- a set of controller chips on the motherboard that routes addresses to the correct physical device.
When the CPU puts the address 0xFFFFFFF0 on its address bus, the chipset sees this address and knows it falls in the range assigned to the BIOS ROM (or, on modern systems, the SPI flash chip that contains the UEFI firmware). The chipset routes the read request to that chip, which responds with the bytes stored at that location.
This mapping is itself hardwired into the chipset. At power-on, the chipset has a default configuration that maps the top of the address space to the firmware flash chip. Later in the boot process, firmware might reconfigure the chipset to remap these regions, but at the instant of the first instruction fetch, the defaults are all that matter.
The CPU's State at Reset
When the reset line is deasserted and the CPU begins execution, its internal state is well-defined. The x86 architecture specifies exact values for every register after reset:
- CS (Code Segment): Base = 0xFFFF0000, selector = 0xF000
- IP (Instruction Pointer): 0xFFF0
- All other segment registers: Selector = 0x0000
- General purpose registers: Most set to 0x0000
- EFLAGS: 0x00000002 (interrupts disabled)
- CR0: 0x60000010 (real mode, cache disabled)
Two things stand out in this list. First, interrupts are disabled. The CPU will not respond to hardware interrupts until firmware explicitly enables them. This makes sense -- the interrupt vector table has not been set up yet, so responding to an interrupt would cause a crash.
Second, the cache is disabled. The CPU will read directly from the ROM chip for every instruction fetch, with no caching. This is slow, but it is safe. Caching requires configuration, and no configuration has happened yet.
No RAM Yet
Here is a detail that surprises many people: at the moment the CPU begins executing, RAM is not working.
Modern DDR memory requires initialization before it can be used. The memory controller needs to know the speed, timing, voltage, and organization of the installed DIMMs. This information is stored on a small chip on each DIMM called the SPD (Serial Presence Detect) EEPROM. The firmware must read the SPD data, configure the memory controller, and train the memory interface before a single byte of RAM is usable.
So the BIOS firmware, executing from the reset vector, must run its first instructions without any RAM. It cannot use a stack (which normally lives in RAM). It cannot store variables in RAM. It can only use CPU registers and execute directly from ROM.
This is one of the most constrained execution environments in all of computing. The firmware must bootstrap itself using only the CPU's internal registers, reading instructions directly from the ROM chip through the chipset, until it has initialized RAM and can begin using memory normally.
Other Architectures
The x86 approach -- reset vector near the top of the address space, jump to BIOS -- is specific to x86. Other architectures handle the reset vector differently.
ARM processors typically start at address 0x00000000, where they expect to find not a single instruction but a vector table -- a series of addresses, each pointing to a handler for a different type of event (reset, undefined instruction, software interrupt, and so on). The first entry in the table is the reset vector.
RISC-V leaves the reset vector as an implementation choice. A RISC-V chip designer can put it anywhere in the address space, as long as the board maps executable firmware there. Common choices are 0x80000000 or 0x20000000.
The concept is the same everywhere: a fixed, known starting address that both the CPU and the board agree on. The specifics differ, but the principle is universal.
From Vector to Firmware
The reset vector is nothing more than a handoff point. It is the hardware saying to the software: "You start here." What happens next -- the Power-On Self Test, hardware initialization, device enumeration -- is all firmware territory.
The CPU has done its part. It woke up, fetched its first instruction from the hardwired address, and began executing. From here, control passes to the code burned into the BIOS or UEFI firmware chip.
That firmware has a lot of work to do. It needs to test the hardware, initialize devices, configure the memory controller, set up the interrupt table, and eventually find a bootable device. All of that starts with the Power-On Self Test.
Next: POST and the BIOS