1. Unified Extensible Firmware Interface (UEFI) Framework UEFI Overview
Intel SSG/SSD/UEFI

2. Legal Disclaimer BLDK PRC Training 2011
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling , or go to: This document contains information on products in the design phase of development. All products, computer systems, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice. Intel, Intel Atom, Intel Core, and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. * Other names and brands may be claimed as the property of others. Copyright © 2011, Intel Corporation. All rights reserved.
BLDK PRC Training 2011

3. UEFI / PI Training Handout
March 31, 2010
Agenda
BIOS Background
UEFI Overview
Platform Initialization (PI) Overview
Describe Background and History of Unified Extensible Interface (UEFI) and Intel® Platform Innovation Framework for UEFI
Introduce fundamental principles of UEFI architecture and the  implementation where they are used
Describe the UEFI  boot sequence and the details of the different phases (PEI, DXE, BDS, EFI shell)
Describe the Development Environment
Unified Extensible Firmware Interface (UEFI) & Platform Initialization (PI) Overview

4. BIOS background
What’s Legacy BIOS
Basic Input - Output System for original IBM PC/XT and PC/AT
Originated in 1980s
Based on 8086 architecture
A group of clearly defined OS-independent interface for hardware
Int10 for Video service
Int13 disk service
Int16 keyboard service
Int18 BIOS ROM loader
Int19 bootstrap loader
Availability of MS-DOS outside of IBM allowed applications to run equally well across different brands of box "PC clones".
When BIOS was invented they were going to sell it (250,000 units) and then obsolete it.
This 16 bit BIOS has come a long way, but legacy bios is out-of –date, ad hoc, unspecified, and extended beyond the original design.

5. EFI / UEFI History Timeline
BIOS background
EFI / UEFI History Timeline
PCI Spec
framework1 0.9 Spec
PC Era
1980s
Intel® Itanium® Platforms 64 bit develops
EFI 1.02
EFI 1.10
Specifications
2005
2000
1995
1990
1985
IBM 16 Bit BIOS
EFI only way to boot Itanium® Platforms
EFI Dev
Kit
(EDK)
EFI Sample Implementation x
EFI 1.10 Spec – Dec 2002
UEFI 2.0 Jan 2006
Platform Initialization 1.0 Aug 2006
PI 1.1 Oct 2007
UEFI 2.2 Oct 2008
Shell Oct 2008
Implementation
Tianocore.org Open Source
Open Source EFI Developer Kit (EDK)
UEFI Specifications -

6. UEFI Specification Timeline
BIOS background
UEFI Specification Timeline
UEFI 2.0
UEFI 2.1
UEFI 2.2
UEFI 2.3
Specifications
PI 1.0
PI 1.1
PI 1.2
Shell 2.0
Packaging 1.0
2010
2009
2008
2007
2006
SCT UEFI 2.0
SCT UEFI 2.1
Implementation
EDK 1.01: UEFI 2.0
EDK 1.04: UEFI 2.1
PI 1.0
EDK 1.05: UEFI 2.1+
PI 1.0
The UEFI Forum is responsible for both specifications and the Self Conformance Tests used to verify interface conformance to the Specifications.
The upper markers indicate the timeline of UEFI and Platform Initialization (PI) Specification approval, starting with the UEFI 2.0 Specification approved in Early 2006 (the EFI used the 1.x versions, so UEFI started at 2.0), and the PI 1.0 Specification (August of 2006).
The timeframe of the specification approval is controlled by the UEFI Forum’s process for developing approving specifications. There is no formal timeframe or specification schedule. Instead, specifications are developed and approved per the committee process as new topics are discovered, understood, agreed upon, and approved.
The important thing to recognize form this slide, is the ongoing development and improvement of the UEFI specification.
The Implementation to the specification followed about a year after Specification approval, with the SCT following about 6 months after that. This is normal because one must have a implementation to test against in order to test a platform for compliance.
For further details on the Specifications and the nature of improvements from 2.0 to 2.3, please visit the UEFI Forums website (UEFI.org) and review the specification’s changes logs.
UDK2010
SCT
PI 1.0
EDK II: UEFI 2.1+
PI 1.0
EDK II: UEFI 2.3+
PI 1.2+
Open Source
All products, dates, and programs are based on current expectations and subject to change without notice. 6

7. Agenda BIOS Background UEFI Overview
Platform Initialization (PI) Overview

8. UEFI / PI Training Handout
UEFI Overview
March 31, 2010
What is UEFI? OS
Loader
Unified (EFI) / Extensible Firmware Interface (EFI)
UEFI is an interface specification
Abstracts BIOS from OS
Decouples development
Compatible by design
Evolution, not revolution
Modular and extensible
OS-Neutral value add
Provide efficient Option ROM Replacement
Common source for multiple CPU architectures
Complements existing interfaces
Compatibility
UEFI
BIOS
Hardware
What is UEFI
It is based on the
Extensible Firmware Interface from Intel
The Unified Extensible Firmware Interface Specification (UEFI) is an outcome of the UEFI Forum, a non-profit collaborative trade organization formed to promote and manage the UEFI standard.
Compatible by design
Evolution, not revolution
The Major design points are that EFI needs
1. to work with ACPI as on legacy because there is a big investment in ACPI and we did not want to throw that away.
2. everything in UEFI booting to be backwards compatible
3 to not boot from the magic boot sector. We boot to the media which allows us to boot media CDs, Floppies, Hard drives that can boot both UEFI and IA32 at the same time.
You can even boot IA32, Itanium EFI, Xscale EFI and legacy BIOS all off the same boot media
UEFI is an Interface specification
Abstracts Platform from OS
The Specification was written from the perspective of lets
“Tell the OS what to do instead of having the OS tell the platform what to do.”
UEFI includes modular driver model and CPU-independent option ROMs
There are issues with option ROMs and 16bitness
There is a big push to go to something that will help in this arena
Modular and extensible
Intel and other companies have many initiatives. They continue to add features and functionality.
Intel wanted to make sure there was a clean way to add in interfaces.
And Intel worked to ensure that nothing like ACPI or SMBios are made obsolete.
This provides the flexibility to meet the current and future needs
UEFI is OS-Neutral value add
It complements existing interfaces
UEFI was designed to support backwards compatibility
_______________________________
Note: RAS = Reliability + Availability + Serviceability *
UEFI / PI Overview

