1. DMTF and UEFI A Partnership for Platform Manageability
July 18th, 2007
Michael A. Rothman, Intel
UEFI Configuration Sub-team Chair

2. Agenda What is UEFI? UEFI Relationships in the Industry
24-Apr-17
Agenda
What is UEFI?
Purpose / Promoters
UEFI Relationships in the Industry
Adoption in platforms and operating systems
Relationship with DMTF
Technical Details
Background
PEI/DXE Details
Trends for the Future
Evolving the BIOS Standard
Call to Action

3. Brief History of UEFI BIOS now has standardization
Before UEFI, there was EFI (1998)
The only way to boot Itanium® Processor-based systems
Addressed BIOS Limitations
Developed by Intel, …but designed to be CPU design neutral
Before PI, there was Intel Framework
Enable modularity, extensibility, flexibility in firmware implementation
Industry agreed on EFI/Framework direction
Can be used on IA-32, Itanium and embedded devices
Need for broader governance
Intel, Microsoft contributed the seed material
The UEFI Forum, Inc. was formed (2005)
UEFI Specification v2.0 and v2.1 published (2006/2007), added support for x64
PI Specifications v1.0 published (2006)
Ecosystem is maturing
BIOS now has standardization

4. What is UEFI? The UEFI Forum is responsible forOS
Pre-boot
Tools
The UEFI Forum is responsible for
Unified Extensible Firmware Interface (UEFI) Specification
Platform Initialization Interface (PI) Specifications
UEFI Spec is about interfaces between OS, add-in
firmware driver and system firmware
Operating systems and other high-level software should only interact with interfaces and services defined by the UEFI Specification
PI Specs relate to making UEFI implementations
Promote interoperability between firmware components providers
All interfaces and services produced and consumed by firmware only
UEFI Specification
Platform Drivers
Silicon Component
Modules
PI Specification
Hardware
UEFI and PI are Independent Interfaces
PI Framework
Modular components

5. Industry group promotion, and very open participation approach
UEFI
A Washington non-profit Corporation
Develops, promotes and manages evolution of Unified EFI Specification
Continue to drive low barrier for adoption
Promoter members:
IBVs: AMI, Insyde, Phoenix
OEMs: Dell, HP, IBM, Lenovo
AMD, Apple, Intel, Microsoft
Tiered Membership:
Promoters, Contributors and Adopters
More information:
Industry group promotion, and very open participation approach

6. How UEFI is organized UEFI Board USWG UCST PIWG UNST UTWG USST ICWG
Each sub-team focuses on specific topics and contributes material to the work group.
Publications/Decisions ratified by the board
Each work group approves/delivers different content to the public.

7. DMTF Relationship Technical Committees USWG UCST SMBIOS DMWG/SMWG
PMCI/etc

8. OSV Adoption UEFI Support? UEFI as a requirement?
Native UEFI Boot in upcoming Windows Vista SP1 (client) as well as Windows Longhorn (server).
UEFI as a requirement?
Microsoft is starting to define operating behavior which presumes an underlying UEFI infrastructure in upcoming O/S versions.
Link to draft Longhorn UEFI Requirements
Linux O/S loader availability has existed for a while. Inclusion within various distributions is WIP.

9. PC Vendor Adoption
Percentage of platforms shipping with UEFI is increasing.
Most of the major OEMs have platforms that either are shipping with UEFI or have systems in development which will use it.
Intel has shipped and continues to have plans to ship UP/DP/MP with UEFI support.
The major IBVs (Phoenix, AMI, Insyde) are producing UEFI firmware versions for their clients.

