Unified Extensible Firmware Interface (UEFI)

Unified ExtensibleFirmware Interface(UEFI)ImplementationAndrew GuidelinesRitzDevelopment ManagerWindows Kernel TeamMicrosoft Corporation

Key TakeawaysBe a leader in advancing 64-bit computingAdopt best practices and new toolsLet’s partner on new hardware directionsUnderstand importance of Unified ExtensibleFirmware Interface (UEFI)UEFI in industry and Microsoft plansUnderstand how to build UEFI platforms whichare Windows compatible

Agenda2 key audiences, 2 focusesInterested in UEFI and Microsoft’s position?Understand what UEFI isUnderstand Microsoft firmware goalsUEFI timelineUnderstand Microsoft roadmapImplementing a UEFI platform?Explicit guidance on how to construct a systemFirmware and Deployment considerations

What Is UEFI?UEFI is a firmware interface specificationStandardized mechanism to bootstrap OperatingSystem (OS) launchNext-generation replacement forBIOS-based firmwareUEFI is a platform independent specificationPlatform specifics defined for Itanium,x64, x86

What Is UEFI?UEFI runs in long-mode on x64Great environment for using modernprogramming techniques and toolsBy comparison, BIOS is a 16-bit real-modeenvironmentUEFI contains formally architected extensibilitymodelAdding in driver support is well-architectedCompared to ad-hoc extensibility in BIOS

How UEFI And ACPI RelateUEFI complements Advanced Configurationand Power Interface (ACPI) firmwareACPI firmware used at runtime, UEFI mainlyused during bootstrapLimited runtime usage of UEFI firmware

Why Is UEFI Important?Engineering easeSignificant benefits to UEFI approachNon-recoverable Engineering cost (NRE) is lessonedwith UEFIBIOS has shown its ageInnovation still possible with BIOS, but technical limitationsmake this very difficultChanging how ecosystem operatesClean extensibility model changes how systemsare integratedSignificant industry momentumA once every 20 years opportunity

Why Is UEFI Important?User VisibilityUEFI doesn’t greatly effect visible feature setof a platformUEFI dictates internals of how a system isput togetherSimplifies design of pre-OS componentsConsumers shouldn’t need to understand thispart of the systemUsers rarely interact with firmware

Windows Firmware RoadmapGoalsEnable mainstream 64-bit computingUEFI is a solid technology to bet onTransition away from BIOS firmware to UEFI firmwareover timeProactive long-term investment in UEFIAchieve firmware independenceConsistent with Windows portability goalsRequirement for transition periodAvoid adding complexity to customers during firmwaretransition

Windows EngineeringMethodologyInvesting in UEFIMicrosoft taking advantage of benefits of UEFIinternallyFuture releases may include exclusiveUEFI scenariosShifting to UEFI first approachArchitect, design, build on UEFIWhere relevant, port feature to BIOS

Evolution Of UEFI(1 of 4)Late1990’sConception of EFIFocused alternative to BIOS on ItaniumAlso intended as replacement for BIOS on x86Microsoft active in EFI 1.0 specification2001Windows XP 64-bit edition: introduces EFI 1.02 supportfor ItaniumWork begins on next-generation Windows BootEnvironmentMicrosoft goal to support EFI on x86

Evolution Of UEFI(2 of 4)2003Development for Windows XP Professional x64 EditionX64 established as Windows strategic directionNeed EFI solution to support X64 and gain industrymomentum for X64 and EFIFall2004Demo of Windows 32-bit EFI boot at Intel Developer ForumEstablishes viability of Windows Boot Environment and EFI

Evolution Of UEFI(3 of 4)2005Windows XP Professional x64 Edition releasedUEFI forum establishedGoal to define support for x64Goal to drive EFI adoption through ecosystemSpring2006UEFI 2.0 releasedDemo of Windows x64 UEFI boot at Intel Developer ForumWindows plug-festEcosystem maturing but not yet ready

Evolution Of UEFI(4 of 4)Winter2006Windows Vista releasedUEFI plug-festMore platform support, parity with BIOSEmerging driver supportSpring2007Windows Server codename “Longhorn” UEFI plug-festEcosystem maturingVarious mature base implementationsUEFI 2.1 released

UEFI Solutions Emerging…UEFIspecification readyWindowsUEFI readyPartnerEcosystemUEFI ready

Windows Support For UEFIWindows Server Longhorn andWindows Vista introduce native UEFI 2.0support on all 64-bit platformsEmergence of x64 provides an inflection point fortransition to UEFINo support for 32-bit platforms planned

Windows Support For ItaniumWindows supports existing EFI 1.1-basedItanium systemsSome elements of UEFI 2.1 requireddepending on platform WHEA integrationdesign choice

What Does UEFI SupportInclude?64-bit Client and Server support in theWindows Server Longhorn timeframeParity support for all BIOS-based platform scenarioson UEFI platformsNative deployment and boot on UEFI platforms

Guidelines For BuildingA UEFI Platform

Principles ForFirmware RequirementsParity support for all scenarios on BIOS andUEFI systemsSupport UEFI on mainstream x64 systemsAllow boot of older operating systems (e.g., WindowsXP) on UEFI platforms during transitionUEFI does support a firmware compatibility layer to supportboot of prior BIOS-based operating systemsWindows Server Longhorn and Windows Vista startthe clock ticking for dropping BIOS backwardscompatibility

Required Firmware ElementsMust support UEFI 2.0 specificationElements of UEFI 2.1 requiredFuture-proofed: Windows does not explicitlycheck for newer revisionsSupport Windows boot, Windows installationand Windows compatibility requirementsACPI 2.0+ runtime firmware support

