I forgot to mention but Tianocore and other UEFI Open Source projects have implemented shells for UEFI firmwares.
Some people are even working on porting Python to UEFI.
Feel free to ask questions or clarifications about this overview.
Mainly if you had thoughts about the way UEFI works which does not correspond to the big picture I gave.
Olivier
-----Original Message-----
From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot-architecture-bounces@lists.linaro.org] On Behalf Of Olivier Martin
Sent: 06 July 2011 20:29
To: boot-architecture(a)lists.linaro.org
Subject: UEFI Overview
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.
_______________________________________________
boot-architecture mailing list
boot-architecture(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/boot-architecture
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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.
