Filter
Top Products
Extensible Firmware Interface Specification
1-10 12/01/02 Version 1.10
bus types is being designed into desktop and mobile systems and even some embedded systems.
This increasing complexity means that a simple method for describing and managing all the buses
and devices in a platform is required in the preboot environment. The EFI Driver Model provides
this simple method in the form of protocols services and boot services.
1.6.1 EFI Driver Model Goals
The EFI Driver Model has the following goals:
• Compatible –TheEFI Driver Model must maintain compatibility with the EFI 1.02
Specification. This means that the EFI Driver Model must take advantage of the
extensibility mechanisms in the EFI 1.02 Specification to add the required functionality
• Simple – Drivers written to the EFI Driver Model must be simple to implement and
simple to maintain. The EFI Driver Model must allow a driver writer to concentrate on
the specific device for which the driver is being developed. A driver should not be
concerned with platform policy or platform management issues. These considerations
should be left to the system firmware.
• Scalable –TheEFI Driver Model must be able to adapt to all types of platforms. These
platforms would include embedded systems; mobile and desktop systems, as well as
workstations; and servers.
• Flexible –TheEFI Driver Model must support the ability to enumerate all the devices, or
to enumerate only those devices required to boot the required OS. The minimum device
enumeration provides support for more rapid boot capability, and the full device
enumeration provides the ability to perform OS installations, system maintenance, or
system diagnostics on any boot device present in the system.
• Extensible –TheEFI Driver Model must be able to extend to future bus types as they are
defined.
• Portable – Drivers written to the EFI Driver Model must portable between platforms and
between processor architectures. Initially this is limited to platforms with IA-32 family
and Itanium
®
processors, but no processor-specific assumptions are made.
• Interoperable – Drivers must coexist with other drivers and system firmware and must do
so without generating resource conflicts.
• Describe Complex Bus Hierarchies –TheEFI Driver Model must be able to describe a
variety of bus topologies from very simple single bus platforms to very complex platforms
containing many buses of various types.
• Small Driver Footprint – The size of executables produced by the EFI Driver Model must
be minimized to reduce the overall platform cost. While flexibility and extensibility are
goals, the additional overhead required to support these must be kept to a minimum to
prevent the size of firmware components from becoming unmanageable.
• Address Legacy Option ROM Issues –TheEFI Driver Model must directly address and
solve the constraints and limitations of legacy option ROMs. Specifically it must be
possible to build add-in cards that support both EFI drivers and legacy option ROMs
where such cards can execute in both legacy BIOS systems and EFI conforming platforms
without modifications to the code carried on the card. The solution must provide an
evolutionary path to migrate from legacy option ROMs driver to EFI drivers.