What Is the Reset Vector?

Explains the reset vector in firmware, where the CPU starts after reset, and how to debug the earliest boot code.

October 28, 2025 Updated June 19, 2026 3 min read

The reset vector is the first address the CPU executes after reset. In firmware, it is the very early entry point before SEC, before PEI, before memory initialization, and before normal UEFI services exist.

In short: the reset vector is where the CPU wakes up and enters firmware.

On traditional x86 systems, the CPU starts near the top of the physical address space. Firmware then uses a small reset stub to jump into the real early initialization code.

Reset
  -> CPU fetches instruction at the reset vector
  -> reset stub runs
  -> minimal CPU state is prepared
  -> control jumps to SEC / early firmware entry

The reset vector is not BIOS main

A common mistake when reading firmware is to treat the reset vector as the BIOS “main function”. In practice, the reset vector is usually a very small piece of code that moves the CPU from reset state into a more structured firmware path.

At this point, you usually do not have:

stable DRAM
UEFI Boot Services
protocol database
normal heap or pool
complete logging
full C runtime

So reset vector code must be very conservative. It cannot assume that memory, stack, serial output, or normal libraries are already available.

What does the reset stub do?

Depending on the architecture and platform, the reset stub may:

set up a minimal CPU mode
set up a temporary stack or temporary storage
jump from the reset address into the real firmware volume
prepare the SEC entry
handle reset type or bootstrap processor state
set very early microcode or chipset state when needed

The key point is that the reset vector is only the entrance. Most firmware logic lives in later phases.

Why is it hard to debug?

Logging is very limited at this stage. Serial may not be initialized, DRAM may not exist, and exception handling may not be ready. If the failure happens here, the external symptom is often no log, no PEI entry, or a very early reset loop.

Typical signs include:

no first serial log
no PEI memory initialization log
debugger never reaches familiar symbols
board resets repeatedly very early
emulator stops around the reset address

The important question is whether the CPU cannot fetch code at all, or it fetches code but jumps to the wrong place.

Relationship with the firmware image

The reset vector must point to valid code in the firmware image. If FDF layout, flash descriptor, BIOS region mapping, or reset vector placement is wrong, the CPU may fetch garbage. This is why early boot debugging needs both source code and binary layout checks.

Check these points:

Is the reset vector placed at the expected image offset?
Is the BIOS region mapped correctly?
Does the FV that contains reset/SEC code sit in the right location?
Does flash read return valid data?
Is the jump target address correct?

Source-reading checklist

When reading the reset vector path, check:

1. Where is the assembly reset stub?
2. Where does FDF or image layout place the reset code?
3. Which physical address does the CPU start from after reset?
4. Which symbol does the reset stub jump to?
5. How is stack or temporary storage handled?
6. Is there any accidental dependency on DRAM?
7. At which point is the first serial log enabled?
8. Does control reach the SEC entry?

Conclusion

The reset vector is the real starting point of the firmware execution flow. When there is no log, no PEI entry, or a very early reset loop, reset vector and reset stub code should be checked first. Understanding this area prevents you from debugging DXE or BDS while the bug is still in the first few instructions after reset.