9. UEFI / PI Training Handout
UEFI Overview
March 31, 2010
Concept
OPERATING SYSTEM
Legacy OS LOADER
UEFI OS LOADER
UEFI API
UEFI BOOT SERVICES
UEFI
RUNTIME
SERVICES
Compatibility
UEFI or PI
Drivers
Driver
Driver
Memory
Timer
Boot
Devices
Protocols +
Handlers
(OTHER)
SMBIOS
ACPI
INTERFACES
FROM
OTHER
REQUIRED
SPECS
PLATFORM SPECIFIC FIRMWARE
PLATFORM HARDWARE
UEFI OS
Loader
UEFI SYSTEM
PARTITION
UEFI
Drivers
OS PARTITION
Motherboard
ROM/FLASH
Option
ROM
Option
ROM
[NOTE: open up & condense (click text box)]
This slide illustrates the interactions of the various components a UEFI specification-compliant
system uses to accomplish platform and OS boot.
The platform firmware is able to retrieve the OS loader image from the System Partition.
The specification provides for a variety of mass storage device types including disk, CD-ROM, DVD and remote boot via a network.
Through the extensible protocol interfaces, it is possible to add other boot media types. These may require OS loader modifications if they require use of protocols other than those defined in this document.
Once started, the OS loader continues to boot the complete operating system. To do so, it may use
the EFI boot services and interfaces defined by this or other required specifications to survey, comprehend, and initialize the various platform components and the OS software that manages
them. EFI runtime services are also available to the OS loader during the boot phase.
The basic take away is that UEFI is actually an interface specification
{ENTER}
The platform firmware produces this set (point to the box below UEFI Boot Services)
The closet thing to legacy is the “Int” interfaces like Int 10 int 16 Int 13
In UEFI there are a set of defined interfaces like the UEFI OS Loader, pre boot applications
{point to OS loader}
There is also a new extensible mechanism to support option ROMs that will work across multiple processors
{point to Option ROM}
Regarding the framework: It is all about is you producing a system that has all of these UEFI interfaces
The UEFI Spec itself is just an API
How does one component talk to another
How does the OS loader talk to the platform
How does the Option ROM talk to the platform
How does the utility talk to the platform
That’s what UEFI is all about
This slide shows the principal components of UEFI and their relationship to platform hardware and OS software
This Slide illustrates the interactions of the various components of an UEFI specification-compliant system that are used to accomplish platform and OS boot.
The platform firmware is able to retrieve the OS loader image from the System Partition. The specification provides for a variety of mass storage device types including disk, CD-ROM, and DVD as well as remote boot via a network. Through the extensible protocol interfaces, it is possible to add other boot media types, although these may require OS loader modifications if they require use of protocols other than those defined in this document.
Once started, the OS loader continues to boot the complete operating system. To do so, it may use the EFI boot services and interfaces defined by this or other required specifications to survey,
Option
ROM
UEFI Drivers
UEFI
Drivers *
UEFI / PI Overview

10. Unified EFI (UEFI) Forum – www.uefi.org
UEFI / PI Training Handout
UEFI Overview
March 31, 2010
Unified EFI (UEFI) Forum –
Promoters
OEMs: Dell, HP, IBM, Lenovo
IBVs: AMI, Insyde, Phoenix
AMD, Apple, Intel, Microsoft
UEFI Specification
EFI 1.10 specification contributed to the Forum by Intel and Microsoft to be used as a starting draft
UEFI specification released.
Forum will evolve, extend, and add any new functionality as required
Intel contributed EFI 1.10 SCT being used as starting base for UEFI conformance tests (UEFI SCT 2.1 released 2008)
The UEFI Forum is a forum of industry partners (and competitors) working together to establish and industry wide standard for firmware framework and features.
The UEFI Forum is creating a standard and extensible firmware technology that can provide support for the industry for years to come.
Purpose: Worldwide adoption and promotion of UEFI specifications. *
UEFI / PI Overview

11. UEFI / PI Training Handout
UEFI Overview
UEFI / PI Training Handout
March 31, 2010
UEFI Membership
Any entity wanting to implement the specification
Adopters:
Corporations, groups or individuals wanting to participate in UEFI
Chance to join work groups and contribute to spec or test development
Early access to drafts and work in progress
Contributors:
Board and Corporate Officers
Promoters:
UEFI / PI Overview 11 11

12. Boot device support Hard disk Removable media Network
Boot Support
Boot device support
Hard disk
Removable media
CD-ROM, DVD-ROM
El Torito 1.0 “No emulation”
Floppy, USB Storage, etc.
Network
PXE BIOS support specification (Wire for Management)
iSCSI
Future media via extensibility methods
UEFI specification provides for a robust set of possible boot devices:
Hard drives, CDs, DVDs, Floppy, USB storage devices, and several implementations of Network booting are all currently available under UEFI.
More importantly, the UEFI specification is “Extensible” in nature. As new bootable devices are developed, UEFI can be extended to support them without impacting the current device list.
When the PC was first developed, there were only two standard booting devices available, the floppy drive and the Cassette Tape interface. The addition of each new boot device beyond these carried with it new problems and issues, and the removal of support for obsolete boot devices also caused difficulties as well. Since rthe UEFI is designed for flexibility, the future addition and removal of boot devices from the architecture is already considered and planned.
Full Device Support

13. New Partition Structure
UEFI / PI Training Handout
Boot Support
March 31, 2010
New Partition Structure
First useable block
Start partition
End partition
LBA0
LBA1
LBAn
...
MBR
Table HDR
Partition 1 n
Partition 1
Table HDR
Partition
... 1 n
EFI eliminates size limit issues and provides redundant information.
EFI allows a hard drive to have multiple partitions and to have more than one system partition, allowing multiple operating systems to exist. EFI reads only FAT-formatted partitions. Non-FAT partitions are recognized as other block devices, but EFI cannot read them.
EFI can read a drive's Master Boot Record (MBR) and recognizes FAT32 partitions without a GUID, caused by not being partitioned with EFI disk tools.
With the new EFI partition scheme, you can create an unlimited number of disk partitions, with multiple system partitions on the same disk.
EFI provides two partition headers: a primary header and backup header. This allows hard drive restoration applications developed for EFI to easily restore a hard drive.
An EFI system partition can be created by an EFI-aware OS installer or with disk utilities
Diskpart, EFIfmt, Efichk  
On the web site go to Tools and then Disk utilities
EFI requires the firmware to be able to parse legacy master boot records MBR and the new GUID Partition
Table (GPT) logical device volumes. The EFI firmware produces a logical
BLOCK_IO device for each EFI Partition Entry or if no EFI Partition Table is present any partitions found in the partition tables. Logical block address zero of the BLOCK_IO device will correspond to the first logical block of the partition.
EFI defines a new partitioning scheme that must be supported by EFI firmware. The advantages of using the GUID Partition Table over the legacy MBR partition table:
128 Bit Unique Identifier and unique serial number
Supports many partitions unlike MBR
Uses a primary and backup table for redundancy.
It is a superset of MBR boot sector
Start partition
End partition
Last useable block
Primary Partition
Table
Backup Partition
Table
See Section-5 UEFI 2.X Spec.
UEFI / PI Overview 13

