You've come to this page because you've asked a question similar to the following:
What is the boot process employed by EFI (Extensible Firmware Interface) machine firmware?
This is the Frequently Given Answer to such questions.
Bootstrapping on EFI involves a boot manager that is built in to the firmware. EFI systems do not rely upon bootstrap programs stored in boot records (VBRs or MBRs) at all. The firmware knows how to read a partition table and understands the FAT filesystem format. (IBM PC compatible firmware does neither.) A designated partition, that is formatted with the FAT filesystem format and identified with a specific well-known partition type, is known as the EFI System Partition. (The EFI System Partition is a true system volume that is identified by its type code in the partition table, not a Poor Man's equivalent that is guessed at like Microsoft's System Reserved Partition is.) It contains boot loader programs, which are EFI executable programs that are loaded and run by the EFI boot manager.
EFI executable programs are standalone programs, that use only machine firmware services and that do not require an underlying operating system in order to run. They can be either operating system boot loaders or "pre-boot" maintenance/diagnosis programs.
The details of the EFI boot manager are up to the firmware implementor,
but all boot managers are configured using well-known EFI variables, which
are publicly defined and documented mechanisms for holding firmware
configuration data. Boot managers are required to inspect these EFI
variables and behave accordingly. The main variable is the
BootOrder EFI variable. And there are two primary use cases:
A system with no BootOrder EFI variable is a system without a
bootable operating system yet installed. The boot manger thus falls back
to a procedure which involves looking for boot loader files in standard
places, in the expectation that a floppy disc, CD-ROM, DVD or other disc
will have a boot loader that will start an operating system installer (or,
more simply, a cut-down operating system with an installer program) from
that disc.
Specifically: In this case, EFI boot managers are
required to enumerate all removable DASDs and fixed DASDs. For removable
DASDs, the disc is treated as containing a single volume. For fixed
DASDs, the disc is searched for an EFI system partition and that volume is
used. In both cases, EFI boot managers look for an EFI executable program
to run stored in the designated volume and called
\EFI\BOOT\BOOTtype.EFI (where
type is IA32, IA64, or some other such
string, according to CPU architecture). This is a default operating
system boot loader.
A system with an BootOrder EFI variable is a system with one
or more already installed and bootable operating systems. And a simpler
scenario ensues. The variable
contains a list of EFI boot options. A boot option is a reference to
another EFI variable, with a standardized name format, that
contains the device and path name of an EFI executable program to load and
run, and a set of parameters to pass to that program. The boot manager
displays a list of these boot options (one part of which is a "display
name" for the boot manager menu), the user chooses the option to boot, and
the boot manager loads and invokes the chosen boot loader program, passing
it various EFI device paths specifying configuration options and the like.
In many ways the EFI boot process is much the same as the ARC boot process: There's a boot manager built in to the firmware, that uses a database comprising a set of firmware variables (alterable by operating system installation and utility programs and with a public and well defined structure), that presents a list of options from which the user chooses, which results in a loader program to run and some options to pass to it.
The differences lie in the details. EFI device paths are more expressive
than ARC paths (which as anyone who has fiddled with BOOT.INI
on Windows NT versions 4 or 5 will know, have an obscure and not very
intuitive format) and encode hardware device locations more accurately
(modulo some strange ideas that EFI has about SCSI). The EFI boot manager
has the option to boot to a command interpreter, the "EFI Shell". And
there's a well defined firmware interface that has a well-defined
extension mechanism for adding things such as extra filesystem drivers to
allow boot-time access to disc volumes formatted with filesystem formats
other than FAT.
By convention, all of the boot
loaders for operating systems are stored in the EFI system partition on a
partitionable DASD, in
a vendor-specific subdirectory
of the
\EFI\ directory.
For the 64-bit versions of Windows NT 5.x, the EFI boot loader is
\EFI\Microsoft\WINNT50\IA64LDR.EFI
(sometimes \EFI\Microsoft\WINNT50C\IA64LDR.EFI),
which comprises NTLDR, the Windows NT boot loader that loads and executes
the Windows NT kernel from files in the Windows
boot volume.
64-bit versions of Windows NT 5.x use EFI as it was designed to be used.
For
Windows NT 6,
the EFI boot loader is
\EFI\Microsoft\Boot\Bootmgfw.efi, which is the Microsoft
Boot Manager — another boot manager, which presents a
second menu of boot options, read from a database file in a
Microsoft-proprietary format, which in turn list boot loader programs to
invoke and options to pass to them.
Windows NT 6 needlessly duplicates the functionality of the EFI boot manager, and needlessly makes a user-visible distinction between all other operating systems (listed on the first boot manager menu, which Microsoft configures to be displayed for only 2 seconds in order to, in Microsoft's own words, "make it easier" for users) and Windows NT (listed on the second boot manager menu).
For the 64-bit versions of Linux, the EFI boot loader is either
\EFI\RedHat\elilo.efi or
\EFI\SuSE\elilo.efi, which comprises a modified version of
LILO, the Linux boot loader that loads and executes the Linux kernel from
files in the
system volume.
ELILO, like the Microsoft Boot Manager, contains a second level
of boot options, held in a separate elilo.conf configuration
file, rather than integrating support for such multiple boot options into
the EFI boot loader and EFI variables, as it should. Unlike the Microsoft
Boot Manager, however, ELILO is a boot loader, incapable of loading any
other operating system but Linux (the different boot options merely
allowing one to specify which Linux kernel image file to use and various
options specific to the Linux kernel such as the ramdisc size), not a boot
manager, and so does not needlessly duplicate all of the
functionality of the EFI boot manager.
For HP-UX, the EFI boot loader is \EFI\HPUX\hpux.efi,
which loads and executes the HP-UX kernel from an image file in the
system volume
(e.g. /vmlinux). The HP-UX boot loader also comprises
an interactive shell, although the EFI Shell that comes with the EFI
firmware provides much the same functionality.
Apple ignores or subverts large parts of the EFI specification on its Intel Macintoshes. The EFI System Partition is empty and unused, and the EFI boot manager is obscured by an Apple boot loader that is executed before it.
The Apple EFI firmware understands the HFS+ filesystem format, in addition
to the FAT filesystem format mandated by the EFI specification. Apple's
firmware boot loader reads the value of a variable stored in
NVRAM. This can either point to a disc partition or to a specific file,
depending from whether one has "blessed" a disc partition or a
file/directory using
the bless utility.
(Blessing a directory is a shorthand for copying a platform-specific boot
loader file into that directory and then blessing the file.)
If the value in NVRAM points to a disc partition, then the Apple boot
loader assumes that this is an HFS+ formatted volume. HFS+ contains a
file ID pointer in its volume header that points to a boot file. The
Apple boot loader reads the HFS+ volume header, and loads and runs the
indicated file as an EFI application. By default, this is
/System/Library/CoreServices/boot.efi, the boot loader for
MacOS X.
If the value in NVRAM points to a specific file, that is the EFI
executable that the Apple boot loader loads at boot, ignoring what any
HFS+ volume headers may contain. One such file is xom.efi,
an alternative EFI operating system boot loader application that loads
Windows NT XP on Intel Macintoshes.
If, in either case, the EFI application is non-graphical, its user
interface won't be seen, because the Apple boot loader switches the
display to graphical mode. If the application exits, returning to the
firmware, the EFI boot manager is finally invoked. But since the EFI boot
manager has a textual user interface, its user interface will not be
visible, either. (A TextMode.efi EFI application is freely
available that simply switches the display back to text mode and returns
to the firmware.)
