•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