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.
Boot sequence: -------------- 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 dependencies solved). 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.
Some examples: # Device path for a kernel on PCI SATA Hard Drive: PciRoot(0)/Pci(0|0)/Pci(0|0)/Pci(5|0)/Pci(0|0)/Sata(0,0,0)/HD(2,MBR,0x000767 30,0x1F21BF,0x1F21BF)\boot\zImage - 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(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0 )/zImage - 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 devices.