Filter
Top Products
Introduction
Version 1.10 12/01/02 1-7
specification to ensure that firmware developers, OEMs, operating system vendors, and
perhaps even third parties can share the space safely while adding to platform capability.
Defining a boot environment that delivers these attributes could be accomplished in many ways.
Indeed several alternatives, perhaps viable from an academic point of view, already existed at the
time this specification was written. These alternatives, however, typically presented high barriers
to entry given the current infrastructure capabilities surrounding Intel architecture platforms. This
specification is intended to deliver the attributes listed above while also recognizing the unique
needs of an industry that has considerable investment in compatibility and a large installed base of
systems that cannot be abandoned summarily. These needs drive the requirements for the
additional attributes embodied in this specification:
• Evolutionary, not revolutionary. The interfaces and structures in the specification are
designed to reduce the burden of an initial implementation as much as possible. While
care has been taken to ensure that appropriate abstractions are maintained in the interfaces
themselves, the design also ensures that reuse of BIOS code to implement the interfaces is
possible with a minimum of additional coding effort. In other words, on IA-32 platforms
the specification can be implemented initially as a thin interface layer over an underlying
implementation based on existing code. At the same time, introduction of the abstract
interfaces provides for migration away from legacy code in the future. Once the
abstraction is established as the means for the firmware and OS loader to interact during
boot, developers are free to replace legacy code underneath the abstract interfaces at
leisure. A similar migration for hardware legacy is also possible. Since the abstractions
hide the specifics of devices, it is possible to remove underlying hardware, and replace it
with new hardware that provides improved functionality, reduced cost, or both. Clearly
this requires that new platform firmware be written to support the device and present it to
the OS loader via the abstract interfaces. However, without the interface abstraction,
removal of the legacy device might not be possible at all.
• Compatibility by design. The design of the system partition structures also preserves all
the structures that are currently used in the “PC-AT” boot environment. Thus it is a
simple matter to construct a single system that is capable of booting a legacy OS or an
EFI-aware OS from the same disk.
• Simplifies addition of OS-neutral platform value-add. The specification defines an open
extensible interface that lends itself to the creation of platform “drivers.” These may be
analogous to OS drivers, providing support for new device types during the boot process,
or they may be used to implement enhanced platform capabilities like fault tolerance or
security. Furthermore this ability to extend platform capability is designed into the
specification from the outset. This is intended to help developers avoid many of the
frustrations inherent in trying to squeeze new code into the traditional BIOS environment.
As a result of the inclusion of interfaces to add new protocols, OEMs or firmware
developers have an infrastructure to add capability to the platform in a modular way. Such
drivers may potentially be implemented using high level coding languages because of the
calling conventions and environment defined in the specification. This in turn may help to
reduce the difficulty and cost of innovation. The option of a system partition provides an
alternative to nonvolatile memory storage for such extensions.
• Built on existing investment. Where possible, the specification avoids redefining
interfaces and structures in areas where existing industry specifications provide adequate
coverage. For example, the ACPI specification provides the OS with all the information