3. UEFI驱动模型：从Driver Binding到I/O Abstraction
UEFI驱动模型，说白了就是一套标准化的“插拔”框架。你想想看，BIOS要管理那么多设备——显卡、网卡、硬盘控制器——如果每个驱动都自己搞一套加载逻辑，那系统早就乱套了。UEFI规范定义了一套统一的驱动模型，让所有驱动遵循同样的“契约”来工作。
我个人习惯把UEFI驱动模型拆成四个核心部分来理解：Driver Binding Protocol（驱动的“身份证”和“操作手册”）、I/O Abstraction（硬件访问的“翻译官”）、Handle Database（系统里的“设备花名册”），以及Protocol Interface（驱动之间的“通信协议”）。下面我们一个一个说。
核心观点：UEFI驱动模型的核心思想是“驱动与设备分离”。驱动不直接操作硬件，而是通过Protocol Interface来访问设备。这种设计让驱动具有了可移植性和可组合性。
3.1 Driver Binding Protocol：驱动的“身份证”
每个UEFI驱动都必须实现一个EFI_DRIVER_BINDING_PROTOCOL。这个Protocol定义了三个关键函数：Supported()、Start()和Stop()。嗯，这里要注意：Supported()只是“检查”设备是否支持，不修改任何状态；Start()才是真正“绑定”设备并初始化驱动的地方。
我在项目中遇到过一个问题：某个网卡驱动在Supported()里做了硬件寄存器读取，结果导致系统在枚举设备时频繁崩溃。后来我查了UEFI规范才发现，Supported()应该只做“轻量级”检查——比如比对Vendor ID和Device ID，而不应该触碰硬件。这个坑，我踩过，你们别踩。
typedef struct _EFI_DRIVER_BINDING_PROTOCOL {
EFI_DRIVER_BINDING_SUPPORTED Supported;
EFI_DRIVER_BINDING_START Start;
EFI_DRIVER_BINDING_STOP Stop;
UINT32 Version;
EFI_HANDLE ImageHandle;
EFI_HANDLE DriverBindingHandle;
} EFI_DRIVER_BINDING_PROTOCOL;实战技巧：在Supported()函数中，尽量使用EFI_OPEN_PROTOCOL_BY_DRIVER属性来打开Protocol。这样如果驱动加载失败，系统可以自动回滚，不会留下“半初始化”的设备。
3.2 I/O Abstraction：硬件访问的“翻译官”
UEFI驱动不直接读写硬件端口或内存映射寄存器，而是通过I/O Abstraction层来访问。这层抽象通常由PCI I/O Protocol或Block I/O Protocol提供。说白了，驱动只需要调用PciIo->Mem.Read()或PciIo->Io.Write()，底层怎么操作硬件，驱动不用管。
我曾经调试过一个SATA控制器驱动，死活读不到硬盘的ID信息。折腾了两天，最后发现是驱动直接用了MmioRead32()去读BAR0寄存器，而没有通过PCI I/O Protocol来访问。UEFI固件在启动过程中可能已经对PCI配置空间做了重映射，直接读物理地址是拿不到正确数据的。这个教训让我记住了：永远不要绕过I/O Abstraction。
| I/O Protocol | 用途 | 典型接口 |
|---|---|---|
| EFI_PCI_IO_PROTOCOL | 访问PCI配置空间、BAR、DMA | Pci.Read(), PciIo.Mem.Read() |
| EFI_BLOCK_IO_PROTOCOL | 读写块设备（硬盘、U盘） | ReadBlocks(), WriteBlocks() |
| EFI_SIMPLE_TEXT_INPUT_PROTOCOL | 键盘输入 | ReadKeyStroke() |
| EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL | 屏幕输出 | OutputString() |
3.3 Handle Database：系统的“设备花名册”
UEFI固件维护着一个全局的Handle Database。每个设备、每个驱动实例、甚至每个Protocol实例，都有一个唯一的EFI_HANDLE。你可以把Handle Database想象成一本花名册：每个Handle是一个“人”，而Protocol是这个人拥有的“技能”。
系统通过gBS->InstallProtocolInterface()来注册一个Protocol到某个Handle上，通过gBS->LocateProtocol()来查找某个Protocol。我记得有一次调试USB键盘驱动，发现键盘始终无法输入。后来用gBS->LocateHandleBuffer()枚举了所有Handle，才发现USB Hub的Handle上根本没有安装EFI_USB_IO_PROTOCOL——原来是Hub驱动根本没加载成功。
避坑指南：我曾经在Start()函数里忘记调用gBS->InstallProtocolInterface()来安装驱动提供的Protocol。结果驱动虽然加载了，但其他驱动找不到它提供的服务。记住：驱动加载后，必须显式安装它提供的Protocol，否则等于白干。
3.4 Protocol Interface：驱动之间的“通信协议”
Protocol Interface是UEFI驱动模型中最灵活的部分。每个Protocol就是一个结构体，里面包含一组函数指针和数据字段。驱动A可以通过gBS->OpenProtocol()来获取驱动B的Protocol，然后调用里面的函数。这种设计让驱动之间实现了“松耦合”——只要遵守同一个Protocol契约，驱动A和驱动B可以来自不同的厂商。
举个例子：文件系统驱动会安装EFI_SIMPLE_FILE_SYSTEM_PROTOCOL，而Shell程序通过OpenProtocol()获取这个Protocol，然后调用OpenVolume()来访问文件。Shell根本不需要知道底层是FAT32还是NTFS——这就是Protocol Interface的魅力。
// 查找并打开一个Protocol
EFI_STATUS Status;
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *FileSystem;
Status = gBS->LocateProtocol(
&gEfiSimpleFileSystemProtocolGuid,
NULL,
(VOID **)&FileSystem
);
if (EFI_ERROR(Status)) {
// 处理错误：没有找到文件系统Protocol
return Status;
}
// 现在可以通过FileSystem->OpenVolume()来访问文件了3.5 驱动模型的工作流程：一张图说清楚
下面这张SVG图展示了UEFI驱动模型的核心工作流程。从驱动加载到设备绑定，再到I/O操作，每一步都离不开我们刚才讲的四个组件。
3.6 实战中的常见问题
讲完了理论，说说我在实际项目中遇到的几个典型问题：
- 驱动加载顺序问题：有时候驱动A依赖驱动B的Protocol，但B还没加载。解决办法是在
Supported()里用gBS->LocateProtocol()检查依赖是否就绪，如果没就绪就返回EFI_UNSUPPORTED，系统会稍后重试。 - Protocol GUID搞错：我曾经把
gEfiPciIoProtocolGuid写成了gEfiPciRootBridgeIoProtocolGuid，结果驱动一直找不到Protocol。记住：Protocol GUID是唯一的，一个字母都不能错。 - Handle泄漏：在
Stop()函数里忘记调用gBS->UninstallProtocolInterface()，导致Handle Database里残留了无效的Protocol。这会导致系统在枚举设备时出现“幽灵设备”。
调试小技巧：在UEFI Shell下，可以用dh命令查看所有Handle，用drivers命令查看已加载的驱动。如果某个设备没有正常工作，先用这两个命令看看驱动是否真的加载了，Protocol是否真的安装了。这比直接看代码快得多。
好了，这一章的内容就到这里。UEFI驱动模型是理解整个UEFI启动流程的基础，后面的章节我们会基于这些概念，深入分析各种启动异常的具体定位方法。