DMTF Alliance Partner Technical Symposium 1 DMTF and UEFI A Partnership for Platform Manageability...

DMTF Alliance Partner Technical Symposium

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


Brief History of UEFI

3

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 standardizationBIOS now has standardization


What is UEFI?

4

The UEFI Forum is responsible for– Unified Extensible Firmware Interface

(UEFI) Specification– Platform Initialization Interface (PI)

SpecificationsUEFI Spec is about interfaces between OS,

add-infirmware 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

•Hardware

OSPre-bootTools

UEFI Specification

Silicon Component Modules

Platform Drivers

PI Framework

Modular components

UEFI and PI are Independent InterfacesUEFI and PI are Independent Interfaces

•PI Specification


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

5

Industry group promotion, and very open participation approach

Industry group promotion, and very open participation approach


How UEFI is organized

6

USSTUSST

UNSTUNST

UEFI BoardUEFI Board

USWGUSWG

PIWGPIWG

UTWGUTWG

ICWGICWG

UCSTUCST

Publications/Decisions ratified

by the board

Each sub-team focuses on specific topics and

contributes material to the work group.

Each work group approves/delivers different

content to the public.


DMTF Relationship

7

USWG

UCST

Technical Committees

SMBIOS

DMWG/SMWG

PMCI/etc


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/firmware/uefireg.mspx

– Linux O/S loader availability has existed for a while. Inclusion within various distributions is WIP.

8


PC Vendor Adoption

Percentage of platforms shipping with UEFI is increasing.Percentage of platforms shipping with UEFI is increasing.– Most of the major OEMs have platforms that either are shipping Most of the major OEMs have platforms that either are shipping

with UEFI or have systems in development which will use it.with UEFI or have systems in development which will use it.

– Intel has shipped and continues to have plans to ship UP/DP/MP Intel has shipped and continues to have plans to ship UP/DP/MP with UEFI support.with UEFI support.

The major IBVs (Phoenix, AMI, Insyde) are producing UEFI The major IBVs (Phoenix, AMI, Insyde) are producing UEFI firmware versions for their clients.firmware versions for their clients.

9


Legacy API vs UEFI API

10

Legacy UEFI/Framework

INT 16h AH = 10h

AH = Scan code

AL = ASCII character

Input

Output

Output

Read Keystroke Example

mov ax, 1000hint 16h

cmp ah, 10hjz HandleExtReadKeycmp ah, 11hjz CheckForKey;; Do more checking

HandleExtReadKey:;; Do real work heremov axret

Caller Sample Code Handler Sample Code

This, &Key

Key = EFI_INPUT_KEY

Input

Output

TextIn->ReadKeystroke (TextIn, &Key);

ReadKeyStrokeHandler ( IN EFI_SIMPLE_TEXT_INPUT_PROTOCOL *This, OUT EFI_INPUT_KEY *Key ){// Do real work here}

Caller Sample Code

Handler Sample Code

Protocol

Simple Text Input Protocol

ReadKeyStroke

Reset

WaitForKey


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

11

Standardize how to deliver silicon support and early firmware

environment

Standardize how to deliver silicon support and early firmware

environment


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”

12

All early init information is passed upstream through a HOB

All early init information is passed upstream through a HOB


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

13

In contrast to previous POST tables, very flexible initialization

allows for various solutions to enable fast boot.

In contrast to previous POST tables, very flexible initialization

allows for various solutions to enable fast boot.


Overall View of Boot Time Line

14

Power on [ . . Platform initialization . . ] [ . . . . OS boot . . . . ] Shutdown

Run Time(RT)

OS-PresentApp

Final OS Environment

Final OS Boot Loader

Driver Execution Environment (DXE)

Boot DevSelect(BDS)

Transient System Load(TSL)

OS-AbsentApp

Transient OS Environment

Transient OS Boot Loader

Boot Manager

Device, Bus, or Service Driver

UEFI

Interfaces

UEFI Driver Dispatcher

Architectural Protocols

Pre EFIInitialization (PEI)

CPUInit

Chipset Init

Board Init

verify

Security (SEC)

PEICore

Pre Verifier


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

15


Configuration of Add-in Devices

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;

16

Configuration

Access ProtocolConfiguration

Access Protocol

Configuration







Access Protocol

16

Standard way to programmatically

interact with IHV add-in devices.

Standard way to programmatically

interact with IHV add-in devices.


Local Configuration Infrastructure

17

EFI System Table

EFI Configuration Table

GUID Pointer

Table A GUID Address ATable B GUID Address B

Table Y GUID Address YTable Z GUID Address Z

...

Standard method to pass interesting state data up through to the O/S

Standard method to pass interesting state data up through to the O/S


Network Infrastructure

18

PXEBC

SNP

UNDI

APP

APP

ARP Service Binding IP Service Binding

UDP Service Binding

MNP Service Binding

MTFTP Service Binding

TCP Service Binding


Basic network-based configuration interactions

19

Physical SMP Server

Middleware

Server

Service

Processor

PI Architecture 1.0BMC

OS

Server

In Band Out of Band

UEFI 2.0

SM

AS

H


Advanced network-based configuration interactions

20

Large Corporate Customer Platform Schema Definition

Platform type A

Platform type B

•Platform type C

Flash

Flash

Flash

•Three classes of platforms each with

•different configuration maps in their FLASH

Settings Keyword Option Keyword/Value Pairs FLASH Map OffsetHT_ENABLE Enable=1, Disable=0 0x00COM1_ENABLE Enable=1, Disable=0 0x01COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x02COM1_IRQ 0x03, 0x04 0x04 . . . Platform C Tag Definitions

Settings Keyword Option Keyword/Value Pairs FLASH Map OffsetHT_ENABLE Enable=1, Disable=0 0x23COM1_ENABLE Enable=1, Disable=0 0x18COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x19COM1_IRQ 0x03, 0x04 0x1B . . . Platform B Tag Definitions

Platform C

012

4

n

...

3

0x000x01

0x02F8

0x03

0x00

Platform B

18191A

23

n

1B

0x01

0x2E8

0x04

0X03

0X00

...

...

0 0x00...

Platform A

0

1011

13

n

...

12

0x00

0x01

0x02F8

0x04

0x00

...

14 0x01

Settings Keyword Option Keyword/Value Pairs FLASH Map OffsetHT_ENABLE Enable=1, Disable=0 0x14COM1_ENABLE Enable=1, Disable=0 0x10COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x11COM1_IRQ 0x03, 0x04 0x13 . . . Platform A Tag Definitions

Administrator

Administrator sends a configuration directive to the client workstations. The heterogeneous

targets must be able to interpret the directives into platform-specific actions.


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).

21

“BIOS” is evolving through UEFI“BIOS” is evolving through UEFI


Call To Action

I want to leave you thinking about BIOS in a slightly I want to leave you thinking about BIOS in a slightly different way than you otherwise might have in the past.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.

22

“BIOS” now has a single venue for evolving.Interactions with industry standards groups are

ongoing.

“BIOS” now has a single venue for evolving.Interactions with industry standards groups are

ongoing.


Backup

UEFI Web site– www.uefi.org

Presenter– [email protected]

23

DMTF Alliance Partner Technical Symposium 1 DMTF and UEFI A Partnership for Platform Manageability...

Documents

Transcript of DMTF Alliance Partner Technical Symposium 1 DMTF and UEFI A Partnership for Platform Manageability...