What’s Driving the Evolution of the Unified Extensible Firmware Interface?
To learn where the Unified Extensible Firmware Interface, or UEFI, is going, it helps to know how problems became mothers of invention when the PC’s commercial success led to a de facto, rather than formally standardized, BIOS, as we learn in the first of a series of articles.
Typically, nothing is ever developed in a vacuum, and few technologies in modern devices come into being fully formed and without precedent or prior equivalent technology. The same can be said for computer firmware and Basic Input/Output System (BIOS) solutions. Even when the PC was a brand-new product, the architecture and model of the software stack was based upon decades of proven computer science. The history of the PC BIOS establishes a context and continuity necessary for understanding the forces driving the Unified Extensible Firmware Interface (UEFI) evolution.
When the PC was first developed, it was equipped with a set of software, stored in non-volatile memory, which provided system initialization and device functionality on the platform as an integral part of the hardware. This was designated as firmware, with the “firm” defined as software as part of the hardware (software + hardware = firmware). Firmware provided low-level functionality of the hardware in a standard mechanism. This was the first PC BIOS, and with the commercial success of the PC, the BIOS was replicated in the many ‘clone’ systems that followed. Through this replication, the BIOS interface became a de facto standard.
No One Complete Specification
Presented with this de facto standard, developers faced difficulties defining the standard in writing. In the first clones, the standard was to “work just like the original PC.” But then the PC standard began to evolve from the PC-XT to the PC-AT, and then to include the newer and more robust technologies and options consumers demanded. The standard was not fully quantified or documented, so the manufacturers were not willing to wait and lose market opportunity as the original manufacturer implemented new technology support. Each manufacturer began to uniquely customize its BIOS implementations to meet its expanded requirements.
To this day, due to this level of customization, there is no one complete specification for all PC BIOS interfaces and implementations. But rather, books detailing the BIOS interface do exist and can range from a few hundred pages (for the basic standard PC implementation) to more than a thousand pages (for the basics, many of the common customizations, and data on the methodologies for customization so the reader will be able to analyze those customizations not defined in the text).
Modularity makes it easier to develop firmware, and more importantly provides a clean mechanism to reuse code as possible. In the end, EFI was about developing firmware following more advanced software design practices.
Signs Pointing to Unsustainability
Needless to say, PC BIOS was not designed to be a long-term solution for the personal computer industry’s pre-boot and boot requirements, but as an expediency to get the first PC’s to boot. The popularity of the PC inspired the creation of the PC compatible industry as manufacturers began to develop and sell clones based upon the original product. By duplicating the original product, these clones were defined to include the same BIOS code and interfaces. PC BIOS became a standard that everyone copied.
This was the situation that continued on for years in the PC marketplace, but there were growing signs that the BIOS would eventually become unsustainable as the interface standard. When hard disk drives were added in the PC-AT (the second and upgraded version of the original PC-XT), there was an inherent limitation in the BIOS that had to be adjusted to allow for disk drives over 10.4 MB in capacity.
As time and technology moved forward, the BIOS standard began to unravel with 32-bit processors, larger capacity disk drives (the standard interface was limited to addressing a device of 504MB or smaller), new enhanced graphics capabilities, Ethernet and internet support, and the additions of new technologies like Universal Serial Bus (USB), Peripheral Component Interconnect Express (PCIe), and Embedded Multi Media Card (eMMC).
Like many things, the cost of the effort against the magnitude of gain was eventually to become untenable. And so, it was understood, that one day, the BIOS would face redesign or replacement.
Extensibility and Software Design Principles
The Extensible Firmware Interface or EFI, the forerunner to UEFI, does relate to the development of a boot solution for the Itanium processor. However, the more significant part of the story is how the developers fashioned the EFI to be an organic replacement for the traditional PC BIOS.
In general, EFI began with the evaluation of the Legacy PC BIOS as a possible boot solution for the new class of processor. When engineers discovered that the Legacy PC BIOS was not suitable to the new technology, they created a new boot solution, architected to avoid the issues inherent in the original PC BIOS. This decision defines EFI as having standard infrastructure and using a standard interface scheme to allow for the extensibility of capability over time. So, as new technologies become available, the standard could be expanded, and as old technologies became obsolete, their support could be phased out of implementations (though the standards would remain in the specification as historical context if nothing else).
It should be noted at this point how EFI (and eventually UEFI) were developed and designed to overcome the known issues of Legacy, PC BIOS. The original Legacy PC BIOS (also known as traditional BIOS) was developed for the Intel® 8088 processor in the original PC. It would run in 16-bit mode and was established to execute at a set and known location in memory (originally 0F8000h – 0FFFFFh, which was top of memory for the 8088). While the first PC BIOS was 32 KB, the space for the PC BIOS was later expanded to 64 KB, with optional space reserved for add-on card BIOS and additional BIOS expansions to include memory regions from 0C0000h to 0FFFFFh.
The interface standard for the Legacy PC BIOS was a mix of direct calls into known memory locations in the BIOS space and the use of software interrupts to enter functional dispatchers with command codes in one register, and other parameters in the remaining 8088 16-bit registers. While the memory locations were phased out over the years, the “landing zones” were preserved to maintain compatibility with older applications, which were dependent upon them. The number of interrupts allocated for the command interface was set, and the number of command codes was limited per interrupt.
Only the original interface routines were considered standard, so the development of new interfaces would always be a problem, as each manufacturer would have its own need for new interfaces and would create new interfaces as needed. Without a standards organization to collate the new interfaces as they were required, each manufacturer’s BIOS implementation would have unique components, which could be at odds with the implementations of other manufacturers.
The EFI specification changed the interface paradigm of the BIOS. While the processor Boot Vector (a known memory address where the processor will ‘fetch’ the first instructions of code) is specific for each processor, and a BIOS by definition must factor that address in its design to be functional in the system. The EFI specification established that:
- The firmware could execute from memory anywhere in the system.
- The interfaces would be dynamic in nature, based upon pointer structures and functionally identified by a Globally Unique Identifier (GUID) and unique 128-bit integer value generated to be unique in value.
These two changes alone allow for the firmware of a system to support an ever-increasing number of devices and technologies, without having to worry about running out of interfaces or space in memory to execute.
With the use of a dynamic pointer system, the EFI standard allowed BIOS to be modular. Developers gained more flexibility to configure the BIOS capabilities to include and remove modules at need. Modularity makes it easier to develop firmware and, more important, provides a clean mechanism to reuse code as possible. In the end, EFI was about developing firmware following more advanced software design practices.
The next article will dive into the next stage of UEFI evolution and the advancements that have been made.
Michael Krau is a Systems Engineer at Intel Corporation and is the Chair of the Industry Communications Working Group (ICWG) of the UEFI Forum.