olivier.martin at arm.com
Wed Jul 6 19:29:21 UTC 2011
This email describes the way UEFI Tianocore implementation works. I limit
the scope to the UEFI drivers and the 'boot manager'. The implementation and
the platform specific bits are skipped.
1) After the platform modules (part of the PI (Platform Initialization)
phase) have finished the bringup initialization, the DXE (Driver Execution
Environment) Core is loaded.
2) The DXE core scans the different firmwares available on the platform and
calls the entrypoint of all the drivers that are expected to start (either
they request to be initialized during this sequence or they have their
Following the recommendation of the UEFI specification, the drivers should
do not touch the hardware controllers during this phase. They should only
declares their protocols (UEFI name for 'interfaces') to the DXE core.
3) Once all the drivers are dispatched, the DXE core passes its control to
the driver that exports the Boot Device Selection (BDS) interface.
This BDS driver should implement the 'Boot Manager' of the UEFI firmware
defined by the Chapter 3 of the UEFI spec.
This chapter defines non volatile variables that define among other things:
- The Boot Device entries ('Boot###' variables) (Name, location of the OS
loader, arguments) and their order ('BootOrder' variable)
- The devices responsible for the Console Input/Output
- The 'Timeout' before the BDS starts the default boot selection
- if defined, 'BootNext' defines the OS loader/EFI application to start the
next boot only (the variable is erased at the next boot)
4) Following the non variables values, the BDS will either automatically
starts the boot device (case 'BootNext' is defined or 'TimeOut' reached 0)
or displays the boot menu (with the Boot Device entries defined by
'Boot###' listed in the order defined by 'BootOrder'). Then the user chooses
in this menu which entry he/she wants to start.
5) With our implementation of the Boot Manager, we currently defines 3 types
of boot devices. The boot device can be either an EFI application (eg: an OS
loader) or a ATAG or FDT Linux kernel image. In case the BDS starts a Linux
kernel images, our BDS will automatically fills the required ATAG or loads
the Device Tree blob.
Note: One of our partner has been asking us to provide a reference EFI
Application to boot Linux. It is expecting some platforms will have their
own BDS and will use an EFI application to load the Linux kernel.
Actually, we are waiting the output of the Boot Architecture 'forum' to
provide such 'reference' EFI application.
UEFI Device Path
UEFI has the concept of 'Device Path'. Every hardware devices supported by
the UEFI firmware on the platform have a representation that defined the
hardware path to access to this device and their properties.
# Device path for a kernel on PCI SATA Hard Drive:
- PciRoot(0) define the first PCI Root complex.
- PCI(5|0) = PCI controller with Device = 5 and Function = 0
- HD(Partition,Type,Signature,Start, Size) = hard disk partition
- \boot\zImage : filepath on the partition
# Device path for a Linux kernel on the first partition of the SD card:
- VenHw(guid) is used when the device path node is not defined by the UEFI
specification (generally memory mapped controllers)
The Device Path allows to describe hardware devices or media even if they
have been initialized. When hardware drivers are started they can declare
the device path(s) of the hardware they support.
The advantage is if we do not need some specific hardwares during the UEFI
boot up, we could skip their initialization in UEFI.
This device path complexity can be hidden by the Boot Manager. We have
implemented our own interactive boot menu to help us to define the boot
More information about the boot-architecture