1. UEFI与固件程序设计
Tel：
同济大学软件学院

2. What’s the UEFI?
The Unified Extensible Firmware Interface (UEFI) specification defines a new model for the interface between operating systems and platform firmware.
It provides a standard, modern environment for booting an operating system and running pre-boot applications.
It works to standardize two primary functions of the PC Basic Input/Output System (BIOS): firmware-to-OS interface and platform initialization. 继续 返回

3. Agenda
UEFI Forum
UEFI Technical Concept
Summary 继续 返回

4. Agenda
UEFI Forum
UEFI Technical Concept
Summary 继续 返回

5. The UEFI Forum -- http://www.uefi.org
The Unified EFI Forum is a non-profit collaborative trade organization formed to promote and manage the UEFI standard.
Eleven leading companies: 继续 返回

6. UEFI Membership Promoters: board and corporate officers Contributors:
Corporations, groups or individuals wanting to participate in UEFI
Chance to join work groups and contribute to spec or test development
Early access to drafts and work in progress
Adopters:
Any entity wanting to implement the specification 继续 返回

7. How the UEFI Forum Works
Board sets strategic direction
Charters work groups to implement direction
Work groups drawn from membership
Staffed by Promoters and Contributors
Board approves work groups proposals
Work Groups:
USWG – UEFI Specification Working Group
-Responsible for UEFI Spec production
UTWG – UEFI Testing Working Group
-Responsible for publishing SCT( Self Certification Test )
PIWG – Platform Initialization Working Group
-Responsible for the spec that will eventually replace
the framework level specs
ICWG – Industry Communications Working Group 继续 返回

8. Forum’s Architecture 继续 返回 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. 继续 返回

9. The UEFI Forum -- http://www.uefi.org
UEFI Specification
EFI 1.10 specification contributed to the Forum by Intel and Microsoft to be used as a starting draft
UEFI 2.3 specification released.(2010.2)
Forum will evolve, extend, and add any new functionality as required 继续 返回

10. Agenda
UEFI Forum
UEFI Technical Concept
Summary 继续 返回

11. UEFI Operational ModelOS
Booted
Failure
Platform
Init
Standard
firmware
platform
initialization
OS Loader
UEFI
Application
UEFI Image
Load
Driver
Drivers and
applications
loaded
iteratively
Boot Services
Terminate
Operation
handed off
to OS loader
Boot Manager
UEFI binaries
Boot code
UEFI OS Loader
Boot from
ordered list
of EFI OS
loaders
Retry
API specified
Value add implementation
UEFI API 继续 返回

12. UEFI Conceptual Overview
OPERATING SYSTEM
Legacy OS LOADER
UEFI OS LOADER
UEFI API
Compatibility
UEFI BOOT SERVICES
UEFI
RUNTIME
SERVICES
UEFI or
Framework
Drivers
Driver
Driver
Memory
Timer
Boot
Devices
Framework
Protocols +
Handlers
(OTHER)
SMBIOS
ACPI
INTERFACES
FROM
OTHER
REQUIRED
SPECS
PLATFORM SPECIFIC FIRMWARE
PLATFORM HARDWARE
UEFI OS
Loader
UEFI SYSTEM
PARTITION
UEFI
Drivers
OS PARTITION
Motherboard
ROM/FLASH
Option
ROM
Option
ROM
Option
ROM
UEFI Drivers
UEFI
Drivers 继续 返回

13. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

14. Boot support -- System Partition
Architectural Sharing
System partition
Location for OS loaders
Applications and drivers
FAT32 Format
FAT32 spec now “public”
Tried and tested format
Readily available tools
Interoperability layout
Multiple system partitions
Supports multiple OS installs
New Partition Structure
64 bit partition sizes
Unlimited # of partitions
Co-exists w/ legacy MBR 继续 返回

15. Boot support -- GUID(Globally Unique Identifiers) Partition Table (GPT)
First useable block
Start partition
End partition
LBA0
LBA1
LBAn
MBR
Table HDR
Partition 1
... n
Partition 1
Table HDR
Partition
... 1 n
Start partition
End partition
Last useable block
Primary Partition
Table
Backup Partition
Table 继续 返回

16. Boot support -- Boot device
Hard disk
Removable media
CD-ROM, DVD-ROM
Floppy, LS-120 SuperDisk, Iomega Zip, Fujitsu MO etc.
Network
PXE BIOS support specification (WfM)
Future media via extensibility methods
Full device support 继续 返回

17. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

18. Key Elements
Objects -- manage system state, including I/O devices, memory,
and events
UEFI System Table -- data structure with data
information 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 继续 返回

19. Key Elements --- UEFI Objects 继续 返回 EFI SYSTEM Images Memory TABLE
Environment
Variables
Events
Handles
And
Protocols
Monotonic
Counter
Time / Date
Watch Dog
Timer 继续 返回

20. Key Elements --- UEFI System Table
This main entry point is the same for UEFI Applications, UEFI OS Loaders, and UEFI Drivers.
The System Table contains pointers to the active console devices, a pointer to the Boot Services Table, a pointer to the Runtime Services Table, and a pointer to the list of system configuration tables such as ACPI, SMBIOS, and the SAL System Table. 继续 返回

21. EFI System Table Pointer
Key Elements
--- UEFI System Table
EFI System Table Pointer
IBI
Runtime Services ptr
Boot Services ptr
Runtime Services
ACPI Table
Boot Services
SMBIOS Table
Block IO
Disk IO
Console output
Etc.
New std ??? 继续 返回