UEFI FirmwareInstallation RequirementsUEFI-based installation requires boot via UEFIMust support appropriate boot serviceprotocols for installation mechanismMust support runtime variable servicesMust support GPT partitioning scheme

DVD Media RequirementsWindows uses same media for UEFI and BIOSinstallationWindows uses UDFS bridge format for DVD mediaWindows uses El Torito multiple bootcatalog supportWindows OEM Preinstall Kit (OPK) and WindowsAdmin Installation Kit (AIK) include updatedversion of cdimage.exe that supports creation ofmultiple boot catalog imageDetails provided in deployment guide

DVD Firmware RequirementsUEFI Firmware must support El Torito multipleboot catalog support for DVD bootUEFI firmware must detect catalog entry with0xEF platform tagUEFI firmware boot manager must execute\EFI\BOOT\BOOTX64.EFI from catalogMust ignore catalog entry with 0x0 platform tagPlatforms with BIOS support must supportsame media

Network Boot RequirementsMust send out PXE broadcast with correctclient system architecture tag (0x00 0x07)Must support TFTP downloadInitial download is Windows Boot Manager

Understanding GPTGUID Partition Table (GPT) partitioning schemerequired for UEFI bootGPT proven scheme from Itanium deploymentsGPT already supported for data disks on WindowsServer 2003 SP1Key features of GPTNo boot code on diskRobustnessFlexibility: extensible partition types and countsModern: Extended disk sizes (>2TB)

GPT Disk Partitioning

Windows GPT RequirementsRequired PartitionsEFI system partition (ESP)Minimum size 200MBFormatted with FAT32 file systemMicrosoft reserved partition (MSR)– 128 MBWindows Operating System (OS) partitionFormatted with NTFS file system

Firmware Boot RequirementsRequired ProtocolsFirmware must implement the following protocols fordisk bootBlock I/O protocol and Device Path protocolFirmware must implement the following protocols forinput/outputSimple Input protocolGraphics output protocolSimple Text output protocolFirmware must implement the following protocol forBitLocker supportEFI TCG protocol

Understanding WindowGraphics UsageWindows OS Loader places system into graphics modeRequired for localized text to be renderedWindows prefers graphics output protocol (GOP)Windows supports EFI 1.1 UGA protocol but UGA is deprecated in UEFI2.0 specificationBetter long-term choice is GOP supportFirmware may not manipulate frame buffer after mode is set byOS LoaderWindows requires 1024x768 or 800x600 resolution with32-bit colorIf neither supported, Windows reverts to simple text mode and English

Understanding GraphicsOutputRuntime compatibilityGOP does not support runtime callsWindows sets the mode in OS LoaderPreserve mode and frame buffer after ExitBootServices()and until Windows performance driver takes overFor Windows Server Longhorn VGA support stillrequires int10h supportRequired for many video cardsWish to loosen this restriction in future releasesSpecify the VGA not present ACPI flag on server systemswithout video card

Runtime FirmwareRequirementsFirmware must implement EFIvariable servicesStorage Sizing recommendationsWindows limits use of variable services for bootsettingsMost settings stored on ESP in WindowsBCD store

Variable Services And WHEAWHEA Error record persistence required forWindows Server LonghornMultiple design alternatives existUsing EFI variable services requires UEFI 2.1variable services complianceStorage Sizing1KB minimum size required for x64 WHEA Errorrecords100KB minimum size required for Itanium WHEAError recordsMore details in WHEA presentation

ACPI Sleep StateRequirementsWindows Vista requires S3 and S4 supportWindows Server Longhorn requires S4 supportFirmware must ensure that physical memory isconsistent across S4 sleep transitionsSize and location must both be maintainedRequired to restore physical memory across transitionWindows will fail to resume from S4 if these conditions notsatisfiedPhysical memory map retrieved via GetMemoryMap()interface

BCD DeploymentWindows stores boot settings in BootConfiguration Data (BCD) storeCommon abstraction for UEFI andBIOS platformsWindows Server 2003 had different mechanismsand no abstractionAlso allows access to UEFI NVRAM variablesAccess to BCD store available viaBCD WMI providerBCDEditExcellent web resources available

BCD DeploymentBCD store is created on ESPConsider backup plan for BCD storeBoot settings static during installationModify boot settings post setup via scripting

UEFI And Image DeploymentImage Deployment for UEFI is similar toimage deployment on BIOSCapture the Windows partition imageRun setup.exe to deploy image on targetAll details taken care of for youIf you deploy offline, you must deployWindows partition and ESPExtra steps detailed in whitepaper

A Note On Bootstrap ExtensibilityAd-hoc mechanisms for extensibility notsupported with UEFIWindows supports custom bootstrap actionsUEFI boot manager supportsother extensibilityPlease talk with Microsoft about how to bestintegrate your value-add softwareOpportunities to enhance UEFI specification

Call To ActionUnderstand industry momentum around UEFIConsider impact of UEFI for your companyUnderstand why Microsoft loves UEFIStart building Windows UEFI platformsUnderstand requirements for Windows UEFI platformsGet engaged with Microsoft and UEFIFamiliarize with Windows UEFI supportRun the UEFI SCTGet involved in Windows and UEFI plug-fests

Additional ResourcesWeb ResourcesPortal:http://www.microsoft.com/whdc/system/platform/firmware/default.mspxUEFI Requirements:http://www.microsoft.com/whdc/system/platform/firmware/uefireg.mspxCustom Boot Actionshttp://www.microsoft.com/whdc/system/platform/firmware/OEMBoot_Vista.mspxRelated SessionsSVR-T326 WHEA Systems: Design and ImplementationWinboot @ microsoft.comQuestions and Comments:

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in theU.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft mustrespond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of anyinformation provided after the date of this presentation.MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.