UEFI Architecture and Technical Overview

Submit New Article

January 8, 2009 8:00 PM PST


Home >> | Back to Courseware Access page >> | Back to Other Courseware Content page >> |

 

UEFI Curriculum

About UEFI

UEFI-Framework Course Contents

Introduction to PC Architecture

Beyond BIOS

UEFI Introduction

UEFI Architecture and Technical Overview

UEFI Application

UEFI Shell

UEFI Boot Manager

UEFI Services

UEFI Drivers

Framework Architecture and Technical Overview

Labs

References

Potential research topics

Agenda

• UEFI Technical Overview

– UEFI Terminology – What is the UEFI System Table?

– What is a Device Path

– EFI 1.1 and UEFI 2.0 differences

– EFI Byte code

• Technology not addressed by UEFI

• Summary

 

Contents

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




Center


• 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