Terminology

The following list provides a quick overview of some of the terms that may be encountered later in the article and have existed in the industry associated with the BIOS standardization efforts.

• UEFI Forum. The industry body which produces UEFI, Platform Initialization (PI), and other specifications.
• UEFI Specification. The firmware-OS interface specification.
• EDK. The EFI Development Kit, an open sourced project that provides a basic implementation of UEFI, Framework, and other industry standards. It, is not however, a complete BIOS solution. An example of this can be found at http://www.tianocore.org.
• UDK. The UEFI Development Kit is the second generation of the EDK (EDK II), which has added a variety of codebase related capabilities and enhancements. The inaugural UDK is UDK2010, with the number designating the instance of the release.
• Framework. A deprecated term for a set of specifications that define interfaces and how various platform components work together. What this term referred to is now effectively replaced by the PI specifications.
• Tiano. An obsolete codename for an Intel codebase that implemented the Framework specifications.

A Short History of EFI

The Extensible Firmware interface (EFI) project was developed by Intel, with the initial specification released in 1999. At the time, it was designed as the means by which to boot Itanium-based systems. The original proposal for booting Itanium was the SAL (System Architectural Layer) SAL_PROC interface, with an encapsulation of the PC/AT BIOS registers as the arguments and parameters. Specifically, the means to access the disk in the SAL_PROC proposal was "SAL_PROC (0x13, 0x2, ...)", which is aligned with the PC/AT conventional BIOS call of "int13h."

Given the opportunity to clean up the boot interface, various proposals were provided. These included but were not limited to Open Firmware and Advanced RISC Computing (ARC). Ultimately, though, EFI prevailed and its architecture-neutral interface was adopted.

The initial EFI specification included both an Itanium and IA-32 binding. EFI evolved from the EFI 1.02 interface into EFI1.10 in 2001. EFI1.10 introduced the EFI Driver model.

With the advent of 64-bit computing on IA-32 (for example, x64) and the industry’s need to have a commonly owned specification, the UEFI 2.0 specification appeared in 2005. UEFI 2.0 is largely the same as EFI 1.0, but also included the modular networking stack APIs for IPv4 and the x64 binding. In Figure 3, we illustrate the evolution of the BIOS from its legacy days through 2010.

[Click image to view at full size]

Figure 3: BIOS Evolution Timeline.

EFI Becomes UEFI -- The UEFI Forum

Regarding the UEFI Forum, there are various aspects to how it manages both the UEFI and PI specifications. Specifically, the UEFI forum is responsible for creating the UEFI and PI specifications.

When the UEFI Forum first formed, a variety of factors and steps were part of the creation process of the first specification:

• The UEFI forum stakeholders agree on EFI direction
• Industry commitment drives need for broader governance on specification
• Intel and Microsoft contribute seed material for updated specification
• EFI 1.10 components provide starting drafts
• Intel agrees to contribute EFI test suite As this had established the framework of the specification material that was produced which the industry used, the forum itself was formed with several thoughts in mind:
  • The UEFI Forum is established as a Washington non-profit Corporation
    • Develops, promotes and manages evolution of Unified EFI Specification
    • Continue to drive low barrier for adoption
  • The Promoter members for the UEFI forum are:
    • AMD, AMI, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo, Microsoft, Phoenix
  • The UEFI Forum has a form of tiered Membership:
    • Promoters, Contributors, and Adopters
    • More information on the membership tiers can be found at http://www.uefi.org
  • The UEFI Forum has several work groups:
    • Figure 4 illustrates the basic makeup of the forum and the corresponding roles.
    [Click image to view at full size]

    

    Figure 4: Forum group hierarchy.

  • Sub-teams are created in the main owning workgroup when a topic of sufficient depth requires a lot of discussion with interested parties or experts in a particular domain. These teams are collaborations amongst many companies who are responsible for addressing the topic in question and bringing back to the workgroup either a response or material for purposes of inclusion in the main working specification. Some examples of sub-teams that have been created are as follows
    • UCS/UEFI Configuration Sub-team
      • Chaired by Michael Rothman (Intel)
      • Responsible for all configuration related material and the team has been responsible for the creation of the UEFI configuration infrastructure commonly known as HII, which is in the UEFI Specification.
    • UNST/UEFI Networking Sub-team
      • Chaired by Vincent Zimmer (Intel)
      • Responsible for all network related material and the team has been responsible for the update/inclusion of the network related material in the UEFI specification, most notably the IPv6 network infrastructure.
    • USST/UEFI Security Sub-team
      • Chaired by Tim Lewis (Phoenix)
      • Responsible for all security related material and the team has been responsible for the added security infrastructure in the UEFI specification.