14. GPT Advantages over MBR Partition Table
Boot Support
GPT Advantages over MBR Partition Table
64-bit Logical Block Addressing.
Supports unlimited number of partitions
Uses a primary and backup table for redundancy.
Uses version number and size fields for future expansion.
Uses CRC32 fields for improved data integrity.
Defines a GUID for uniquely identifying each partition.
Uses a GUID and attributes to define partition content type.
Each partition contains a 36 Unicode character human readable name.
No magic code must execute as part of booting
Fixes the 2.2 Terabyte Problem
The GPT has many significant advantages over the MBR Partition Table.
Most notably, the GPT is not constrained to a limited number of partitions or a maximum disk size for operation. Nor does it require special “proprietary” code to allow booting from an individual partition.
The 2.2 Terabyte problem became serious with the advent of drives with over 2.2 TB of storage capacity. GPT provides cannot address drive space greater than 2.2 TB, creating a short fall in the drive subsystem (users pay for more than 2.2 TB of disk, but can only access the 2.2 TB). GPT resolves that limitation.
GPT is well designed for reliability with redundant tables, CRC fields, Guid usage for partition recognition, and the ability to name each partition with a human readable name of up to 36 characters.
GPT is designed to provide support for additional future features.

15. UEFI Specification - Key Concepts
UEFI Terminology
UEFI / PI Training Handout
March 31, 2010
UEFI Specification - Key Concepts
Objects - manage system state, including I/O devices, memory, and events
The UEFI System Table - data structure with data in-formation tables to interface with the systems
Handle database and protocols - callable interfaces that are registered
UEFI images - the executable content format
Events - the software can be signaled in response to some other activity
Device paths - a data structure that describes the hardware location of an entity
Objects managed by EFI-based firmware - used to manage system state, including I/O devices, memory, and events
The UEFI System Table - the primary data structure with data in-formation tables and function calls to interface with the systems
Handle database and protocols - the means by which callable interfaces are registered
UEFI images - the executable content format by which code is deployed
Events - the means by which software can be signaled in response to some other activity
Device paths - a data structure that describes the hardware location of an entity, such as the bus, spindle, partition, and file name of an UEFI image on a formatted disk.
UEFI / PI Overview

16. UEFI Data Structures - UEFI System Table
UEFI / PI Training Handout
UEFI Terminology
March 31, 2010
UEFI Data Structures - UEFI System Table
Input Console
Active Consoles
Output Console
Standard Error Console
EFI System Table
EFI Runtime Services Table
Variable Services
Real Time Clock Services
Reset Services
Status Code Services
Virtual Memory Services
EFI Boot Services Table
Task Priority Level Services
Memory Services
Event and Timer Services
Protocol Handler Services
Image Services
Driver Support Services
Version Information
EFI Specification Version
Firmware Vendor
Firmware Revision
Handle Database
The EFI System Table contains all the information needed to utilize the services firmware Core, and the services provided by any previously loaded UEFI Compliant drivers.
The EFI System Table provides access to all the active console devices in the platform. It provides access to EFI Configuration Tables.
It includes the handle database. Any executable image can access the handle database for any of the protocol interfaces.
When the transition to the OS runtime is performed, the handle database, active consoles, EFI Boot Services, and services provided by boot service DXE drivers are terminated. This frees up more memory for use by the OS, and leaves the EFI System Table, EFI Runtime Services Table, and the system configuration tables available in the OS runtime environment.
Per the UEFI specification, there are boot-time services and runtime services. There is handle database and a list of all the protocols that these handles have associated with them. Of course, keep in mind that all these will be gone from memory when the OS has booted. The only things that will remain are the runtime services after an UEFI OS a-where is loaded
There is also the option of converting all of the EFI Runtime Services from a physical address space to an OS-specific virtual address space. This address space conversion may only be performed once.
Protocol Interface
Protocol Interface
Boot Service Data Structures
Runtime Data Structures
UEFI / PI Overview

17. UEFI / PI Training Handout
UEFI Terminology
March 31, 2010
GUID
“Globally” Unique Identity
128-bit quantity defined by Wired for Management WfM 2.0 specification **
Used to identify protocols
1:1 with interfaces
Regulate extension mechanism
Documented in the spec
Added through drivers
To make sure we have interoperability and to make sure extensions do not interfere with one another, UEFI uses GUID or Globally Unique Identifier concept.
It is a 128 Bit quantity or ID
The utility GENGUID is the tool to generate a new GUID. This is what UEFI uses to identify it’s protocols, partitions, file image system, etc. Since it’s guaranteed to be unique, users can add items without fear of conflict.
There will not be any collisions until 2034
The key here is that these GUIDs allow safe co-existence
Safe co-existence of 3rd party extensions **
UEFI / PI Overview

18. UEFI Means the Pieces all Fit and Work!
Legacy BIOS vs UEFI
Legacy BIOS
INT 10h
INT 13h
Chaining
INT 16h
INT 15h ?
GUID3
GUID2
GUID1
GUID5
GUID4
UEFI
UEFI
GUID1 UEFI Specification
GUID2 PI Specification
GUID3 ODM defined
GUID4 OEM defined
GUID5 IBV defined
Legacy BIOS was previously configured by setting up the “Int” interfaces
Such as Int 10, Int 13, Int 16 or Int 15.
This method does not have one common place or repository defined
The Ralf Brown List contains a list of the legacy “Int”
BUT things are just wrong: this int conflicts with that int
This extension for this memory size conflicts with that extension for memory size, etc.
OR you can only abstract one video device because of Int 10 only works for one device
<ENTER>
UEFI uses GUIDs to allow users to continue to add interfaces with no collisions
For example, in the UEFI Specification there is a set of GUIDs that define these protocols or APIs
In the Framework specification there are more Protocols defined and those are GUIDs that came from the Framework team .
OEMs and ODMs can define their own GUIDs and interfaces and protocols. They are guaranteed these will never conflict because the GUIDs have unique IDs.
Because we make a unique handle for each device, we no longer have them all chaining into Int 13. Now we can have multiple video devices, or we can have multiple console devices.
That is the reason behind why we have Handles and GUIDs for these protocols – APIs—now lets explore those definitions . . .
Ralf Brown’s
Interrupt List
UEFI Means the Pieces all Fit and Work!

19. UEFI / PI Training Handout
UEFI Terminology
UEFI / PI Training Handout
March 31, 2010
Handles
All protocols have a handle which is associated with the protocol
Every device and executable image in UEFI has a handle protocol in the handle database
Every boot device must have a device path protocol to describe it
UEFI uses Handles, a common concept in software
We use handles to uniquely define interfaces
Every API or Protocol that is registered in the system will be sitting on a handle
Every Image that we load will be sitting on a handle
There are also Handles to allow you to associate API – protocols together
And one of the most common things we use is a device path
A device path is a API – Protocol or data structure that lets you know where you want to boot from
So you might have a single handle with a block I/O interface on it to allow you to read from the disk. It would also have a device path protocol on it to let you know from which disk it needs to be extracted.
A handle points to a list of one or more protocols that can respond to requests for services for a given device referred to by the handle
UEFI / PI Overview

