DMTF and UEFI A Partnership for Platform Manageability

1
DMTF and UEFIA Partnership for Platform
Manageability
July 18th, 2007 Michael A. Rothman, Intel UEFI
Configuration Sub-team Chair
2
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

• 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 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

OS
Pre-boot Tools
UEFI Specification
Platform Drivers
Silicon Component Modules

• PI Specification

• Hardware

UEFI and PI are Independent Interfaces
PI Framework
Modular components
5
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 www.uefi.org

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?
• 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
• http//www.microsoft.com/whdc/system/platform/firm
  ware/uefireg.mspx
• 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
Protocol
INT 16h
AH 10h
Input
Simple Text Input 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-gtReadKeystroke (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
OS-AbsentApp
verify
PEICore
Transient OS Environment
CPUInit
Transient OS Boot Loader
Chipset Init
Board Init
OS-PresentApp
Boot Manager
UEFI Driver Dispatcher
Architectural Protocols
Final OS Environment
Final OS Boot Loader
Run Time (RT)
Driver Execution Environment (DXE)
Boot Dev Select(BDS)
Transient System Load (TSL)
Pre EFI Initialization (PEI)
Security (SEC)
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 -gt Machine system configuration
• Think Setup
• Machine -gt Machine system configuration
• Think Automation

16
Configuration of Add-in Devices
16

• 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 programmaticallyinteract with
IHV add-in devices.
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
Configuration Access Protocol
17
Local Configuration Infrastructure
EFI System Table
EFI Configuration Table
Standard method to pass interesting state data up
through to the O/S
18
Network Infrastructure
APP
APP
PXEBC
SNP
UNDI
19
Basic network-based configuration interactions
Middleware
In Band
Out of Band
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
Settings Keyword Option Keyword/Value Pairs
FLASH Map Offset HT_ENABLE Enable1,
Disable0 0x00 COM1_ENABLE
Enable1, Disable0 0x01 COM1_ADDRESS
0x2e8, 0x2f8, 0x3e8, 0x3f8
0x02 COM1_IRQ 0x03, 0x04
0x04 .
.
. Platform C Tag Definitions
Settings Keyword Option Keyword/Value Pairs
FLASH Map Offset HT_ENABLE Enable1,
Disable0 0x23 COM1_ENABLE
Enable1, Disable0 0x18 COM1_ADDRESS
0x2e8, 0x2f8, 0x3e8, 0x3f8
0x19 COM1_IRQ 0x03, 0x04
0x1B .
.
. Platform B Tag Definitions
Settings Keyword Option Keyword/Value Pairs
FLASH Map Offset HT_ENABLE Enable1,
Disable0 0x14 COM1_ENABLE
Enable1, Disable0 0x10 COM1_ADDRESS
0x2e8, 0x2f8, 0x3e8, 0x3f8
0x11 COM1_IRQ 0x03, 0x04
0x13 .
.
. Platform A Tag Definitions

• Three classes of platforms each with
• different configuration maps in their FLASH

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 (UEFIs
  domain) and standard manageability
  namespaces/profiles (DMTFs 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
• www.uefi.org
• Presenter
• Michael.a.Rothman_at_intel.com