4.UEFI Technical Overview

 Contents
•1UEFI Technical Overview
•1.1What is UEFI?
•1.2Concept
•1.3UEFI Specification - Key Concepts
•1.4Objects Managed by UEFI Firmware
•1.5What is the UEFI System Table
•1.6UEFI System Table
•1.7 UEFI Data Structures - EFI System Table
•1.8GUID
•1.9Protocols (API)
•1.10Handles
•1.11Handle Protocol Database
•1.12Legacy BIOS vs UEFI
•1.13Device Path Protocol
•1.14Device Path Examples
•1.15EFI 1.1 vs. UEFI
•1.16UEFI 2.1 Published 2007
•1.17What’s supported?
•1.18EFI Byte Code Overview
•2Technology not addressed by UEFI
•2.1Why Do More Than UEFI?
•2.2UEFI Firmware Software Stack
•3Summary
 

UEFI Technical Overview

What is UEFI?

• Extensible Firmware Interface

• UEFI is an interface specification

• Abstracts the platform from OS

– Decouples development

• Includes a modular driver model and CPU-independent option ROMs

– Offers promise of improved RAS

• Compatible by design

– Evolution, not revolution

• Modular and extensible

– OS-Neutral value add

• Complements existing interfaces

Concept

UEFI Specification - Key Concepts

• Objects - manage system state, including I/O devices, memory, and events

• The UEFI System Table - data structure with data in-formation tables to interface with the systems

• Handle database and protocols - callable interfaces that are registered

• UEFI images - the executable content format

• Events - the software can be signaled in response to some other activity

• Device paths - a data structure that describes the hardware location of an entity

Objects Managed by UEFI Firmware

What is the UEFI System Table

• Firmware implementation information

– Read only for peripheral drivers

– Specification version

– Interface to UEFI protocols

– Interface to other standards…

UEFI System Table

UEFI Data Structures - EFI System Table

GUID

• “Globally” Unique Identity

– 128-bit quantity defined by Wired for Management WfM 2.0 specification http://www.intel.com/design/archives/wfm/index.htm

• Used to identify protocols

– 1:1 with interfaces

• Regulate extension mechanism

– Documented in the spec

– Added through drivers

Protocols (API)

• GUID, Interface Structure, Services

– DEVICE_PATH, DEVICE_IO, BLOCK_IO, DISK_IO, FILE_SYSTEM, SIMPLE_INPUT, SIMPLE_TEXT_OUTPUT,

SERIAL_IO, PXE_BC, SIMPLE_NETWORK, LOAD_FILE, UNICODE_COLLATION

 

Handles

• All protocols have a handle which is associated with the protocol

• Every device and executable image in UEFI has a handle protocol in the handle database

• Every boot device must have a device path protocol to describe it

Handle Protocol Database

Legacy BIOS vs UEFI

UEFI

GUID1 UEFI Specification GUID2 Framework Specification GUID3 ODM defined

GUID4 OEM defined GUID5 IBV defined

 

Device Path Protocol

• A data structure description of where a device is in the platform

• All boot devices, logical devices and images must be described by a device path

• 6 types of device paths:

–Hardware

–ACPI

– UID/HID of device in AML

–Messaging

– i.e. LAN, Fiber Channel, ATAPI, SCSI, USB

–Media

– i.e. Hard Drive, Floppy or CD-ROM

–EDD 3.0 boot device

– see EDD 3.0 spec int13 48

–End of hardware

– marks end of device path

 

 

Device Path Examples

• Acpi(PNP0A03,0)/Pci(1F|1)/Ata(Primary,Master)/HD(Part3, Sig00110011)

• Acpi(PNP0A03,1)/Pci(1E/0)/Pci(0|0)/Mac(0002B3647D69)

• Acpi(PNP0A03,0)/Pci(1F|0)/Acpi(PNP0501,0)/Uart(115200 81)

 

EFI 1.1 vs. UEFI

Items being changed or deprecated

UGA Protocols, SCSI Passthrough, USB Host Controller, Device I/O

 

New Items

Added Networking APIs, Intel® 64 binding, Service Binding, Tape I/O, Hash,