20. UEFI / PI Training Handout
UEFI Terminology
March 31, 2010
Protocols (API)
GUID, Interface Structure, Services
DEVICE_PATH, DEVICE_IO, BLOCK_IO, DISK_IO, FILE_SYSTEM, SIMPLE_INPUT, SIMPLE_TEXT_OUTPUT, SERIAL_IO, PXE_BC, SIMPLE_NETWORK, LOAD_FILE, UNICODE_COLLATION
Handle
GUID
GUID 1
Protocol Interface
Function 1
Access
Device or
Services
Produced by
Other UEFI
Drivers
Function Ptr 1
Function Ptr 2
Function 2
. . .
Private Data
SLIDE SHOWS
A single handle and protocol from the handle data-base that is produced by an UEFI driver. The protocol is composed of a GUID and a protocol interface structure. Many times, the UEFI driver that produces a protocol interface maintains additional private data fields. The protocol interface structure itself simply contains pointers to the protocol function. The protocol functions are actually contained within the UEFI driver. An UEFI driver might produce one protocol or many protocols depending on the driver’s complexity.
-----
“Protocols” can be a confusing term, but a protocol is a really simple thing. A protocol is just an API, just a “C” callable interface.
We have mechanism for dynamically registering these APIs
A protocol is a lot like “C” implementing “C++” concepts
So we just have a structure that has function pointers with number functions
{point to the Function pointer}
We pass in a pointer to the function and there is also a way to have private data with each protocol
So a protocol is like doing “C++” like things in “C” nothing really complicated
{point to the diagram}
A lot of the UEFI Specification will define a set of protocols that are going to exist on a system
So if a person is writing a OS loader they know what interfaces to consume
If they are writing an Option ROM you know what interfaces you have to produce
For A Hard disk your option ROM will produce a block IO interface
. . .
GUID 2
. . .
BlkIo->ReadBlocks(BlkIo, …)
UEFI / PI Overview

21. Handle Protocol Database
UEFI Terminology
UEFI / PI Training Handout
March 31, 2010
Handle Protocol Database
...
Handle
First Handle
GUID
Protocol
Interface
Instance
Data
Image Handle
Controller Handle
Attributes
This slide shows a portion of the handle database. In addition to the handles and protocols, a list of objects is associated with each protocol. This list is used to track agents are consuming a specific protocol. This information is critical to the operation of UEFI drivers, because this information is what allows UEFI drivers to be safely loaded, started, stopped, and unloaded without any resource conflicts.
Putting it all together, in UEFI we use a Handle database
UEFI allows multiple protocols on a given handle
The only rule is all the GUIDs must be different
Example:
If you have 2 block I/O devices – 2 disks;
Each block I/O protocol will be on a different handle;
When you register the block I/O device, that’s when the handle is created
UEFI / PI Overview

22. UEFI / PI Training Handout
UEFI Terminology
March 31, 2010
Device Path Protocol
A data structure description of where a device is in the platform
All boot devices, logical devices and images must be described by a device path
6 types of device paths:
Hardware
ACPI – UID/HID of device in AML
Messaging – i.e. LAN, Fiber Channel, ATAPI, SCSI, USB
Media – i.e. Hard Drive, Floppy or CD-ROM
EDD 3.0 boot device – see EDD 3.0 spec int13 48
End of hardware – marks end of device path
Regarding the device path protocol:
It is important for the device path protocol to have the OS tell the platform what the boot device is
We need a way for the OS to tell the platform were to boot from.
When the UEFI BIOS comes up to boot, it only has to turn on the devices that it knows it must boot from
This makes a great difference on servers with many attached devices to boot from
To describe hardware we have 6 types of Device Paths. The device path needs to sit in NVRAM and it needs to be correct even if the system gets reset
For UEFI these devices paths describe
Hardware – as in, where in the system it shows up
ACPI –describes the ACPI name space – we want to work with ACPI and not redefine ACPI or require ACPI to change
Messaging – for things like LAN, Fiber channel, ATAPI, SCSI, USB – think of the messaging device path as another bus in your system; one that bus defines a new way of looking at devices –For example in IDE that is like primary secondary – master, slave – that would be the extra messaging that needs to be sent across to make it work.
Media device path –the location on a hard drive, Floppy or CD-ROM. We must have coexistence – so we do not boot from a magic location sector zero. On a device we actually boot from a file or from any partition – so we have device paths that explain partitions whether they are Eltorito or hard disk partitions
EDD 3.0 boot devices – this is a legacy BIOS, to allow us to layer UEFI or the Framework on top of legacy option ROMS
And we also have a device path entry that explains the End of the device path – because we do not know how the length of the device path – it is just a sequence of data structures with one at the end that says “this is the last entry”.
See Section-9 UEFI 2.X Spec.
UEFI / PI Overview