22. UEFI Data Structures 继续 返回 EFI System Table
Input Console
Active Consoles
Output Console
Standard Error Console
EFI System Table
EFI Runtime Services Table
Variable Services
Real Time Clock Services
Reset Services
Capsule Services
Virtual Memory Services
EFI Boot Services Table
Task Priority Level Services
Memory Services
Event and Timer Services
Protocol Handler Services
Image Services
Driver Support Services
Version Information
EFI Specification Version
Firmware Vendor
Firmware Revision
Handle Database
Protocol Interface
Protocol Interface
Boot Service Data Structures
Runtime Data Structures 继续 返回

23. Key Elements --- GUID “Globally” Unique Identity
-The 128-bit Globally Unique Identifier (GUID) for the protocol interface.
A sample of the EFI GUID format 继续 返回

24. Key Elements --- GUID Used to identify protocols
-1:1 with interfaces
Regulate extension mechanism
-Documented in the spec
-Added through drivers 继续 返回

25. Key Elements --- protocols Each protocol includes the following:
The protocol’s globally unique ID(GUID)
The protocol Interface structure
The protocol services 继续 返回

26. Key Elements --- protocols HandleProtocol(GUID,…) 继续 返回 Handle GUID
Protocol Interface
Access
Device or
Services
Produced by
Other UEFI
Drivers
Function 1
Function Ptr 1
Function Ptr 2
Function 2
. . .
Private Data
. . .
GUID 2
. . .
BlkIo->ReadBlocks(BlkIo, …) 继续 返回

27. Key Elements --- Handle Database
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 继续 返回

28. Key Elements --- Handle Database 继续 返回 ... First Handle Handle GUID
Protocol
Interface
Instance
Data
Image Handle
Controller Handle
Attributes 继续 返回

29. Key Elements --- UEFI Images
UEFI uses a subset of the PE32+ image format
UEFI image memory Types 继续 返回

30. Key Elements --- 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 继续 返回

31. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

32. Complete and size efficient
Boot service
Events and notifications
Polled devices, no interrupts
Watchdog timer
Elegant recovery
Memory allocation
Handle location – for finding protocols
Image loading
Drivers, applications, OS loader
Complete and size efficient 继续 返回

33. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

34. Minimal set to meet OSV needs
Runtime service
Services available at both boot time and runtime
Timer, Wakeup alarm
Allows system to wake up or power on at a set time.
Variables
Boot manager handshake
Capsule
System reset
Minimal set to meet OSV needs 继续 返回

35. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

36. Driver model
The UEFI Driver Model does not attempt to describe the processors or the core chipsets.
Instead, the UEFI Driver Model describes the set of I/O buses produced by the core chipsets, and any children of these I/O buses.
These children can either be devices or additional I/O buses. This can be viewed as a tree of buses and devices with the core chipsets at the root of that tree. 继续 返回

37. Driver model Used for devices on industry standard buses
“boot devices”
Structured model of device/bus hierarchy
Device Drivers and Bus Drivers
Device Drivers are topology agnostic
Benefits
Simpler Device Drivers
-Moves complexity into Bus Drivers and core services
-Smaller driver footprint
Deterministic driver selection by the platform
-Which driver controls which device
Describes complex bus hierarchies
-Embedded, Desktop, Workstation, Server
Extensible to future bus types 继续 返回

38. Driver model
a sample desktop system 继续 返回

39. Driver model
Server System 继续 返回

40. Driver Initialization
Step 1: the boot service LoadImage(). 继续 返回

41. Driver Initialization
Step 2: the boot service StartImage(). 继续 返回

42. Host Bus Controllers Host Bus Controllers
This initial collection of controllers is known as the Host Bus Controllers.
a platform with n processors (CPUs), and a set of core chipset components that produce m host bridges.
Host Bus Controllers 继续 返回

43. Host Bus Controllers PCI Root Bridge Device Handle
Each host bridge(HB) is represented in UEFI as a device handle that contains a Device Path Protocol instance, and a protocol instance that abstracts the I/O operations that the host bus can perform.
PCI Root Bridge Device Handle 继续 返回

44. Device Drivers PCI Root Bridge Device Handle
Each host bridge(HB) is represented in UEFI as a device handle that contains a Device Path Protocol instance, and a protocol instance that abstracts the I/O operations that the host bus can perform.
PCI Root Bridge Device Handle 继续 返回

45. Bus Drivers
Bus drivers and device drivers are virtually identical from the UEFI Driver Model’s point of view.
The only difference is that a bus driver creates new device handles for the child controllers that the bus driver discovers on its bus.
Child Device Handle with a Bus Specific Override 继续 返回

46. Driver Design Steps Driver or Application Determine the driver’s type
Identify I/O protocols to be consumed
Identify I/O protocols to produce
Implement UEFI driver model protocols
Implement specific protocols
All Drivers
Service Drivers
UEFI Driver Model
Initializing Drivers
Bus
Drivers
Hybrid Drivers
Device
Drivers
Root Bridge Drivers 继续 返回

47. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

48. EFI Byte Code MEMORY Legacy 16/32 bit EFI Byte Code 继续 返回
IA-32 (BIOS)
Legacy 16/32 bit
Itanium
EFI Byte Code
IA-32 (EFI)
Single image supports multiple platforms
Code is interpreted on
Intel Itanium® Architecture and IA systems
IHVs develop only once 继续 返回

49. Agenda UEFI Forum UEFI Technical Concept Summary Boot support
Key Elements
Boot Service
Runtime Service
UEFI Driver Model
EFI Byte Code
Summary 继续 返回

50. Summary UEFI settle interface firmly on the Industry’s Roadmap
UEFI breaks through fundamental BIOS barriers
UEFI solves legacy Option ROM problems
UEFI offers flexible solution to meet existing and future needs 继续 返回