Intel Extensible Firmware Interface - Manual (Page 57)

Overview
Version 1.10 12/01/02 2-17
The combination of firmware services, bus drivers, and device drivers in any given platform is
likely to be produced by a wide variety of vendors including OEMs, IBVs, and IHVs. These
different components from different vendors are required to work together to produce a protocol for
an I/Odevice than can be used to boot an EFI compliant operating system. As a result, the EFI
Driver Model is described in great detail in order to increase the interoperability of these
components.
This remainder of this section is a brief overview of the EFI Driver Model. It describes the legacy
option ROM issues that the EFI Driver Model is designed to address, the entry point of a driver,
host bus controllers, properties of device drivers, properties of bus drivers, and how the EFI Driver
Model can accommodate hot-plug events.
2.5.1 Legacy Option ROM Issues
Legacy option ROMs have a number of constraints and limitations that restrict innovation on the
part of platform designers and adapter vendors. At the time of writing, both ISA and PCI adapters
use legacy option ROMs. For the purposes of this discussion, only PCI option ROMs will be
considered; legacy ISA option ROMs are not supported as part of the EFI Specification.
The following is a list of the major constraints and limitations of legacy option ROMs. For each
issue, the design considerations that went into the design of the EFI Driver Model are also listed.
Thus, the design of the EFI Driver Model directly addresses the requirements for a solution to
overcome the limitations implicit to PC-AT-style legacy option ROMs.
2.5.1.1 IA-32 16-Bit Real Mode Binaries
Legacy option ROMs typically contain 16-bit real mode code for an IA-32 processor. This means
that the legacy option ROM on a PCI card cannot be used in platforms that do not support the
execution of IA-32 real mode binaries. Also, 16-bit real mode only allows the driver to access
directly the lower 1 MB of system memory. It is possible for the driver to switch the processor into
modes other than real mode in order to access resources above 1 MB, but this requires a lot of
additional code, and causes interoperability issues with other option ROMs and the system BIOS.
Also, option ROMs that switch the processor into to alternate execution modes are not compatible
with Itanium Processors.
EFI Driver Model design considerations:
• Drivers need flat memory mode with full access to system components.
• Drivers need to be written in C so they are portable between processor architectures.
• Drivers may be compiled into a virtual machine executable, allowing a single binary driver to
work on machines using different processor architectures.