Intel Extensible Firmware Interface 1.6 EFI Design Overview

Introduction

Version 1.02 12/12/00 9

Any information or service that is available via Itanium-based firmware architecture specifications

supercedes any requirement in the common IA-32 and Itanium-based specifications listed above.

The Itanium-based firmware architecture spec ifications (currently the IA-64 System Abstraction

Layer Specification and portions of the IA-64 Architecture Software Developer’s Manual, Volumes

1-4) define the baseline functionality required for all Itanium-based platforms. The major addition

that EFI makes to these Itanium-based firmware architecture specifications is that it defines a boot

infrastructure and a set of services that constitute a common platform definition for high volume

Itanium-based systems to implement based on the more generalized Itanium-based firmware

architecture specifications.

The following specifications are the required Intel Itanium architecture specifications for all

Itanium-based platforms:

• IA-64 System Abstraction Layer Specification.

• IA-64 Architecture Software Developer’s Manual, Volumes 1-4.

Both documents are available at http://developer.intel.com/design/ia-64.

1.6 EFI Design Overview

The design of EFI is based on the following fundamental elements:

• Reuse of existing table-based interfaces. In order to preserve investment in existing

infrastructure support code, both in the OS and firmware, a number of existing specifications

that are commonly implemented on Intel architecture platforms must be implemented on

platforms wishing to comply with the EI specification. (See Section 1.5 for additional

information.)

• System partition. The System Partition defines a partition and file system that are designed to

allow safe sharing between multiple vendors, and for different purposes. The ability to include

a separate sharable system partition presents an opportunity to increase platform value-add

without significantly growing the need for non-volatile platform memory.

• Boot services. Boot Services provides interfaces for devices and system functionality that can

be used during boot time. Device access is abstracted through “handles” and “protocols.” This

facilitates reuse of investment in existing BIOS code by keeping underlying implementation

requirements out of the specification without burdening the consumer accessing the device.

• Runtime services. A minimal set of runtime services is presented to ensure appropriate

abstraction of base platform hardware resources that may be needed by the OS during its

normal operations.