lspci for Firmware Debug

How to read lspci output as a firmware engineer when debugging PCI enumeration, BAR assignment, bridge routing, and driver binding.

2 min read
Shell & Firmware Tools cover

A PCIe device does not appear in the OS.

Before debugging the driver, ask a simpler question:

Did the OS enumerate the device at all?

lspci is often the fastest answer on Linux.

lspci
lspci -nn
lspci -vv
lspci -xxxx -s 00:1f.0

What firmware engineers should read

Item Value Note
BDF Bus:Device.Function Shows where the device exists in PCI topology.
Vendor ID / Device ID Device identity Useful for driver binding and silicon identification.
Command Register Decode enable bits Memory Space, I/O Space, and Bus Master must match expected device use.
BARs Assigned resources Shows MMIO or I/O windows assigned by firmware/OS.
Capabilities PCIe/MSI/MSI-X/PM Useful for power, interrupt, and link feature debugging.
Kernel driver Driver binding Shows whether OS has attached a driver after enumeration.

Real world example: device exists but driver does not bind

lspci -nn
03:00.0 Network controller [0280]: Intel Corporation Device [8086:2725]

If the device appears with correct Vendor ID / Device ID, the issue is probably not basic PCI enumeration. Move toward driver ID table, ACPI companion device, firmware configuration, power state, or missing resources.

Real world example: device missing entirely

If the expected endpoint is absent:

Check reset GPIO
Check power rail
Check reference clock
Check PCIe link training
Check root port enable policy
Check bifurcation / lane routing
Check firmware setup option

This connects lspci directly to board and BIOS policy.

Found this useful?

Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.