Extensible Firmware Interface Specification
320 12/12/00 Version 1.02
Programmatic interaction with the boot manager is accomplished through globally defined
variables. On initialization the boot manager reads the values which comprise all of the published
load options among the EFI environment variables. By using the SetVariable() function the
data that contain these environment variables can be modified.
Each load option entry resides in a Boot#### variable or a Driver#### variable where the
#### is replaced by a unique option number in printable hexadecimal representation
(0000 – FFFF). The #### must always be four digits, so small numbers must use leading zeros.
The load options are then logically ordered by an array of option numbers listed in the desired
order. There are two such option ordering lists. The first is DriverOrder that orders the
Driver#### load option variables into their load order. The second is BootOrder that orders
the Boot#### load options variables into their load order.
For example, to add a new boot option, a new Boot#### variable would be added. Then the
option number of the new Boot#### variable would be added to the BootOrder ordered list and
the BootOrder variable would be rewritten. To change boot option on an existing Boot####,
only the Boot#### variable would need to be rewritten. A similar operation would be done to
add, remove, or modify the driver load list.
If the boot via Boot#### returns with a status of EFI_SUCCESS the boot manager will stop
processing the BootOrder variable and present a boot manager menu to the user. If a boot via
Boot#### returns a status other than EFI_SUCCESS, the boot has failed and the next
Boot#### in the BootOrder variable will be tried until all possibilities are exhausted.
The boot manager may perform automatic maintenance of the database variables. For example, it
may remove unreferenced load option variables, any unparseable or unloadable load option
variables, and rewrite any ordered list to remove any load options that do not have corresponding
load option variables. In addition, the boot manager may automatically update any ordered list to
place any of its own load options where it desires. The boot manager can also, at its own
discretion, provide for manual maintenance operations as well. Examples include choosing the
order of any or all load options, activating or deactivating load options, etc.
The boot manager is required to process the Driver load option entries before the Boot load option
entries. The boot manager is also required to initiate a boot of the boot option specified by the
BootNext variable as the first boot option on the next boot, and only on the next boot. The boot
manager removes the BootNext variable before transferring control to the BootNext boot
option. If the boot from the BootNext boot option fails the boot sequence continues utilizing the
BootOrder variable. If the boot from the BootNext boot option succeeds by returning
EFI_SUCCESS the boot manager will not continue to boot utilizing the BootOrder variable.
The boot manager must call LoadImage() which supports at least SIMPLE_FILE_PROTOCOL
and LOAD_FILE_PROTOCOL for resolving load options. If LoadImage() succeeds, the boot
manager must enable the watchdog timer for 5 minutes by using the SetWatchdogTimer()
boot service prior to calling StartImage(). If a boot option returns control to the boot manager,
the boot manager must disable the watchdog timer with an additional call to the
SetWatchdogTimer() boot service.
If the boot image is not loaded via LoadImage() the boot manager is required to check for a
default application to boot. Searching for a default application to boot happens on both removable