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.)