10. Legacy API vs UEFI API Read Keystroke Example Legacy UEFI/Framework
INT 16h
AH = 10h
Input
Simple Text Input Protocol
ReadKeyStroke
Reset
WaitForKey
Protocol
AH = Scan code
Output
AL = ASCII character
Output
This, &Key
Input
Key = EFI_INPUT_KEY
Output
Caller Sample Code
Handler Sample Code
Caller Sample Code
mov ax, 1000h
int 16h
cmp ah, 10h
jz HandleExtReadKey
cmp ah, 11h
jz CheckForKey
;; Do more checking
HandleExtReadKey:
;; Do real work here
mov ax
ret
TextIn->ReadKeystroke (TextIn, &Key);
Handler Sample Code
ReadKeyStrokeHandler (
IN EFI_SIMPLE_TEXT_INPUT_PROTOCOL *This,
OUT EFI_INPUT_KEY *Key ) {
// Do real work here }

11. PEI Theory of Operations (Early Init)
Consumes reset, INIT, MCA
Small, tight startup code
Starts as XIP from ROM
Leverage new architectural support in upcoming IA CPUs
“Cache in lieu of RAM”
Gets us to C closer to reset
Core locates, validates, and dispatches PEIMs
Primary goals
A standard method for delivering silicon modules.
Discover boot mode
Launch modules that initialize main memory
Discover & launch DXE core
Standardize how to deliver silicon support and early firmware environment

12. Transition between PEI and DXE
PEI gives way to DXE
Hand off from one to the other, PEI dematerializes
Work deferred to DXE whenever possible
Memory map and resources discovered in PEI passed on to DXE
Hand Of Blocks (HOBs)
set of linked data structures
Memory, firmware stores, platform resources, boot mode, etc.
Last PEI Module is Initial Program Load for DXE
HOB list passed in as argument to DXE “main”
All early init information is passed upstream through a HOB

13. DXE Theory of Operations (Late Init)
First goal: determine boot target
Required boot device and console devices
Loads drivers to construct environment that can support boot manager & OS boot
Dependencies provide driver ordering
Grammar-based description of drivers’ requirements
Including patch or override operations e.g. with “before/after” dependencies
EFI drivers with no dependency started last
Compatibility for UEFI drivers, IHV cards etc.
Dispatch completes as fast as practical
Required hardware init performed by driver on call to entry point
EFI driver entry points just register protocol
Defer initialization of boot devices until we know which are needed
When all required drivers are loaded go to boot manager to attempt to boot
In contrast to previous POST tables, very flexible initialization
allows for various solutions to enable fast boot.

14. Overall View of Boot Time Line
UEFI Interfaces
Pre Verifier
verify
OS-Absent App
PEI Core
Device, Bus, or Service Driver
Transient OS Environment
CPU Init
Chipset Init
Transient OS Boot Loader
Board Init
UEFI Driver Dispatcher
Boot Manager
OS-Present App
Architectural Protocols
Final OS Boot Loader
Final OS Environment
Security (SEC)
Pre EFI
Initialization (PEI)
Driver Execution Environment (DXE)
Boot Dev
Select (BDS)
Transient System Load
(TSL)
Run Time
(RT)
Power on
[ . . Platform initialization . . ]
[ OS boot ]
Shutdown

15. UEFI Configuration Infrastructure
Problem Statement
No standard/interoperable mechanism to address pre-boot based issues like:
Localization
Standard delivery of string packages
Fonts
Create standard glyph support along with optional font styles
Shared Configuration Infrastructure
Alleviate the burden for many configuration engines in a system (e.g. add-in device no longer needs to delay boot or poll for hot-keys, etc)
Should be able to also address:
Human -> Machine system configuration
Think Setup
Machine -> Machine system configuration
Think Automation

16. Configuration of Add-in Devices16
Device Access APIs
Introduces abstractions to allow the platform BIOS to interact both with the motherboard as well as various other agents (e.g. Add-in device) in the system.
typedef struct { EFI_HII_EXTRACT_CONFIG ExtractConfig; EFI_HII_ROUTE_CONFIG RouteConfig; EFI_HII_FORM_CALLBACK Callback; } EFI_HII_CONFIG_ACCESS_PROTOCOL;
Standard way to programmatically interact with IHV add-in devices.
I/O Controller
I/O Controller
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
I/O Controller
Configuration
Access Protocol
Configuration
Access Protocol

17. Local Configuration Infrastructure
EFI System Table
EFI Configuration Table
GUID
Pointer
Table A GUID
Address A
Table B GUID
Address B .
Table Y GUID
Address Y
Table Z GUID
Address Z
Standard method to pass interesting state data up through to the O/S

18. Network Infrastructure
APP
APP
PXEBC
MTFTP
Service Binding
TCP
Service Binding
UDP
Service Binding
ARP
Service Binding IP
Service Binding
MNP
Service Binding
SNP
UNDI
NIC

19. Basic network-based configuration interactions
Middleware
In Band
Out of Band
I/O Controller OS
SMASH
UEFI 2.0
PI Architecture 1.0
Service
Processor
BMC
Physical SMP Server
Server
Server

20. Advanced network-based configuration interactions
Large Corporate Customer
Platform Schema Definition
Platform type C
Settings Keyword Option Keyword/Value Pairs FLASH Map Offset
HT_ENABLE Enable=1, Disable= x00
COM1_ENABLE Enable=1, Disable= x01
COM1_ADDRESS x2e8, 0x2f8, 0x3e8, 0x3f x02
COM1_IRQ x03, 0x x04
Platform C Tag Definitions
Flash
Platform type B
Settings Keyword Option Keyword/Value Pairs FLASH Map Offset
HT_ENABLE Enable=1, Disable= x23
COM1_ENABLE Enable=1, Disable= x18
COM1_ADDRESS x2e8, 0x2f8, 0x3e8, 0x3f x19
COM1_IRQ x03, 0x x1B
Platform B Tag Definitions
Platform type A
Flash
Settings Keyword Option Keyword/Value Pairs FLASH Map Offset
HT_ENABLE Enable=1, Disable= x14
COM1_ENABLE Enable=1, Disable= x10
COM1_ADDRESS x2e8, 0x2f8, 0x3e8, 0x3f x11
COM1_IRQ x03, 0x x13
Platform A Tag Definitions
Flash
Platform B 18 19 1A 23 n 1B
0x01
0x2E8
0x04
0X03
0X00
. . .
0x00
Three classes of platforms each with
different configuration maps in their FLASH
Platform A 10 11 13 n
. . . 12
0x00
0x01
0x02F8
0x04 14
Platform C 1 2 4 n
. . . 3
0x00
0x01
0x02F8
0x03

21. BIOS is a living standard
A BIOS specification standard?
UEFI is an evolving standard, to-date UEFI 2.0, UEFI 2.1 published in Jan ‘06 and Jan ‘07 respectively.
DMTF relationship means what?
Ensure the two groups cooperate and have a symbiotic relationship.
By having an alliance between DMTF/UEFI we can cooperatively evolve the standards for both the traditional platform configuration/setup (UEFI’s domain) and standard manageability namespaces/profiles (DMTF’s domain).
“BIOS” is evolving through UEFI

22. Call To Action
I want to leave you thinking about BIOS in a slightly different way than you otherwise might have in the past.
More DMTF workgroup interaction
If there are work efforts ongoing which touch on platform BIOS, UEFI would like to participate as appropriate.
Communicate with UEFI
Where appropriate, we might find it useful to have certain standard platform BIOS features (i.e. Interfaces, Capabilities, etc). If so, contact us to further discuss such scenarios.
“BIOS” now has a single venue for evolving.
Interactions with industry standards groups are ongoing.

23. Backup UEFI Web site Presenter www.uefi.org