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

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

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

What is UEFI? The UEFI Forum is responsible for OS 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

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: www.uefi.org Industry group promotion, and very open participation approach

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.

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

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

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.

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 }

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

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

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.

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

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

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

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

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

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

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=0 0x00 COM1_ENABLE Enable=1, Disable=0 0x01 COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x02 COM1_IRQ 0x03, 0x04 0x04 . . . Platform C Tag Definitions Flash Platform type B Settings Keyword Option Keyword/Value Pairs FLASH Map Offset HT_ENABLE Enable=1, Disable=0 0x23 COM1_ENABLE Enable=1, Disable=0 0x18 COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x19 COM1_IRQ 0x03, 0x04 0x1B . . . Platform B Tag Definitions Platform type A Flash Settings Keyword Option Keyword/Value Pairs FLASH Map Offset HT_ENABLE Enable=1, Disable=0 0x14 COM1_ENABLE Enable=1, Disable=0 0x10 COM1_ADDRESS 0x2e8, 0x2f8, 0x3e8, 0x3f8 0x11 COM1_IRQ 0x03, 0x04 0x13 . . . 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

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

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.

Backup UEFI Web site Presenter www.uefi.org Michael.a.Rothman@intel.com