Recall that the UEFI Forum (www.uefi.org) governs several specifications. The first is the main UEFI specification which serves as the contract between the platform firmware and several pre-OS components. The latter components include pre-OS applications, drivers, OS runtimes. The other specification under the aegis of the UEFI Forum is the platform initialization, or "PI" specifications. These five volumes describe interoperability between components that comprise the construction of the platform firmware, including the Pre-EFI Initiation (PEI) phase and the Driver Execution Environment (DXE). For both the UEFI and PI specifications, major specification releases entail updates to functionality and capabilities. A fortiori, such changes entail updates to the version fields in the various services tables, such as the UEFI System Table for UEFI and the PEI, DXE, and SMM services tables for PI, respectively. These service table revisions allow for software to detect the variant of a given platform firmware in case a certain service has evolved modal behavior or to ascertain if a certain capability exists.
With all that in mind, evolution of the UEFI and PI specifications can also occur via the errata process. If you think of the major specification updates to be a forward direction evolving process, the errata process is more lateral in that it clarifies issues within a given set of specifications without introducing interoperability issues. This interop issue is important in that there is no software discernible difference between various implementations of errata for a given UEFI or PI major version, so such changes cannot be probed by software via the version number conceit listed earlier.
Finally we get to the point of this blog posting and the PI 1.2.1a specification. The 'a' suffix means that this revision of the specification consists of the first errata against the PI 1.2.1a specification. Recall that the PI 1.2.1 specification was released on May 2, 2012. The PI 1.2.1a specification, in turn, was released on October 26, 2012. This five month cadence is not unreasonable, with the most frequent errata cycle being once per quarter if there are sufficient bugs to address.
For PI 1.2.1a specification, the errata includes the following:
- Adding a 'boot with manufacturing mode'
- Addition of a simple signed firmware volume and file
- Clarification of memory usage across the S3 boot path
- Root handler processing clarification in SMI
and other clean-up.
The creation of errata allow for consistency in the software definitions. This, along with conformant implementations of the UEFI and PI specifications at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2, provides an evolution of the platform firmware between the addition of new features and capabilities in major specification revision updates.
With all that in mind, evolution of the UEFI and PI specifications can also occur via the errata process. If you think of the major specification updates to be a forward direction evolving process, the errata process is more lateral in that it clarifies issues within a given set of specifications without introducing interoperability issues. This interop issue is important in that there is no software discernible difference between various implementations of errata for a given UEFI or PI major version, so such changes cannot be probed by software via the version number conceit listed earlier.
Finally we get to the point of this blog posting and the PI 1.2.1a specification. The 'a' suffix means that this revision of the specification consists of the first errata against the PI 1.2.1a specification. Recall that the PI 1.2.1 specification was released on May 2, 2012. The PI 1.2.1a specification, in turn, was released on October 26, 2012. This five month cadence is not unreasonable, with the most frequent errata cycle being once per quarter if there are sufficient bugs to address.
For PI 1.2.1a specification, the errata includes the following:
- Adding a 'boot with manufacturing mode'
- Addition of a simple signed firmware volume and file
- Clarification of memory usage across the S3 boot path
- Root handler processing clarification in SMI
and other clean-up.
The creation of errata allow for consistency in the software definitions. This, along with conformant implementations of the UEFI and PI specifications at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2, provides an evolution of the platform firmware between the addition of new features and capabilities in major specification revision updates.
No comments:
Post a Comment