23. * An UEFI Device Path describes a boot target.
UEFI Terminology
Why UEFI Device Path ? –
An UEFI Device Path describes a boot target.
Binary description of the physical location of a specific target.
Acpi(PNP0A03,0) /Pci(1F|1) /Ata(Primary,Master) /HD(Part3, Sig010…) \EFI\Boot”/”OSLoader.efi”
Acpi(PNP0A03,0) /Pci(1F|1)
Acpi(PNP0A03,0) /Pci(1F|1) /Ata(Primary,Master) /HD(Part3, Sig010…) \EFI\Boot”/”OSLoader.efi”
Acpi(PNP0A03,0) /Pci(1F|1) /Ata(Primary,Master) /HD(Part3, Sig010…)
Acpi(PNP0A03,0)
Acpi(PNP0A03,0) /Pci(1F|1) /Ata(Primary,Master)
Initialize the
Partition Driver
Initialize PCI
Device
Connect PCI
Root Bridge &
Install OP ROM
Initialize ATA
Device
Connect Consoles
Initialize PCI
root Bridge
Boot Sequence
The use of device paths allows the system resources to be defined in terms of connections between hardware devices, and the “pathways” the processor must follow to get to those devices.
(NOTE: This slide REALLY has to be seen as a build slide, each step is very important in the overall under standing of the process. However, the animation (line chagne from RED to black and back is not necessary and not included in this breakdown)
This includes the pathway to a specific boot device.
The Boot target is the OS loader UEFI Application located on the third partition of the Master drive on the primary ATA controller off of the PCI Device 1Fh, function #1, off of the primary PCI host bridge (Bus zero). This is how we would refer to this target, starting form the target working back to the processor, in UEFI, the target is defined starting from the processor, as devices are discovered and drivers are loaded in the boot process.
In the Example:
Starting from the beginning, The initialization of the PCI Root Bridge is a one of the fundamental steps in system initialization, Many hardware components are attached to the PCI bus, and this step is necessary to discover all subsequent devices on the PCI bus. In the example, the PNP ID found is associated with the Root PCI device in the system (the Northbridge/Southbridge pair, or the equivalent). This establishes the basis of PCI BUS zero and the root for additional PCI devices (and buses).
<ENTER>
On PCI Bus zero, there exists (device 1Fh, Function 1) and IDE controller. This device discovered and initialized by a driver to initialize PCI devices. Note: this process is part of PCI initialization, it initialized the controller, but is not concerned with any “children” devices attached (downstream) to the controller, this will be handled later.
The devices on the IDE controller are now being initialized. An ATA driver is associated with the drives, and the the Primary Master disk drive is now initialized.
This occurs at the same time the system consoles are established (near boot device select timeframe). This is important, as the HDD will not be initialize in the Pre-boot flow, unless it is the current “Targeted Boot Device” or the user has selected “Setup” as the boot path.
If the HDD is the Current targeted device, then it has to be initialized to be able to use for boot (obviously). However, if the system does not need the device to attempt the boot, then it will not waste time initializing a device that is not necessary.
In the case of setup, the system is not ‘booting’ to an OS, but rather the user is configuring the systems options. It is therefore necessary for all system options (hardware) to be initialized, so the user has a complete and accurate inventory to work with in the configuration process.
The drive was initialized in the last step, but drives may contain several partitions (in this case, the partition of interest is Partition 3), so a partition driver is associated to point to the proper partition on the drive.
The final stage in following the path, is to access the files on the target partition and load the Boot loader program.
File access is handled by a File system driver, which has to be initialized for the drive and partition targeted (Primary Master ATA, Partition #3). Once initialized, the file structure can be parsed, the the boot loader file (OSLoader.efi) can be loaded into memory and executed.
This begins the launch of the OS, and the transition state for the boot firmware to the operating system.
However, now that the process is underway, there is still the software process of booting the OS. The OS loader will ensure that the system is capable of booting the OS by running diagnostics (at least to ensure that the OS image on the disk is viable to boot an OS). IF the diagnostics fail, the OS loader can return the system to the firmware, to allow it to attempt to boot from the next boot target in the list of ‘bootable devices”.
Assuming a complete and successful execution of Diagnostics, the OS loader will load the OS code, and the Boot process will complete as part of the OS’s function.
This Boot of the operating system was initiated, and successful, starting from a a simple path defining the device (location) from which to boot, and ending with a viable OS execution on the platfrom.
Initialize File
System Driver
Diagnostics/Shell
Note: Boot Sequence
is part of the PI Spec.
Launch O/S
Loader
Boot *

24. RT Services are Minimal set to meet OSV needs
UEFI / PI Training Handout
March 31, 2010
Boot Services
Runtime Services
Available at both Boot time and Runtime
Events and notifications
Polled devices, no interrupts
Watchdog timer
Elegant recovery
Memory allocation
Handle location – for finding protocols
Image loading
Drivers, applications, OS loader
Timer, Wakeup alarm
Allows system to wake up or power on at a set time.
Variables
Boot manager handshake
System reset
ExitBootServices()
Boot Services only exist during boot time when the firmware owns the entire system.
We make a handoff in UEFI using a call named “EXIT BOOT SERVICES”. When the OS wants to take over it, calls “exit boot services” and then the boot services go away and the OS device drivers take over from that point.
In the pre-boot space we have pre-boot services for :
Event Notifications –deal with polled devices or no interrupts. This is how we inform that certain protocols or APIs have been added to the system so if they might need to some work
Watch Dog Timer – that gets specified so when one these modular chunks of code gets loaded and has a problem the watch dog timer will fire and system will know there is a problem and do a elegant recovery.
UEFI also has a centralized place to perform Memory Allocation so that it is performed in one place to avoid creating no conflicts.
UEFI uses the handle database and Handle Location services to register and find Protocols and APIs.
Images are drivers, applications or OS loaders, and in UEFI all of our images are PE32. UEFI has a set of services for Loading Images ––– that is the standard image type that is constructed by Microsoft tools and Microsoft “C” complier
On the Microsoft web site are two specifications searchable by the keyword “UEFI”–the definition of PE32 or the PE32+ which is the 64bit version which is the image for UEFI
and
the specification of how FAT works for UEFI. Note that the file system partition for UEFI support is FAT.
UEFI also has a set of Runtime Services
When UEFI started out the UEFI architects and designers did not want to have a lot of runtime services because when they talked to the OS vendors, the OS Vendors had a lot of issues and problems with so many platforms they have to support.
If the code tries to run under them from the platform in the BIOS while the OS is running it is very difficult to debug these problems –
so when Intel was talking to all the OS vendors for Itanium they really thought that a large number of BIOS service or firmware services in the OS was not a good idea.
When the UEFI spec was started there was only one set of services, which were these variable services. These are similar to an environment variable – they exist after the OS has booted so that the OS can set the boot policy.
In reference to device paths, using the ACPI table the OS can determine the device path to various boot devices and set the now NVRAM using the variable service, which enables UEFI at the next boot up to set the boot policy set by the OS.
The other service that the OS vendors ended up actually asking us for was a way to extract the Timer and the Wakeup Alarm and also to do a system Reset
Summary
UEFI Services were targeted on making an abstraction of OS Loaders, to make the OS loaders clean.
Everything in UEFI is based on a protocol or API – there is no assumed hardware devices
For example,
there is no assumption of a 8259 in the system
there is no assumption there is a VGA hardware in the system
UEFI Aware OS
RT Services are Minimal set to meet OSV needs *
UEFI / PI Overview 24

25. Typical System USB Bus USB CPU IDE Bus IDE VGA ISA Bus PCI Bus Other
UEFI Driver Design
Typical System
CPU
PCI Host
Bus
USB
IDE
PCI-ISA
Bridge
VGA
Keyboard
Mouse
Floppy
Drive
Hard
CD-ROM
PCI Bus
USB Bus
ISA Bus
IDE Bus
Device Controller
Bus Controller
Other
ISA
FDC
PCI-PCMCIA
Manageable by UEFI Driver Model
One key assumption is that the architecture of a system can be viewed as a set of one or more processors
connected to one or more core chipsets. The core chipsets are responsible for producing one or more
I/O buses.
The UEFI Driver Model does not attempt to describe the processors or the core chipsets.
Instead, the UEFI Driver Model describes the set of I/O buses produced by the core chipsets, and any
children of these I/O buses.
These children can either be devices or additional I/O buses. This can be
visualized as a tree of buses and devices with the core chipsets at the root of that tree.
The leaf nodes in this tree structure are peripherals that perform some type of I/O. These could include
keyboards, displays, disks, network, etc. The non-leaf nodes are the buses that move data between
devices and buses, or between different bus types.
This Slide is an example of a more complex server system. This system contains six buses and eight devices.
The UEFI Driver Model is simple and extensible so that complex systems like this one can be described and
managed in the preboot environment.
The combination of firmware services, bus drivers, and device drivers in any given platform is likely
to be produced by a wide variety of vendors including OEMs, IBVs, and IHVs. These different
components from different vendors are required to work together to produce a protocol for an I/O
device than can be used to boot a UEFI compliant operating system.
As a result, the UEFI Driver Model needs to be understood in great detail in order to increase the interoperability of these components.
See Section-2.5 UEFI 2.X Spec.

26. Driver Initialization
UEFI Driver Design
UEFI / PI Training Handout
March 31, 2010
Driver Initialization
UEFI Driver Handoff State
Not Allowed to Touch Hardware Resources
Installs Driver Binding on Driver Image Handle
Created by LoadImage()
Driver Image Handle
Installed in Driver Initialization
Implemented by Driver Writer
EFI_DRIVER_BINDING
EFI_COMPONENT_NAME
When the Driver Initializes, EFI hands off information that calls the driver.
The driver is a PE32 image that gets loaded into memory. The PE32 Image is a re-locatable image format so that image can be loaded anywhere in memory. So even on Itanium systems it can get loaded up above 4 Gigs anywhere there is free memory.
Generally when the Driver initializes the driver does not touch any hardware –
All the driver does is install this API called driver binding protocol or API
The basics supported to this API are functions Start() , Stop() , for this EFI binding protocol
And when a EFI driver loads all it does is register this interface.
This is one of the reasons we can get this very quick boot time because whenever you load all the option ROMs they do not do anything – they just register a service.
They do not touch hardware – which if they did would take a lot of time so they go really fast.
It is up to the platform BIOS writer or whoever set the policy on the platform to decide which drivers to start.
Multiple Drivers can even exist that can control the same hardware device and set the policy in the platform as to which driver you want to use.
In summary, register a driver so that it can be used later.
Registers Driver for Later Use
UEFI / PI Overview

27. Driver Binding Protocol
UEFI Driver Design
Driver Binding Protocol
Driver Image Handle
LOADED_IMAGE
DRIVER_BINDING
DRIVER_BINDING
Supported()
Start()
Stop()
Version
The Driver Binding Protocol is a very important concept in the operation of UEFI device drivers.
When a Driver is loaded, an image handle is created to track the driver within the UEFI stack. (Remember that everything under UEFI control is dynamically assigned a handle for record keeping and tracking purposes)
The Driver Image Handle includes pointer to the loaded image in memory, which can be populated at the time, as the location of the driver in memory is known when the driver is loaded. The Driver Image handle also contains a point for the Driver Binding protocol. However, this pointer cannot be populated at driver load time, as the loader has no way of determining where the protocol is located within the driver image.
The entry point to the drive is known (per standard), and therefore it becomes the responsibility of the driver to establish its driver Binding protocol in the Driver image handle as a function of the driver initialization process…
<ENTER>
This provides for use of the Driver binding fuctions and data later in the process, when device drivers are tested for and assigned to hardware device support. *

28. Example: UEFI ATAPI Driver Stack
UEFI Driver Design
Example: UEFI ATAPI Driver Stack
HD Handle
File System
Protocol(FAT)
HandleProtocol()
Device Path
Protocol
Disk IO
Protocol
UEFI boot services
Block IO
Protocol
ATAPI Device Path
ACPI(pnp0604,0)/PCI(0,1)/
ATA(primary, master)
UEFI ATAPI
Driver
Image Handle
Putting this together: What does a driver ‘stack’ look like in the UEFI system.
Starting with the Handle for a device. The handle contains a pointer, pointing to the device path for the device. The path provides a description of the devices location in the system relative to the path of hardware devices to reach the ‘target device’. In this example the device is the Primary Master ATA controller off the PCI device 0, Function 1 of the root PCI controller.
The handle also points to the Block IO protocol, Disk IO Protocol and File System Protocol associated with the drive.
The UEFI ATAPI driver will associate the disk drive device (UEFI system partition) with the controller device. The ATAPI driver has an image Handle, with a Device path Protocol that defines the Path to the partition level (example Partition #3).
partition
system
UEFI
IDE ATAPI
disk drive
Device Path
Protocol

29. Agenda BIOS Background UEFI Overview
Platform Initialization (PI) Overview

30. Technology not addressed by UEFI
UEFI / PI Training Handout
Technology not addressed by UEFI
March 31, 2010
Technology not addressed by UEFI
Memory Initialization
Recovery
FLASH update
ACPI S3
Platform Initialization
System Management Mode (SMM)
Setup
For example, there are many technologies that are not addressed by UEFI
They are not addressed by UEFI because BIOS engineers continually come up with creative methods that do not necessarily need to be standardized in a specification.
UEFI does not define :
Memory Initialization
Recovery
Flash update
ACPI S3
Platform Initialization
SMM
BIOS Setup
All these things were left out of UEFI, because UEFI is a API specification, specifically targeting option ROMS and OS vendors
The OS vendors should not be involved with defining exactly how all of these technologies work.
IF it is a good idea to get the OS vendors involved then that can be addressed in the UEFI forum.
UEFI Separates BIOS and OS
UEFI / PI Overview

31. USWG/PIWG Relationship
UEFI and PI Specifications
USWG/PIWG Relationship
UEFI
UEFI Spec is about interfaces between OS, add-in driver and system firmware
a new model for the interface between the Operating systems and other high-level software and the platform firmware
PI Specs relate to making UEFI implementations
Promote interoperability between firmware components providers
Modular components like silicon drivers (e.g. PCI) and value-add drivers (security)
UEFI-
enabled OS
Pre-boot
Tools
Option
ROMs
Legacy OS
DXE Driver
UEFI Driver
UEFI Driver
UEFI Driver
BDS
Compatibility Support Module
• • •
Platform Initialization
CPU PEI
Modules
C/S PEI
Modules
UEFI is the interface between the firmware and the OS.
PI is the interface between standard firmware modules.
Hardware PI
Modular components
UEFI and PI are Independent Interfaces 31

32. UEFI / PI Training Handout
Technology not addressed by UEFI
UEFI / PI Training Handout
March 31, 2010
Intel® Platform Innovation Framework for UEFI and Platform Initialization (PI)
Base Core Foundation (“Green H”)
Foundation lets different teams share code
Developers can easily move between projects
Chipset code enabled by Silicon vendor
Standardization benefits the industry
IBV provides value add
Glue code “Big H” is Open Source on
The framework1 Start point for Platform Initialization (PI) Specification on
EFI-
enabled OS
Pre-boot
Tools
Option
ROMs
Today’s OS
UEFI
Drivers PI
OEM x/ODM y
Drivers
Drivers
IBV z
Drivers
IBV x
Compatibility Support Module A
Compatibility Support Module B
MRC - CPU
Architectural Protocols
Foundations
Instead of UEFI on top of legacy, we use the Framework as the foundation
{enter}
For the Framework the foundation code is the Big Green “H”, and we should be able to port to and from different environment to make things easier
Foundation lets different teams share code
Developers can easily move between projects
{ENTER, explain modules easily added between IBV A and IBV B}
Chipset code enabled by Silicon vendor
Standardization benefits the industry
IBV provides value add
Glue code is Open Source
Hardware
1Intel® Platform Innovation Framework for UEFI
UEFI / PI Overview

33. 1Intel® Platform Innovation Framework for UEFI
Why PI
Intel® Platform Innovation Framework for UEFI and Platform Initialization (PI) Overview
Specification time line
UEFI 2.0
UEFI 2.1
UEFI 2.2
UEFI 2.3
framework1 0.9 Spec
PI 1.0
PI 1.1
PI 1.2
Packaging 1.0
EFI 1.02
EFI 1.10
So far we have focused upon the UEFI specification from the UEFI Forum.
However there are several aspects fo platform boot and initialization that are not covered in the UEFI specification. This has always been the case.
This limitation was noticed before the UEFI Specification, and the Framework 0.9 specification was generated to record and address the limitation. In actual implementation, the solutions defined in the Framework 0.90 specification were in development and practice in the EFI 1.02 timeframe, but the specification was not made available until 2004.
It was the Framework 0.90 that acted as the starting pint of the Platform Initialization (PI) specification developed by the UEFI and approved (at 1.0 version) in This specification (like the UEFI specification), has been updated, revised, and added to over the years, and is now up to 1.2 revision level.
The PI specification is also available on the UEFI.org site provided by the UEFI forum.
Shell 2.0
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
1Intel® Platform Innovation Framework for UEFI

34. The framework1 and PI Design Strategy
Design Approach
The framework1 and PI Design Strategy
High level design based on the framework1 plus modular components
Generalize the framework1 Maximize reuse of infrastructure
High degree of independence from platform and market segment specifics
Specifics encapsulated in the drivers
Drivers map to software visible hardware
Isolate hardware/platform specifics to support component-based firmware construction
The Framework Technical Goals Were that they started off with a design point that was going to have to last another 20 years which means planning for as far as we can see.
As mentioned in the EFI overview presentation, the legacy 16 bit BIOS started off to only last a couple of years and have 250,000 products until end of life.
To make something to last the next 20 years it should be made as something to be as flexible, expandable and extendable as it possibly can.
The Framework Architects also had the idea that since Intel has multiple processor architectures they wanted to make a BIOS or firmware solution that worked with all these different types of processors
one design goal was to support IA32, Itanium, and Xscale They wanted to make sure that technology would work with the different environments.
The Framework Architects wanted to make sure it was going to be a clean, scalable, architecture
Wanted to make sure it would be Modular across Companies
They wanted a Driver-based design allowing for binary linking – this is a place where they were thinking about the future because one of the really interesting properties this has is with having these binary modules is that some of the code like the Framework big green “H” as we shall see later, can be open source and all the rest of the code and be non open source because they are independent binary modules and the licensing affects each module.
So it allows a really good mixture of different types of code and having these binary interfaces.
The Framework was designed to be “C” based with no exotic tools . The Intel “C” complier can work on the Microsoft complier just standard “C” compilers
Also with extensibility in mind, and elegance in architecture sometimes has a size cost. Sometimes software Engineers do not have an idea of the needs of the BIOS space. Where code on the hard disk is free and nobody cares about an applications size that is on the hard disk, but anything that goes into the flash cost money.
A lot engineering time and money go into making the size of the code going into the flash - smaller. Thus there was a lot of thought that went in to consider what design areas are going to be needed to meet the size and boot time requirements.
The Framework Designers did not want to force a revolutionary change either, so the design need to made accommodations for Legacy, and to Make sure there is a way to plug in modules from various BIOS vendors that could provide the same 16 bit legacy compatibility.
The Framework Design Strategy
Everything is nicely modular and well abstracted in Framework. This should reduce the difficulties when something new is implemented. As long as it adheres to the defined protocol structure, it will work. Thus, the ramp time should be significantly reduced.
Generalize the Framework
Maximize reuse of infrastructure
High degree of independence from platform and market segment specifics
So the foundation and how all the code is glued together is the same “C” code for mobile, desktop, servers and it just recompiles for Xscale and Itanium and IA32. That goal was met.
Because of this it make it easier to port different processor architectures in the future as things evolve
We tried to encapsulated Specifics in the drivers or contain a lot of the specifics in the drivers
And the Drivers will map to software visible hardware
Isolate hardware/platform specifics to support component-based firmware construction
What We mean is that there are a lot of interfaces that produce interfaces between one driver and the next and these interfaces can be well documented and are named by the GUIDs, as discussed in the EFI overview presentation so there will never be a collision and the GUID defines exactly what the interface does.
With this design it makes it difficult for the different sections of software to cross boundaries with tends to make for a cleaner design .
1Intel® Platform Innovation Framework for UEFI

35. Standard tools Flexible memory initialization
Design Approach
Get to “C” Code Quickly
Commercial “C” compilers use stack model
Requires some memory initialized for a stack
Split the framework1 and PI infrastructure in two
Pre-EFI Initialization (PEI), preamble to get memory
Driver Execution Environment (DXE), infrastructure to support “C” coded EFI drivers
First part of the framework1 / PI finds memory by using special stack
Infrastructure code plus PEI Modules
The framework1 / PI uses modules for CPU, chipset and board
Minimum initialization to get memory working
Architecture only requires “enough” memory
PEI limited so defer to rich DXE “C” environment
A programmatic goal for the Framework is to get to the “C” code as quickly as possible.
HOW to get to C code. Cannot run C out of the reset vector – no memory
One is issue is the Commercial C compilers use stack model
A stack Requires some memory initialized because in C arguments get pushed unto the stack.
For this reason the Framework architecture was split into two infrastructures – 2 main post or boot phases
One is the Pre-EFI Initialization (PEI), preamble to get to high level language environment - Finding memory
for chipset only turn on things to initialize memory but leaving I/O and other things for higher code
Only initialize enough memory
The Second is the Driver Execution Environment (DXE) phase, this is the infrastructure to support C coded EFI drivers
One of the tricks used in the Framework to get to “C” code quickly is to use a special stack.
For Intel processors we can use CACHE AS RAM and use the Cache as stack until memory get initialized.
Some processes, Sparc – some Itanium - PA RISC - just have SRAM available and that can be used for this early PEI stage as well.
In the early stage the Framework uses Minimum initialization and as few modules as possible.
the goal is to get memory working
Framework uses modules for CPU, chipset and board
Architecture only requires “enough” memory to run the Framework
It is not needed to initialize all of memory or test all of memory
The Idea is to Choose to defer complete initialization until DXE “C” code is run
One of the advantages is the boot time gets shorter – for example using the Cache for a stack – especially on Intel Chipsets BECAUSE we the code is running out of Flash, IT is SLOOOOOOW
Standard tools Flexible memory initialization

36. Architecture Execution Flow
Boot Execution Flow
Architecture Execution Flow
UEFI
Interface
Pre Verifier
OS-Absent App
CPU Init
Device, Bus, or Service Driver
Transient OS Environment
verify
Chipset Init
Board Init
Transient OS Boot Loader
EFI Driver Dispatcher
Boot Manager
OS-Present App
Intrinsic Services
Final OS Boot Loader
Final OS Environment ?
On the most basic level. Framework has these phases.
SEC is the security phase. This is the first phase after platform reset or power on to ensure that firmware integrity is intact. Not much goes on here so we will not spend a lot of time on it.
PEI stands for Pre-EFI Initialization Phase. It’s main purpose is to do minimal processor, chipset, and platform configuration for the purpose of discovering memory. It sets up the basic environment for the next phase. In fact, PEI code are gone when it moves on to the next phase. The only thing passed on to the next phase are the hob lists that describe the initialization done in the PEI phase.
DXE stands for driver execution phase. This is the phase where everything happens. Devices will be enumerated and initialized. EFI services will be supported and the protocols and the drivers will be implemented. This is where all the tables that make up the EFI interface will be created.
BDS stands for Boot Device Selection Phase and it is responsible for determining how and where you want to boot the OS.
Security (SEC)
Pre EFI
Initialization (PEI)
Driver Execution Environment (DXE)
Boot Dev
Select (BDS)
Transient System Load
(TSL)
Run Time
(RT)
After Life
(AL)
Power on
[ . . Platform initialization . . ]
[ OS boot ]
Shutdown

37. POST Execution Flow – High Level
Boot Execution Flow
POST Execution Flow – High Level
POST
Dispatch
Boot Dev
Select
Reset
Console
Init
Legacy OS
Load OS
Runtime
CPU Init
Device Init
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Flow of previous slide—what most BIOS do.
Use AMI BIOS example which has a Post Exec function to dispatch modules. The beginning code does the CPU init and starts out in the boot block
Framework can be thought of as execution and dispatching execution modules like other BIOS today. The Framework will still need to process the same and similar instillation similar to what is already done in today’s assembly 16 bit BIOSs. S3
Resume
Recovery

38. POST Execution Flow – High Level
Boot Execution Flow
POST Execution Flow – High Level
PEI
Console
Init
Device Init
Bus Init
POST
Dispatch
Boot Dev
Select
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime
POST
Dispatch
Boot Dev
Select
Reset
Console
Init
Legacy OS
Load OS
Runtime
Firmware
Volumes
CPU Init
Device Init
Cache as RAM
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
PEIM
Boot
Mode
Normal Boot
Handoff Blocks HOB
GUID
The PRE EFI Interface (PEI) foundation is the layer formally known as the Recover or Boot block section of a BIOS.
This phase is concerned about either Normal boot, S3, or Recovery, Just as in a legacy BIOS
The same functions and activities occur in this phase as any other BIOS, CPU init (CACHE init), Memory INIT, CS init.
With the Framework we also introduce new Terms PEIM, HOB, and GUID
PEIM – how a low level PEI communicates information between other PEIs
HOB – Data Structure for keeping track of resources
GUID – Identification mechanism
NVRAM S3
Resume
Capsules
Recovery *

39. POST Execution Flow – High Level
Boot Execution Flow
POST Execution Flow – High Level
DXE
POST
Dispatch
Boot Dev
Select
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime
Boot Dev
Select
EFI Driver
Dispatcher
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Reset
Console
Init
Legacy OS
Load OS
Runtime
EFI/DXE Drivers
CPU Init
Device Init
EFI Boot Services
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Like most BIOSs have some sort of Post execution flow dispatcher, most are table driven), The Device execution environment (DXE) foundation that is the driver or kernel for dispatching and executing the different drivers and or modules. In addition to just dispatching code the DXE foundation will also determine if a module or driver will be executed based on dependency expressions evaluated at runtime. Other BIOSs do this during Build time.
The mechanics behind the Framework are the EFI Drivers and in the DXE foundation these drivers get more abstract to the hardware.
There are fundamental EFI Boot services that are used by DXE S3
Resume
Recovery

40. POST Execution Flow – High Level
Boot Execution Flow
POST Execution Flow – High Level
BDS
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Console
Init
Device Init
Bus Init
POST
Dispatch
POST
Dispatch
Boot Dev
Select
Reset
Platform Policy
Console
Init
Legacy OS
Load
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime OS
Runtime
CPU Init
Device Init
EFI Boot Manager
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Normal Boot
Human Interface HII
Most legacy BIOS will have the feature BIOS Boot Spec (BBS) where the policy is to store a list of know boot devices and the last know boot device is know from successive boots. The framework has this same policy with the Boot Device Selection (BDS) except that the BBS is a subset of what the BDS can do as a feature.
The BDS is where Platform policy decisions will take action, and most customization is done here. S3
Resume
Recovery

41. POST Execution Flow – High Level
Boot Execution Flow
POST Execution Flow – High Level
TSL
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Console
Init
Device Init
Bus Init
POST
Dispatch
Boot Dev
Select
POST
Dispatch
Boot Dev
Select
Reset
Console
Init
Legacy OS
Load OS
Runtime
Compatibility Support Module
CSM
CPU Init
Device Init
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
EFI Preboot
Boot
Mode
Normal Boot
EFI Runtime Services
The goal of most BIOSs is to Boot to the OS. In the Framework there is also the ability to run in the Transient System Load phase. In this phase the boot manager with continue and has selected a EFI OS loader and will start running the EFI Compliant OS or if desired run an EFI application. S3
Resume
Recovery

42. Architecture Execution Flow
Boot Execution Flow
Architecture Execution Flow
UEFI
Interface
Pre Verifier
OS-Absent App
CPU Init
Device, Bus, or Service Driver
Transient OS Environment
verify
Chipset Init
Board Init
Transient OS Boot Loader
EFI Driver Dispatcher
Boot Manager
OS-Present App
Intrinsic Services
Final OS Boot Loader
Final OS Environment ?
Summary to this point.
On the most basic level. Framework has these phases.
SEC is the security phase. This is the first phase after platform reset or power on to ensure that firmware integrity is intact. Not much goes on here so we will not spend a lot of time on it.
PEI stands for Pre-EFI Initialization Phase. It does what it says, pre-EFI initialization. It’s main purpose is to do minimal processor, chipset, and platform configuration for the purpose of discovering memory. It sets up the basic environment for the next phase. In fact, PEI code are gone when it moves on to the next phase. The only thing passed on to the next phase are the hoblists which describes the initialization done in the PEI phase.
DXE stands for driver execution phase. This is the phase where everything happens. Devices will be enumerated and initialized. EFI services will be supported and the protocols and the drivers will be implemented. This is where all the tables that make up the EFI interface will be created.
BDS stands for Boot Device Selection Phase and it is responsible for determining how and where you want to boot the OS.
Security (SEC)
Pre EFI
Initialization (PEI)
Driver Execution Environment (DXE)
Boot Dev
Select (BDS)
Transient System Load
(TSL)
Run Time
(RT)
After Life
(AL)
Power on
[ . . Platform initialization . . ]
[ OS boot ]
Shutdown