PCIe Option ROMs Explained: What Expansion Cards Load Before Windows

A PCI or PCI Express Option ROM is a firmware image associated with a PCI device that can provide code for use before the operating system takes control. The name is historical: on modern UEFI systems, the relevant image can contain a UEFI driver rather than only the legacy x86 code people often associate with “Option ROM.” The purpose is pre-boot device support, not a replacement for the normal Windows or Linux driver.

The UEFI specification explicitly allows PCI Option ROMs to contain one or more images and supports legacy images, UEFI driver images for different processor architectures, or combinations of legacy and UEFI images. A platform can therefore discover an add-in device during PCI enumeration and, when appropriate, load compatible pre-boot code that helps firmware use that device before an OS driver exists.

A motherboard does not need to execute an Option ROM merely to know that a PCIe device exists. PCI enumeration identifies functions and resources through the PCI configuration mechanism. Option-ROM handling comes afterward as a firmware policy and driver-loading question. This distinction matters when troubleshooting: a card can enumerate correctly yet lack the pre-boot support needed for a particular firmware task.

UEFI specifies that its PCI bus driver scans a discovered PCI Option ROM for UEFI driver images after PCI enumeration. Compatible images can then be loaded through UEFI Boot Services. That is more specific than saying the firmware simply “runs the card BIOS”: modern UEFI has a defined driver model, image format, processor binding, loading process, and platform policy around those images.

The transition from legacy PC firmware to UEFI did not require every expansion card to choose one world permanently. The UEFI specification defines an Option ROM format that can coexist with legacy PCI expansion ROM images, and a single PCI Option ROM can contain both a legacy image and one or more UEFI drivers. This allowed add-in cards to support older systems while also exposing native UEFI pre-boot functionality.

A UEFI driver image is not just the old legacy code under a new label. UEFI PCI device drivers use the UEFI driver model and PE/COFF image format, and the firmware loads appropriate images into system memory. The Option ROM is one possible storage location for such a driver; UEFI documentation also makes clear that a PCI device driver should not depend on being stored on the card itself.

Option-ROM support is useful when firmware needs device-specific functionality before the OS starts, but many PCIe devices need no such pre-boot feature. A device can be perfectly usable once Windows or Linux loads its driver even if the platform has no reason to load device-provided pre-boot code for it.

The UEFI Platform Initialization specification even defines a platform mechanism that can supply an Option ROM image from a platform-specific location instead of the physical card. It explicitly allows the result “no option ROM was available for this device.” That is why the presence of a PCIe device and the presence of an Option ROM should never be treated as equivalent facts.

Network adapters illustrate the difference well. Intel documents PCI Option ROM programming on supported PCI and PCIe Ethernet adapters and exposes Boot Agent-related configuration through its BootUtil utility. That firmware capability can support pre-boot network behavior, while the ordinary Ethernet driver used by an installed operating system is a separate software layer.

Storage controllers and graphics adapters can have similar pre-boot requirements. Firmware may need a suitable driver to expose a storage device as a boot path or to initialize a display path before the OS graphics stack loads. An operating system can still support hardware that the firmware cannot use for a particular pre-boot purpose, and the reverse is also possible if the OS lacks an appropriate driver.

The Compatibility Support Module, when a platform provides one, exists to support legacy BIOS-style behavior inside a UEFI firmware environment. A card whose pre-boot support depends on a legacy Option ROM may therefore behave differently from a card with a native UEFI driver. But that does not make “enable CSM” a safe generic troubleshooting rule.

Changing CSM or boot-mode policy can change which firmware path the system uses and can affect an existing operating-system boot configuration, Secure Boot availability, or other platform features. Modern boards also vary in whether CSM exists at all and how Option-ROM policy is exposed. Use the exact motherboard and expansion-card documentation instead of toggling legacy mode merely because a PCIe device is involved.

A UEFI Option ROM driver is executable pre-boot code, so image trust matters on systems enforcing Secure Boot policy. The UEFI specification ties signed PCI Option ROM driver images into its image-validation rules. A technically valid UEFI driver image is therefore not automatically guaranteed to execute under every platform security configuration.

This is another reason to keep concepts separate. Secure Boot does not perform PCI enumeration, and disabling it does not magically create a missing UEFI driver. Likewise, an Option ROM being present does not mean firmware policy will load every image inside it. Image format, processor architecture, platform support, security policy, and device/firmware configuration all participate in the result.

For most users, Option ROMs matter only when a device must do something before Windows or Linux loads: present a bootable storage path, provide network boot functionality, initialize a graphics path, or expose another firmware-time service. If the device works normally after the OS loads, a lack of some pre-boot feature is not automatically evidence that the card itself is defective.

When a motherboard exposes settings such as PCIe OpROM control, UEFI/Legacy Option ROM policy, or storage/network boot ROM controls, read them as pre-boot firmware policy rather than PCIe performance settings. Intel, for example, documents server firmware with per-port OpROM controls. The exact names and behavior are platform-specific, so the useful diagnostic chain is device enumeration, required pre-boot function, available legacy or UEFI image, firmware policy, security policy, and finally the separate operating-system driver state.