Intel Extensible Firmware Interface - Manual (Page 28)

Extensible Firmware Interface Specification
1-2 12/01/02 Version 1.10
1.1 EFI Driver Model Extensions
Access to boot devices is provided through a set of protocol interfaces. The EFI 1.02 Specification
describes these protocol interfaces in detail. However, it does not describe how these protocol
interfaces are produced by the system firmware. The EFI 1.10 Specification includes extensions to
the EFI 1.02 Specification that describe the EFI Driver Model along with additional protocol
interfaces that provide access to a richer set of boot devices. One purpose of the EFI Driver Model
is to provide a replacement for “PC-AT”-style option ROMs. It is important to point out that
drivers written to the EFI Driver Model are designed to access boot devices in the preboot
environment. They are not designed to replace the high performance OS specific drivers. The
EFI 1.10 Specification is designed to be backward compatible with the EFI 1.02 Specification.
This means that any EFI applications or drivers written to the EFI 1.02 Specification will continue
to function on system firmware that complies with the EFI 1.10 Specification.
The EFI Driver Model is designed to support the execution of modular pieces of code, also known
as drivers that run in the preboot environment. These drivers may manage or control hardware
buses and devices on the platform or they may provide some software derived platform specific
service.
The EFI Driver Model is designed to extend the EFI Specification in a way that supports device
drivers and bus drivers. These extensions are provided in the form of new protocols, new boot
services, and updated EFI boot services that are backward compatible with their original versions.
The EFI Driver Model also contains information required by EFI driver writers to design and
implement any combination of bus drivers and device drivers that a platform may need to boot an
EFI compliant OS.
The EFI Driver Model is designed to be generic and can be adapted to any type of bus or device.
The EFI 1.10 Specification describes how to write PCI bus drivers, PCI device drivers, USB bus
drivers, USB device drivers, and SCSI drivers. Additions details are provided that allow EFI
drivers to be stored in PCI option ROMs while maintaining compatibility with legacy option
ROM images.
One of the design goals in the EFI 1.10 Specification is to keep the driver images as small as
possible. However, if a driver is required to support multiple processor architectures, a driver
object file would have to be shipped for each supported processor architecture. To address this
space issue, the EFI 1.10 Specification also defines the EFI Byte Code Virtual Machine. An EFI
driver can be compiled into a single EFI Byte Code Virtual Machine object file. EFI 1.10
complaint firmware must contain an EFI Byte Code interpreter. This allows a single EFI Byte
Code object file to be shipped that supports multiple processor architectures. Another space saving
technique is the use of compression. The EFI 1.10 Specification defines compression and
decompression algorithms that may be used to reduce the size of EFI drivers, and thus reduce the
overhead when EFI drivers are stored in ROM devices.
The information contained in the EFI 1.10 Specification can be used by OSVs, IHVs, OEMs, and
firmware vendors to design and implement EFI firmware, EFI drivers that produce standard
protocol interfaces, and EFI operating system loaders that can be used to boot EFI compliant
operating systems.