1、UEFI的前世今生：BIOS的局限性、EFI的诞生、UEFI论坛与标准演进
大家好，我是你们的固件工程师老友。今天咱们开篇不讲代码，先聊聊UEFI这家伙是怎么来的。你想想看，一台电脑从按下电源键到进入操作系统，中间那几秒钟到底发生了什么？这背后就是固件在干活。而UEFI，就是干这活的新一代“总管”。
我个人习惯，学任何技术都得先搞清楚它为什么出现。不然你学了一堆API，遇到问题还是懵。所以第一章，咱们就回到上世纪80、90年代，看看那个叫BIOS的老前辈，到底哪里不行了。
1.1 BIOS的局限性：那个“16位”的老伙计
BIOS，全称Basic Input/Output System。说实话，它在当年绝对是神作。在DOS时代，它用16位实模式，用1MB地址空间，把硬件抽象得明明白白。我刚开始做固件时，还在老式工控板上调过BIOS，那会儿觉得这东西挺稳的。
但时代变了。进入21世纪，BIOS的短板越来越明显。我列几个最要命的：
- 16位实模式的枷锁：CPU都64位了，BIOS还在16位模式下爬。寻址空间只有1MB，连个2GB内存条都认不全。
- MBR分区表的2TB墙：MBR最大支持2TB磁盘。现在随便一个NAS硬盘都4TB起步，BIOS直接“不认盘”。
- 中断向量表太脆弱：BIOS靠INT 10h、INT 13h这些中断提供服务。一旦操作系统接管，这些中断就废了，没法复用。
- 没有统一驱动模型：每个硬件厂商写自己的Option ROM，动不动就打架。我遇到过显卡Option ROM和网卡PXE ROM冲突，机器直接黑屏。
- 用户界面太原始：蓝底白字，键盘操作，连个鼠标都不支持。你想想看，2025年的用户看到这个界面，不骂娘才怪。
核心痛点一句话总结：BIOS是为单任务、小磁盘、低分辨率时代设计的。它没法优雅地支持64位CPU、大内存、大磁盘和现代图形界面。
嗯，这里要注意，BIOS不是不能用，而是“凑合着用”。但服务器、工作站、高性能PC对可靠性和扩展性的要求越来越高，BIOS这老伙计真的扛不住了。
1.2 EFI的诞生：Intel的“救火队”
为什么会是Intel站出来？因为Intel是平台老大。1990年代末，Intel搞安腾（Itanium）处理器时发现，BIOS根本没法支持64位架构。于是，Intel在1998年启动了“Intel Boot Initiative”项目，后来改名为EFI（Extensible Firmware Interface）。
EFI的设计思路，说白了就是“把固件当做一个微型操作系统”。它有几个革命性的设计：
- 抛弃16位，拥抱64位：EFI从一开始就是纯64位代码，直接跑在CPU的64位模式下。
- 用C语言写固件：不再用汇编。开发效率高了一个数量级。
- 引入驱动模型：EFI Driver Model，让硬件厂商可以写标准的EFI驱动，不再依赖Option ROM那套野路子。
- GPT分区表：支持2TB以上磁盘，理论上最大支持9.4ZB。
- 图形界面：支持鼠标、高分辨率、多语言。
我记得第一次在模拟器里跑通EFI Shell时，那种感觉就像从DOS一下子跳到了Windows。你能直接打命令操作文件系统、加载驱动、启动应用，太爽了。
一个小知识：EFI Shell其实是一个命令行解释器，类似Linux的bash。你可以在里面执行.efi程序，调试硬件。我当年排查一个NVMe驱动加载失败的问题，就是在EFI Shell里一步步手动加载驱动，最后发现是PCIe配置空间没写对。
1.3 UEFI论坛与标准演进：从Intel私货到行业标准
EFI虽然是好东西，但它是Intel的“私货”。其他芯片厂商（AMD、ARM）不乐意了：凭什么我家的CPU要用你Intel的固件标准？
于是，2005年，Intel把EFI 1.10规范贡献给了统一可扩展固件接口论坛（UEFI Forum）。这个论坛的成员包括Intel、AMD、Microsoft、Apple、AMI、Phoenix等巨头。从此，EFI改名为UEFI（统一EFI）。
标准演进有几个关键节点：
| 版本 | 发布时间 | 关键变化 |
|---|---|---|
| EFI 1.02 | 2000年 | Intel发布首个公开版本，定义基本框架 |
| EFI 1.10 | 2002年 | 增加驱动模型、协议接口、UEFI Shell |
| UEFI 2.0 | 2006年 | 论坛接管，增加安全启动（Secure Boot） |
| UEFI 2.3.1 | 2011年 | 增加UEFI网络引导、HTTP Boot |
| UEFI 2.7 | 2017年 | 增加NVDIMM Firmware Interface、改进安全启动 |
| UEFI 2.10 | 2022年 | 增加机密计算、平台固件安全更新 |
从这张表你能看出来，UEFI一直在进化。它不再只是“启动固件”，而是变成了一个平台固件管理框架。安全、网络、存储、虚拟化，全都能管。
避坑指南：我曾经在移植UEFI固件到ARM平台时，踩过一个坑——UEFI规范里很多接口默认假设x86的IO空间和PCIe配置机制。ARM平台没有IO空间，你得用MMIO方式重新实现。所以，读规范时一定要看“Platform-Specific”章节，别想当然。
1.4 知识体系框架：一张图看懂UEFI的“前世今生”
下面这张SVG图，把BIOS的局限、EFI的诞生、UEFI的演进串起来了。你一看就明白。
这张图把三个时代的关系讲清楚了。BIOS是起点，EFI是转折点，UEFI是终点（或者说新起点）。你记住这个脉络，后面学启动流程时，就知道每个阶段为什么要那么设计。
1.5 小结：为什么你必须懂这段历史？
我见过不少工程师，上来就啃UEFI规范，结果被Protocol、Handle、Image Loader搞得一头雾水。为什么？因为你不理解这些概念是为了解决什么问题而生的。
举个例子：UEFI的Protocol机制，说白了就是为了替代BIOS的中断向量表。BIOS用中断号找服务，UEFI用GUID找Protocol。你理解了“为什么要有Protocol”，再看代码就顺了。
所以，第一章虽然不写代码，但它是你后面29章的“地基”。地基稳了，楼才盖得高。
一句话记住本章：BIOS是16位的老古董，EFI是Intel的64位救星，UEFI是行业统一标准。三者一脉相承，但设计思想天差地别。