1. 课程导入
在今天的服务器、笔记本、工控机乃至云主机中，按下电源键后最先运行的那段固件，绝大多数已经不是传统BIOS，而是UEFI。它决定了内存如何初始化、CPU如何从复位向量进入保护模式、操作系统内核从哪里被加载、安全启动是否放行。对于做底层开发、固件开发、系统安全或驱动开发的人来说，UEFI不是“开机画面”，而是一套完整的、可编程的、模块化的固件运行时环境。本课程的目标，是带你从“知道UEFI”走到“能写UEFI驱动、能调试启动流程、能定位启动故障”。
一、UEFI的起源与发展历程
传统BIOS诞生于1975年的CP/M时代，后来被IBM PC沿用，逐渐形成以中断向量表、16位实模式、512字节MBR引导扇区为核心的固件模型。它的优点是简单、兼容性极强；缺点是受限于16位实模式、1MB寻址空间、汇编实现、扩展困难、启动过程黑盒化。随着安腾处理器和EFI 1.0在2000年前后出现，Intel提出了“可扩展固件接口”EFI，随后交由统一EFI论坛（UEFI Forum）标准化，形成UEFI规范。UEFI 2.x逐步引入安全启动、网络协议栈、运行时服务、ACPI协作、驱动模型等能力，成为现代平台固件的事实标准。
从技术演进看，UEFI经历了几个关键阶段：EFI 1.10解决“可扩展”问题；UEFI 2.0引入安全启动与驱动模型；UEFI 2.3以后强化网络与运行时服务；UEFI 2.7以后进一步支持现代安全特性和平台管理。今天，UEFI已经不只是“引导操作系统”，它还承担固件更新、安全启动、设备初始化、平台配置、运行时变量管理等职责。
二、UEFI与传统BIOS的核心对比
理解UEFI，最有效的方式是把它和传统BIOS放在同一张表里对比。下面这张表覆盖了执行环境、引导方式、扩展能力、安全模型和开发方式五个维度。
| 对比维度 | 传统BIOS | UEFI |
|---|---|---|
| 执行环境 | 16位实模式，1MB寻址 | 32/64位保护模式，平坦寻址 |
| 引导方式 | 读取MBR，跳转引导扇区 | 加载FAT分区中的EFI应用（.efi） |
| 扩展能力 | 中断向量、Option ROM，汇编为主 | Protocol驱动模型，C语言开发 |
| 安全模型 | 基本无验证，易被Bootkit感染 | Secure Boot、签名验证、度量启动 |
| 开发调试 | 汇编、工具链封闭、调试困难 | EDK II、开源、支持源码级调试 |
需要强调的是，UEFI并不是“BIOS的简单升级”，而是固件架构的范式变化：从“中断驱动的实模式固件”变成“协议驱动的模块化运行时”。这也是为什么学习UEFI必须理解Protocol、Handle、Image、Event、Boot Service与Runtime Service这些概念。
三、UEFI启动流程的核心原理
UEFI启动可以概括为“SEC→PEI→DXE→BDS→TSL→RT”六个阶段。SEC负责建立临时内存和传递启动参数；PEI负责内存初始化与早期硬件发现；DXE负责加载驱动、建立协议数据库；BDS负责选择启动项并加载EFI应用；TSL是操作系统加载器运行阶段；RT是操作系统接管后的运行时阶段。整个过程不是简单的顺序执行，而是通过HOB、PPI、Protocol、Event等机制在阶段之间传递信息。
四、学习目标与课程整体框架
本课程围绕“原理—工具—开发—调试—实战”五条主线展开。学完后，你应当能够：
- 说清UEFI六个启动阶段各自做什么、阶段之间如何传递数据；
- 理解Protocol、Handle、Image、Event、Boot Service、Runtime Service等核心概念；
- 搭建EDK II开发环境，编译并运行一个UEFI应用或驱动；
- 使用QEMU/OVMF、串口日志、调试器定位启动失败问题；
- 理解Secure Boot、变量存储、固件更新等工程场景；
- 完成一个可加载、可调试、可验证的UEFI驱动实战项目。
课程整体框架分为四个模块：第一模块是基础与规范，覆盖UEFI起源、启动流程、EDK II工程结构；第二模块是驱动开发，覆盖Protocol、驱动模型、事件与异步；第三模块是启动与安全，覆盖BDS、Secure Boot、变量与固件更新；第四模块是实战与排障，覆盖QEMU调试、日志分析、常见启动故障复盘。
实战路线建议：先跑通OVMF+QEMU，再写HelloWorld.efi，然后写一个简单的DXE驱动并加载，最后接入串口日志和调试器。不要一开始就啃规范，先让代码跑起来，再回头理解规范。
五、常见误区与复盘
初学者最容易踩的坑有三个。第一，把UEFI当成“BIOS的升级版”，忽略Protocol驱动模型，结果看不懂DXE为什么能动态加载驱动。第二，只关注启动流程，不关注数据传递，导致调试时不知道HOB、PPI、Protocol分别在哪一阶段使用。第三，跳过工具链直接读规范，结果概念记住了，但无法编译、无法运行、无法定位问题。
排障提醒：UEFI启动失败时，优先看串口日志中的阶段标记。如果卡在PEI，重点查内存初始化和HOB；如果卡在DXE，重点查驱动依赖和Protocol是否安装；如果卡在BDS，重点查启动项变量和EFI应用路径。
下面给出一个最小化的EDK II工程目录结构，后续章节会逐步展开每个文件的作用。
MyFirstUefiPkg/
├── MyFirstUefiPkg.dec
├── MyFirstUefiPkg.dsc
├── Application/
│ └── HelloUefi/
│ ├── HelloUefi.c
│ └── HelloUefi.inf
└── Driver/
└── SimpleDxe/
├── SimpleDxe.c
└── SimpleDxe.inf本章的核心不是记住所有细节，而是建立一张“UEFI地图”：知道启动阶段怎么走、数据怎么传、驱动怎么加载、问题怎么查。接下来，我们会从UEFI规范与EDK II工程结构开始，逐步把这张地图变成可以动手操作的能力。