A Base Address Register (BAR) exposes a function’s register or memory aperture to the host. Enumeration discovers the required size/type and assigns a suitably aligned address range. A device’s DMA address is instead established through the platform DMA/IOMMU mapping contract. A BAR value is not a substitute for that mapping.
For an isolated conventional 32-bit memory BAR size exercise, the sizing readback is 0xFFFFF000 after the enumeration sizing operation. Ignore the low four attribute bits for the address mask: two’s-complement of 0xFFFFF000 in 32 bits gives 0x1000, or 4 KiB. This is explanatory enumeration arithmetic, not instructions to probe a live enabled device; 64-bit and I/O BARs require their own rules.
A BAR describes an address window, not a DMA destination — worked trace
Illustrative isolated example; not measured silicon behaviour.
Proposed assignment | Check | Result |
|---|---|---|
Base 0x80000000; size 0x1000 | Base is a multiple of 0x1000 | Window is 0x80000000–0x80000FFF |
Base 0x80000800; same size | Lower address bits violate alignment | Not a valid assignment for this aperture |
Driver wants register +0x20 | Use the OS-assigned resource and its mapping API | Do not assume raw PCI bus and CPU physical addresses are identical |
No. The BAR describes host access to the device aperture. Bus mastering, DMA mappings, permissions and buffer ownership are separate requirements.
For the conventional PCIe scope here, Detect, Polling and Configuration introduce receiver detection, training and lane configuration before L0. This is a successful-path sketch, not the full LTSSM: substates, timers, retries, reset and Recovery behaviour come from the selected generation and Base Specification revision.
For PCIe Gen3 link equalisation, the relevant LTSSM substate is Recovery.Equalization, not simply Configuration. Training exchanges and transmitter/receiver adjustments follow the selected generation's rules; they are not a universal blind BER sweep. Check the actual state history, configured capability and lane evidence before explaining a reduced width or speed.
Read successful milestones without inventing LTSSM edges
Orientation to the conventional PCIe scope, not an exhaustive state-transition diagram. Consult the named Base Specification revision for substates, entry/exit conditions, Recovery and equalisation.
Milestone | Evidence to inspect | What remains |
|---|---|---|
Detect | Receiver-detection evidence | Training has not yet established the operational link |
Polling / training | Training exchanges and lane observations | Complete applicable lane/configuration rules |
Configuration | Negotiated lane configuration | Reach the required operational state |
L0 | Operational link state and negotiated speed/width | Function discovery, BAR resources and driver setup |
What to notice
This table deliberately does not draw a guessed Configuration-to-Recovery transition.
Gen3 equalisation belongs to the selected revision's Recovery.Equalization rules, not a blanket statement that Configuration does all equalisation.
The L0 row still leaves discovery, resource assignment and driver setup. Link readiness is an earlier obligation.
Platform firmware and/or the operating system enumerate the PCIe hierarchy according to platform policy: discover functions, assign bus/resource windows, size and assign BARs, and configure enables. Configuration transactions are themselves communication before normal driver use; the device driver generally depends on completed discovery and resource setup for its operational paths.
BAR assignment maps device memory/IO regions into host address space. Wrong BAR size or alignment causes driver mapping failures.
What each bring-up milestone proves
Milestone | Evidence | Next boundary still to check |
|---|---|---|
Link reaches L0 | Negotiated speed/width and state history | Configuration requests and completions can reach the function. |
Function discovered | Valid configuration reads and capabilities | Resource windows and BAR assignment are usable. |
BAR mapped and register read works | CPU access reaches the endpoint aperture | Device DMA to a separately mapped host buffer is enabled and permitted. |
DMA setup succeeds | DMA address, lifetime, direction, bus-master enable and permissions | Real data and completion behaviour under load. |
No. The BAR is an endpoint aperture used by CPU accesses. Host-directed DMA uses the platform-returned DMA address with a valid mapping, permissions and lifetime; a CPU pointer is not automatically that address.
LTSSM state history is the first debug artifact for link issues.
Reduced width can reflect configured limits, lane connectivity, reset/training conditions or physical margin. Inspect the lane/state evidence before calling it an equalisation failure.
L0 alone does not prove configuration accesses work; check requests, completions, reset, resource assignment and endpoint behaviour.