A Guide to Submitting Firmware-Focused Engineering Change Requests
At PCI-SIG, we take pride in ensuring that our specifications operate without a hitch. However, sometimes PCI Express developers need to submit Engineering Change Requests (ECRs) to update parts of the specification so that PCIe integrated products can reach their optimal functionality. ECRs allow all of our 800 members to actively contribute to the design process and help reduce the amount of work between specification revisions.
Developers have expressed confusion in knowing where they should go to submit ECRs related to firmware. Understanding the history behind the various PCI Firmware specifications and how they integrate with other standards bodies is a critical first step.
A Brief History of PCI Firmware Specifications
The original issue of the PCI BIOS Specification was released in late 1992 and it remained stable for more than ten years as v2.1 or the “Traditional PCI BIOS.” Around the time that PCI technology evolved into PCI-X and PCIe, The UEFI Forum created the Unified Extensible Firmware Interface (UEFI) specification; it emerged as the new boot model to replace the traditional BIOS. In their specification, the UEFI community defined PCI related boot services and integrated support of PCI, PCI-X and PCIe during the boot process. Since the UEFI Forum adopted the PCI related boot services, the PCI Firmware Specification only provides a short overview of the UEFI PCI Services that define the device state at firmware/OS handoff.
Concurrently, the Advanced Configuration and Power Interface (ACPI) specification, was developed for interfaces important for power management features and for system configuration. Many of the descriptions needed to define PCI for desktops and servers were developed on the side and eventually merged into the PCI Firmware Specification. The ACPI specification—now hosted by the UEFI Forum—provides the mechanism to report the Enhanced PCI Configuration Space, system wake from PCIe, PCI root bridge descriptions, PCI interrupt routing, _OSC/_DSM interfaces for PCI specific features and the PCI hot plug support.
It was not until 2005 that PCI-SIG decided a new PCI Firmware Specification should be published to include the UEFI and ACPI interfaces required to support PCI, PCI-X and PCIe. At the time, a decision was also made to pull the PCI Expansion ROM definitions from the main PCI Specification to the PCI Firmware Specification. For historical reasons, there were references and examples in the ACPI Specification that overlap the PCI Firmware Specification content. Efforts have been made to remove the duplications in the ACPI Specification (see ACPI Specification v6.3). At the end of the day, the PCI Firmware Specification is where these ACPI interfaces are defined.
Where to Submit Firmware Related ECRs
The firmware interfaces needed to support PCI related technologies are spread across a number of specifications owned by outside industry standards bodies. By understanding the ownership and history of these various items, submitting ECRs becomes a significantly easier task.
The primary areas for the PCI related firmware interfaces are:
- UEFI Specification for boot services
- PCI Firmware Specification Section 4 for ACPI interfaces
- PCI Firmware Specification Section 5 for PCI Expansion ROMs
If changes are needed for the first area, ECRs should be filed in the UEFI Forum against the UEFI Specification here. If changes are needed for the latter two areas, come to the PCI Firmware Work Group to file ECRs against the PCI Firmware Specification.
You can safely ignore the Traditional PCI BIOS (Section 2) and the PCI Services specific to DIG-64-Compliant Systems (Section 6) of the PCI Firmware Specification, as they were kept there for historical records.
If you still find references and examples in the ACPI Specification that overlap the PCI Firmware Specification, please submit ECRs to remove them in the UEFI Forum against the ACPI Specification here.
If you have other questions about submitting ECRs, contact the PCI-SIG Firmware Work Group at firstname.lastname@example.org.