DevicePath Utilities, CreateEventEx, UpdateCapsule, iSCSI Initiator,

QueryCapsuleCapabilities, QueryVariableInfo, AuthenticationInfo

 

Items that are not changing

Loaded Image, Device Path, Driver Binding, Platform Driver Override,

Bus Specific Override, Driver Configuration, Driver Diagnostics,

Component Name, Simple Text Input, Simple Text Output, Simple Pointer,

Serial IO, Load File, Simple File System, File Protocol, Disk IO,

Block IO, Unicode Collation, PCI Root Bridge IO, PCI IO, SCSI IO,

USB IO, Simple Network, PXE BC, Network Identifier Interface, BIS,

Debug Support, Debug Port, Decompress, Device IO, EBC, RaiseTPL,

RestoreTPL, AllocatePages, FreePages, GetMemoryMap, AllocatePool,

FreePool, CreateEvent, SetTimer, WaitforEvent, SignalEvent,

CloseEvent, CheckEvent, InstallProtocolInterface, ReinstallProtocolInterface,

UninstallProtocolInterface, HandleProtocol, LocateHandle, LocateDevicePath,

InstallConfigurationTable, LoadImage, StartImage, Exit, UnloadImage,

ExitBootServices, GetNextMonotonicCount, Stall, SetWatchdogTimer,

ConnectController, DisconnectController, OpenProtocol, CloseProtocol,

OpenProtocolInformation, ProtocolsPerHandle, LocateHandleBuffer,

LocateProtocol, InstallMultipleProtocolInterfaces, UninstallprotocolInterfaces,

CalculateCrc32, CopyMem, SetMem, GetTime, SetTime, GetWakeupTime,

SetWakeupTime, SetVirtualAddressMap, ConvertPointer, GetNextVariable,

GetVariable, SetVariable, GetNextHighMonotonicCount, ResetSystem, ...

 

 

UEFI 2.1 Published 2007

• A smaller update than the 2.0 iteration

–Backlog that needed more gestation time

–Aiming for mid year 2006 completion

• User interface presentation

–Aiming to define interfaces that support integration of setup/configuration functions for motherboard and add-in devices

• Security/Integrity related enhancements

–Provide service interfaces for UEFI drivers that want to operate with high integrity implementations of UEFI

• Various other subject areas possible

–More boot devices, error reporting, etc.

 

What’s supported?

• The community is in the progress of switching from EFI 1.1 to UEFI 2.x.

–EFI 1.1 protocols –UEFI 2.0 protocols starting to replace EFI 1.1 protocols –New UEFI 2.1 protocols have been added

 

 

EFI Byte Code Overview

• Single image supports multiple platforms

• Code is interpreted on Intel Itanium® Architecture and IA-32 systems

• IHVs develop only once

Technology not addressed by UEFI

Why Do More Than UEFI?

• EFI Sample Implementation on IA32 too large for today’s desktop, mobile and handheld flash allotment.

• Opportunity to drive C-code and modularity much closer to Si with all architectures in mind.

• Make IA firmware development competitive with RISC implementations.

 

UEFI on BIOS is NOT Good Enough

 

• Memory Initialization

• Recovery

• FLASH update

• ACPI S3

• Platform Initialization

• System Management Mode (SMM)

• Setup

UEFI Separates BIOS and OS

 

 

UEFI Firmware Software Stack

• UEFI on top of Legacy isn’t good enough.

• Inherit the same issue

• Legacy is still the heart of the system

• BIOS’s between teams not standardized

–Changes like this mean major overhaul of System BIOS

–Much rework

 

• Foundation lets different teams share code

• Developers can easily move between projects

• Chipset code enabled by Silicon vendor

• Standardization benefits the industry

• IBV provides value add

• Glue code is Open Source

 

 

Summary

• UEFI as an interface is settled –firmly on the Industry’s Roadmap

• UEFI breaks through fundamental BIOS barriers

• UEFI Solves Option ROM problem

• The Framework is not just another “core” code base … It’s a new purpose-built architecture for firmware

– UEFI / EFI on top of BIOS is not a good solution