Filter
Top Products
Extensible Firmware Interface Specification
1-6 12/01/02 Version 1.10
1.3 Goals
The “PC-AT” boot environment presents significant challenges to innovation within the industry.
Each new platform capability or hardware innovation requires firmware developers to craft
increasingly complex solutions, and often requires OS developers to make changes to their boot
code before customers can benefit from the innovation. This can be a time-consuming process
requiring a significant investment of resources.
The primary goal of the EFI specification is to define an alternative boot environment that can
alleviate some of these considerations. In this goal, the specification is similar to other existing
boot specifications. The main properties of this specification and similar solutions can be
summarized by these attributes:
• Coherent, scalable platform environment. The specification defines a complete solution
for the firmware to completely describe platform features and surface platform capabilities
to the OS during the boot process. The definitions are rich enough to cover the full range
of contemporary Intel architecture-based system designs.
• Abstraction of the OS from the firmware. The specification defines interfaces to platform
capabilities. Through the use of abstract interfaces, the specification allows the OS loader
to be constructed with far less knowledge of the platform and firmware that underlie those
interfaces. The interfaces represent a well-defined and stable boundary between the
underlying platform and firmware implementation and the OS loader. Such a boundary
allows the underlying firmware and the OS loader to change provided both limit their
interactions to the defined interfaces.
• Reasonable device abstraction free of legacy interfaces. “PC-AT” BIOS interfaces
require the OS loader to have specific knowledge of the workings of certain hardware
devices. This specification provides OS loader developers with something different—
abstract interfaces that make it possible to build code that works on a range of underlying
hardware devices without having explicit knowledge of the specifics for each device in
the range.
• Abstraction of Option ROMs from the firmware. This specification defines interfaces to
platform capabilities including standard bus types such as PCI, USB, and SCSI. The list
of supported bus types may grow over time, so a mechanism to extend to future bus types
is included. These defined interfaces and the ability to extend to future bus types are
components of the EFI Driver Model. One purpose of the EFI Driver Model is to solve a
wide range of issues that are present in existing “PC-AT” option ROMs. Like OS loaders,
drivers use the abstract interfaces so device drivers and bus drivers can be constructed
with far less knowledge of the platform and firmware that underlie those interfaces.
• Architecturally shareable system partition. Initiatives to expand platform capabilities and
add new devices often require software support. In many cases, when these platform
innovations are activated before the OS takes control of the platform, they must be
supported by code that is specific to the platform rather than to the customer’s choice of
OS. The traditional approach to this problem has been to embed code in the platform
during manufacturing (for example, in flash memory devices). Demand for such
persistent storage is increasing at a rapid rate. This specification defines persistent store
on large mass storage media types for use by platform support code extensions to
supplement the traditional approach. The definition of how this works is made clear in the