Extensible Firmware Interface Specification
14 12/12/00 Version 1.02
2.1 Boot Manager
EFI contains a boot manager that allows the loading of EFI applications (including OS 1st stage
loader) or EFI drivers from any file on an EFI defined file system or through the use of an EFI
defined image loading service. EFI defines NVRAM variables that are used to point to the file to
be loaded. These variables also contain application specific data that are passed directly to the EFI
application. The variables also contain a human readable Unicode string that can be displayed to
the user in a menu.
The variables defined by EFI allow the system firmware to contain a boot menu that can point to all
the operating systems, and even multiple versions of the same operating systems. The design goal
of EFI was to have one set of boot menus that could live in platform firmware. EFI only specifies
the NVRAM variables used in selecting boot options. EFI leaves the implementation of the menu
system as value added implementation space.
EFI greatly extends the boot flexibility of a system over the current state of the art in the
PC-AT-class system. The PC-AT-class systems today are restricted to boot from the first floppy,
hard drive, CD-ROM, or network card attached to the system. Booting from a common hard drive
can cause lots of interoperability problems between operating systems, and different versions of
operating systems from the same vendor
2.2 Firmware Core
This section provides an overview of the services defined by EFI. These include boot services and
runtime services.

2.2.1 EFI Services

The purpose of the EFI interfaces is to define a common boot environment abstraction for use by
loaded EFI images, which include EFI drivers, EFI applications, and EFI OS loaders. The calls are
defined with a full 64-bit interface, so that there is headroom for future growth. The goal of this set
of abstracted platform calls is to allow the platform and OS to evolve and innovate independently of
one another. Also, a standard set of primitive runtime services may be used by operating systems.
Platform interfaces defined in this chapter allow the use of standard Plug and Play Option ROMs as
the underlying implementation methodology for the boot services. The PC industry has a huge
investment in Intel Architecture Option ROM technology, and the obsolescence of this installed
base of technology is not practical in the first generation of EFI-compliant systems. The interfaces
have been designed in such as way as to map back into legacy interfaces. These interfaces have in
no way been burdened with any restrictions inherent to legacy Option ROMs.
The EFI platform interfaces are intended to provide an abstraction between the platform and the OS
that is to boot on the platform. The EFI specification also provides abstraction between diagnostics
or utility programs and the platform; however, it does not attempt to implement a full diagnostic OS
environment. It is envisioned that a small diagnostic OS-like environment can be easily built on
top of an EFI system. Such a diagnostic environment is not described by this specification.