简介《一个UEFI引导程序的实现》面向操作系统理论初学者、软件工程师与固件开发爱好者围绕从传统BIOS迁移到UEFI引导展开帮助理解两类固件的结构、启动流程及UEFI取代BIOS的原因。文件共1个为PDF格式压缩包约2.36MB内容按章节组织便于系统查阅。已有2381人学习下载在操作系统引导与固件开发主题下具有一定参考价值。书中从TianoCore EDK2环境搭建、UEFI Shell编译执行、GPT磁盘布局与ESP文件系统讲起通过Hello World、UEFI镜像、系统表、调用约定与协议等实例建立开发基础随后逐步实现图形显示模式配置、物理内存获取、文件读取、64位平台处理及系统内核引导启动可作为学习Linux内核源代码和《一个64位操作系统的设计与实现》的补充材料。1. 从固件 Logo 卡住那一刻开始这本电子书能带你走到哪一步一块自制的引导盘插上去固件菜单里死活看不到它或者好不容易把自研内核塞进 ESP跳过去第一行就三重故障重启。这类问题在论坛上问十次有九次答不到点上因为大多数人根本没弄清固件从上电到交权到底走了哪几步。这份文字版电子书讲的就是这条链路从 BIOS 与 UEFI 的结构差异、七个启动阶段一路讲到用 EDK2 搭环境、写 Hello World、做 GPT 与 ESP、配置图形显示模式、取物理内存、从存储介质读文件最后把控制权交给 64 位内核。它适合写过 C、摸过一点汇编、想让自己的内核在虚拟机或真机上真正跑起来的人完全没碰过裸机编程的话前半本会读得很吃力。2. UEFI 替掉 BIOS 的底气七个阶段与三条硬指标2.1 从 0xFFFF0 到 DXE两条启动链到底差在哪BIOS 那条链的起点很固定。上电后 CPU 处于实模式位宽 16 位能寻址的物理空间只有 0~1MB其中 0x0C0000~0x0FFFFF 这段被划给固件自己用。CPU 复位后第一条指令的地址是 0x0FFFF0那儿通常只放一条跳转指令跳进真正的入口之后才开始干活POST 自检、初始化显示设备、检测 CPU 与内存容量、枚举标准设备与即插即用设备、把变动的配置写回 CMOS、按启动顺序把引导扇区读进内存、最后把控制权交给引导程序。整条链是线性铺开的每一步都写死在固件里加一个设备就得动一次固件。UEFI 则是分层推进官方划分是七个阶段。SEC 阶段在内存还没初始化的时候抢跑用处理器缓存当临时内存把 CPU 切到保护模式PEI 阶段初始化内存、CPU 和芯片组因为这段代码没压缩所以必须足够精简DXE 是重头戏绝大多数驱动和协议在这一阶段被加载和分发BDS 阶段读控制台相关的环境变量、按变量里记录的路径去加载启动项TSL 阶段进入 UEFI Shell 这种临时环境操作系统加载器也活在这一层RT 阶段的开关是ExitBootServices一旦调用成功DXE 和引导服务全部销毁只剩运行时服务和系统表还能用AL 阶段对应ResetSystem或者 ACPI 休眠异步事件也能把系统踢进去。这个差别带来的直接后果是BIOS 阶段之间靠跳转串联UEFI 阶段之间靠句柄和协议解耦。你在 DXE 阶段加载的一个驱动只要发布了协议后面的 BDS 甚至操作系统加载器都能直接找到它不需要事先知道它在哪个地址。维度BIOSUEFI运行模式实模式16 位保护模式 / IA-32e寻址上限1MB固件窗口 0x0C0000~0x0DFFFF平坦物理地址空间代码语言汇编为主C / C 为主驱动模型静态链接写死中断向量模块化运行期按需加载设备访问方式中断事件 异步操作引导介质MBR 引导扇区GPT ESP 中的 PE/COFF 镜像可执行文件校验无安全启动开启时校验签名看这张表的时候别只盯着“UEFI 更先进”真正决定你要不要动手的是最后一列引导介质和校验方式变了意味着你之前那套写 MBR、硬编码扇区号的引导代码在 UEFI 机器上根本没机会被执行。2.2 换固件的三个硬理由2TB、汇编耦合、签名校验第一个硬指标是寻址。BIOS 读硬盘用的是 32 位 LBA能表达的最大逻辑块号是 2^32乘以每扇区 512 字节算下来正好 2TB。超过这个容量引导扇区就放不到能被寻址的位置上系统直接起不来。GPT 把 LBA 扩到 64 位理论上限大到不用考虑这是大容量盘普及之后绕不过去的一道坎。第二个是开发效率与耦合度。传统固件代码大量用汇编写好处是贴硬件坏处是每换一代芯片组就得重写一遍代码和设备的耦合度高到离谱。UEFI 把绝大部分逻辑挪到 C 语言应用和驱动甚至能用 C底层差异被引导服务和运行时服务这两套接口挡住了。驱动做成独立模块可以编进固件也可以躺在设备上等着被动态加载每个表和协议还带版本号升级不用整体推倒。第三个是安全。传统固件在跑可执行代码之前基本不做校验谁把引导扇区改了谁就能拿到控制权。UEFI 的应用程序和驱动是 PE/COFF 格式签名塞在签名块里安全启动打开之后固件会先验签再执行证书不在信任列表里就直接拒绝。这条对做内核开发的人其实是双刃剑你自己编的引导程序大概率没有签名真机上要么关掉安全启动要么自己走一遍签名流程。还有一个常被忽略的性能点UEFI 舍弃了中断这种开销较大的外设访问方式只保留时钟中断外部设备操作走“事件 异步”。启动时也不需要把所有设备都枚举一遍只遍历启动路径上用得着的那些这就是为什么同一台机器换固件之后开机时间能明显缩短。2.3 引导程序站在链条的哪个位置这里要先厘清一个容易混淆的点这本电子书做的是一个 UEFI 应用程序并非 UEFI 固件。它运行在 BDS 完成之后、TSL 阶段之内和操作系统加载器处在同一个层级。固件已经把所有脏活干完了——内存初始化好了、磁盘驱动挂上了、图形输出能用、文件系统协议也发布了——你的程序只需要拿着系统表一项一项去调用。所以整个引导程序的主线可以概括成五步通过gBS-LocateProtocol拿到图形输出协议把显示模式切到目标分辨率调gBS-GetMemoryMap拿到当前物理内存布局筛掉固件自己占用的区域用简单文件系统协议打开 ESP 上的内核文件读进刚申请的内存把 CPU 切到 64 位长模式并准备好页表最后ExitBootServices交权跳到内核入口。后面三章就是按这个顺序拆开的。3. 把 EDK2 跑起来从克隆源码到拿到 OVMF.fd3.1 依赖包与分支选择为什么必须锁 UDK2018源码编译这条路最容易翻车的地方其实不在编译本身而在版本。EDK2 的 BaseTools 和各个包的 dsc 文件语法会随版本演进你今天克隆下来的主干代码和书里写的TOOL_CHAIN_TAG、ACTIVE_PLATFORM很可能对不上报错信息还特别隐晦。稳妥的做法是先切到书里用的那个稳定分支把整条链路跑通再去试新版。下面是 RHEL 系发行版上的完整准备流程。注意build-essential是 Debian 系的元包名在 yum 源里根本不存在实际要装的是 gcc、gcc-c、make 这几个iasl是 ACPI 编译器nasm是汇编器uuid-devel提供 UUID 相关头文件BaseTools 编译时会用到。# 安装编译依赖RHEL 系包名别照抄 Debian 的 build-essential yum install -y gcc gcc-c make git uuid-devel libuuid-devel iasl nasm acpica-tools # 克隆主仓库 git clone https://github.com/tianocore/edk2.git cd edk2 # 锁定稳定分支避免 BaseTools 与 dsc 语法漂移 git checkout UDK2018 # 先编基础工具这一步失败后面全免谈 make -C BaseTools/make -C BaseTools/这一行是整个环境的基础它编出来的是build命令本身、各种代码生成器和打包工具。这一步过了才轮到设置环境变量。注意. ./edksetup.sh前面那两个点等价于source作用是让脚本里导出的WORKSPACE、EDK_TOOLS_PATH等变量留在当前 shell 里。如果你习惯直接敲./edksetup.sh脚本在一个子 shell 里跑完就退出变量一个都没留下后面build会告诉你找不到工作空间。# 初始化环境变量注意前面的点号不能省 . ./edksetup.sh # 旧版本里也可以用这个脚本做一次完整性检查 BaseTools/BuildEnv分支选择这件事血泪经验是不要一上来就追最新。新版 EDK2 已经把edksetup.sh的参数改了还引入了pip依赖的 Python 工具链在没有网络代理的机器上会卡很久。先把 UDK2018 这条老路走通理解每个变量管什么再迁移到新版成本低得多。3.2 target.txt 三个变量改错一个就编不出东西Conf/target.txt是模块组的编译配置里面几十个变量真正决定成败的是三个。ACTIVE_PLATFORM指向平台描述文件.dsc的相对路径它决定了这次编译要打哪些包、生成什么形态的固件TOOL_CHAIN_TAG指定编译器工具链标签标签名必须和Conf/tools_def.txt里定义的一致TARGET_ARCH是目标体系结构写X64就是 64 位。变量作用常见取值配错的典型症状ACTIVE_PLATFORM指定平台 dsc 路径OvmfPkg/OvmfPkgX64.dsc报找不到模块或 dsc 不存在TOOL_CHAIN_TAG指定工具链GCC48/GCC5提示未知工具链标签TARGET_ARCH目标架构X64/IA32生成的镜像入口位数不对编译 OVMF开放虚拟机固件时配置写成下面这样。OVMF 的价值在于它是一份能直接喂给虚拟机的完整 UEFI 固件你改完引导程序不用刷真机 BIOS 就能验证出问题大不了重开虚拟机。# Conf/target.txt 中需要修改的三行 ACTIVE_PLATFORM OvmfPkg/OvmfPkgX64.dsc TOOL_CHAIN_TAG GCC48 TARGET_ARCH X64改完配置先别急着build。OVMF 依赖若干个子模块主仓库克隆下来时它们是空的直接编会在链接阶段报一堆符号找不到# 拉取子模块缺这一步会在链接期炸 git submodule update --init --recursive # 开始编译-n 指定并行任务数 build -n $(nproc)编译产物落在Build/OvmfX64/DEBUG_GCC48/FV/OVMF.fd。路径里的DEBUG来自TARGET变量默认 DEBUG可以改成 RELEASE 减小体积GCC48就是前面那个工具链标签。拿到这个 fd 文件虚拟机的固件就有来源了把虚拟机的固件类型从默认改成“使用自定义固件文件”指到这儿即可。如果你机器上的 gcc 版本比较新GCC48那套编译选项可能会因为-Werror把警告当错误而中断这时候换成GCC5标签通常能过。3.3 Hello World 的骨架入口、系统表与调用约定UEFI 应用的入口签名是固定的两个参数一个是本镜像的句柄一个是系统表指针返回值是EFI_STATUS。系统表里挂着三个关键指针——ConOut这类控制台接口、BootServices引导服务退出后失效、RuntimeServices运行时服务退出后仍可用。打印字符串走的是ConOut-OutputString注意换行必须用\r\n只写\n在某些终端上会变成阶梯状输出。#include Uefi.h #include Library/UefiBootServicesTableLib.h #include Library/UefiLib.h // EFIAPI 在 x64 下展开为 ms_abi必须与固件调用约定一致 EFI_STATUS EFIAPI UefiMain ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable ) { // ConOut 是系统表里的控制台输出接口换行用 \r\n SystemTable-ConOut-OutputString (SystemTable-ConOut, LHello UEFI\r\n); // 顺手把系统表版本打出来验证 gST 可用 Print (LRevision: 0x%x\r\n, SystemTable-Hdr.Revision); return EFI_SUCCESS; }配套的模块定义文件.inf决定了这个源文件怎么被编译、链接哪些库[Defines] INF_VERSION 0x00010005 BASE_NAME HelloUefi FILE_GUID 9e5f8c2a-4b1d-4a77-9c3e-5d2f1a6b7c80 MODULE_TYPE UEFI_APPLICATION ENTRY_POINT UefiMain [Sources] HelloUefi.c [Packages] MdePkg/MdePkg.dec [LibraryClasses] UefiApplicationEntryPoint UefiLibMODULE_TYPE写UEFI_APPLICATION表示这是个应用而不是驱动ENTRY_POINT必须和源码里的函数名对上。UefiApplicationEntryPoint这个库负责在 PE 入口和你的UefiMain之间做一层跳板少了它链接会报找不到_ModuleEntryPoint。编译时把ACTIVE_PLATFORM换成ShellPkg/ShellPkg.dsc就能编出 UEFI Shell 本体产物是Build/Shell/DEBUG_GCC48/X64/Shell.efi后面做启动盘要用。这里要专门说一下调用约定因为这是很多人从 C 掉进汇编时摔的第一个跟头x64 下EFIAPI展开成微软的调用约定前四个整型或指针参数依次放 RCX、RDX、R8、R9浮点参数走 XMM0~XMM3调用者在call之前必须在栈上预留 32 字节的影子空间并且保证栈 16 字节对齐。你在汇编里调 C 函数少了sub rsp, 0x20这一步函数内部一写局部变量就把返回地址踩了表现是随机崩溃极难定位。4. 让固件认得你的程序GPT、ESP 与 BOOTx64.EFI4.1 GPT 布局与 ESP为什么文件系统必须是 FAT32GPT 的结构比 MBR 规矩得多。LBA0 放的是保护性 MBR里面只有一个类型为 0xEE 的分区表项作用是让不认识 GPT 的老工具以为整块盘被占满了从而不敢乱动LBA1 是 GPT 头记录分区表项数量、大小、CRC 校验和备份头位置从 LBA2 开始是分区表项区每项 128 字节默认 128 项主表加备份一共占 33 个扇区。这个布局意味着你随便拿个老版本分区工具去改很容易把 CRC 算错固件直接判定分区表非法盘就不认了。ESP 是 UEFI 规范强制要求存在的那个分区类型 GUID 固定为C12A7328-F81F-11D2-BA4B-00A0C93EC93B。它必须能被固件识别并读取而固件里内置的文件系统驱动只认 FAT12/16/32所以 ESP 实际就是 FAT32。这也是为什么 Windows 下资源管理器打不开它——被系统刻意隐藏了得用磁盘管理或者 Linux 挂载才能看到内容。分区类型 GUID建议大小用途ESPC12A7328-F81F-11D2-BA4B-00A0C93EC93B20MB 起存放引导程序与驱动FAT32MSRE3C9E316-0B5C-4DB8-817D-F92DF00215AE16MB系统保留无文件系统数据分区EBD0A0A2-B9E5-4433-87C0-68B6B72699C7视需求存放内核与普通文件ESP 的大小不用太大20MB 足够塞下几个引导程序和驱动但对齐要注意按 4096 扇区也就是 2097152 字节对齐能避开大部分 SSD 的擦除块边界问题。制作的时候先清空整个 U 盘的扇区数据再把分区表类型转成 GUID 格式然后新建 ESP 和普通数据分区。转换分区表这个动作会让原有的分区全部失效工具一般会弹确认框这一步没有后悔药。4.2 从 U 盘到真机分区、挂载、拷贝的可抄流程分区做完之后剩下的活最好在 Linux 下干因为那边没有访问限制。插上 U 盘先确认设备节点假设是/dev/sdb。这里有个很典型的迷惑现象用fdisk -l看只会显示一个类型为ee的分区起始 LBA 是 1结束 LBA 是 4294967295。别慌那是保护性 MBR 里的伪分区记录不是你的 ESP——老版本fdisk对 GPT 支持不好读出来的就是这个结果。# 查看磁盘布局显示的 ee 分区是保护性 MBR不是真实分区 fdisk -l /dev/sdb # 直接看设备节点更靠谱sdb1 是 ESPsdb2 是数据分区 ls /dev/sdb* # 挂载 ESP 并建立标准引导目录 mount /dev/sdb1 /mnt/ mkdir -p /mnt/EFI/BOOT # 把编好的 Shell 改名成固件默认会去找的那个名字 cp /root/Desktop/edk2/Build/Shell/DEBUG_GCC48/X64/Shell.efi /mnt/EFI/BOOT/BOOTx64.EFI # 落盘再卸载跳过 sync 有可能拷进去的是半截文件 sync umount /mnt/BOOTx64.EFI这个名字不是随便起的。UEFI 规范规定了可移动介质上的默认引导路径就是\EFI\BOOT\BOOTX64.EFI32 位平台是BOOTIA32.EFI固件在找不到 NVRAM 里记录的启动项时会退回到这个固定路径去碰运气。文件名大小写敏感写成bootx64.efi在某些固件上就找不到。目录层级也一样EFI/BOOT少一层都不行。拷完之后在虚拟机上验证。新建虚拟机时系统类型选 64 位创建完成后进设置把固件类型从 BIOS 改成 UEFI检查有没有 USB 控制器没有就手动加一个兼容性选 3.0 或 2.0 都行把 U 盘挂上去。如果嫌固件启动时网络适配那几秒太磨人把网卡卸掉能明显加快。启动后如果直接掉进固件自带的 Shell说明它没找到可引导项这时手动敲fs0:切到 U 盘ls看一眼EFI\BOOT在不在再直接执行BOOTx64.EFI能跑起来就说明盘做对了。5. 避坑与排查五个卡了我整晚的现场5.1 基础工具编不过包名照抄与分支错位现象yum install build-essential直接报 “No package available”或者make -C BaseTools/中途挂掉报一堆头文件缺失。原因build-essential是 Debian 系的元包RHEL 系没有这个东西得拆成 gcc、gcc-c、make 分别装。BaseTools 编译失败则多半是缺uuid-devel、iasl或者nasm也可能是克隆下来的是主干分支代码里用了新语法而本机的 gcc 版本跟不上。解决先按 5.1 里的包列表补全依赖再确认git branch显示的是UDK2018。如果还报错把make的输出往上翻找到第一个 error 而不是最后那个 “Error 2”后者通常只是连锁反应。5.2 启动项里看不到 U 盘路径、格式、分区表三选一现象U 盘插上固件启动菜单里只有内置硬盘没有 “UEFI: xxx” 这样的条目或者手动进 Shell 后fs0:能切进去但ls是空的。原因按出现频率排第一是分区表没转成 GPT还是 MBR第二是 ESP 存在但格式不是 FAT32有人图省事格成了 exFAT 或者 NTFS第三是文件放错位置固件只认\EFI\BOOT\BOOTX64.EFI第四是大小写Linux 下大小写敏感拷过去是什么样就是什么样。解决用分区工具重新确认分区表类型和 ESP 的标志位lsblk -f看文件系统类型是不是 vfat挂载后find /mnt -type f确认完整路径。还有一个隐蔽情况某些固件在安全启动开启时会拒绝执行未签名镜像表现就是启动项在、点了没反应这种只能进固件设置关掉安全启动。5.3 ExitBootServices 返回 EFI_INVALID_PARAMETER现象引导程序前面几步都正常打印也出来了唯独调用ExitBootServices时返回EFI_INVALID_PARAMETER循环重试还是失败。原因这个函数要一个MapKey参数它是你上一次GetMemoryMap时固件给的快照标识。如果你在取完 map 之后又调用了任何会分配内存的服务哪怕只是AllocatePool拿了几十字节内存布局就变了固件给的 key 立刻失效它会用这个错误码告诉你“你手上的 map 是旧的”。解决把取 map 和退出做成一个循环每轮重新取MapSize、重新分配缓冲区、重新调用GetMemoryMap拿新的 key然后立刻ExitBootServices。两次调用之间不允许有任何其他引导服务调用哪怕是打印一行日志都会让 key 作废。// 取 map 与退出的原子循环中间不能插任何引导服务调用 while (1) { MapSize 0; Status gBS-GetMemoryMap (MapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion); // 缓冲区不够时固件返回 EFI_BUFFER_TOO_SMALL并按需要的尺寸回填 MapSize if (Status EFI_BUFFER_TOO_SMALL) { MemoryMap AllocatePool (MapSize 2 * DescriptorSize); // 留余量 continue; } Status gBS-ExitBootServices (ImageHandle, MapKey); if (!EFI_ERROR (Status)) break; // 成功就跳出失败就重来一轮 }注意AllocatePool的尺寸要多留两个描述符的余量因为取 map 这个动作本身可能让固件再插入一两个描述符尺寸算得刚好就会一直卡在EFI_BUFFER_TOO_SMALL。5.4 跳进 64 位内核第一行就重启现象ExitBootServices成功了跳转指令也执行了但内核入口的第一条指令还没跑完就三重故障重启串口一行输出都没有。原因九成是调用约定或者栈的问题。x64 下进入内核时栈必须是 16 字节对齐的而且如果你是从 C 里通过函数指针跳过去编译器会按EFIAPI的约定去准备参数如果汇编那一侧按 SysV 约定去读寄存器参数全是错的。另外 UEFI 阶段固件可能没给你开 SSE内核里第一条movaps就会因为对齐或者 CR4 里的标志位没置而炸。解决跳转前手动把栈指针清到 16 字节边界在汇编入口处先cli、重置段寄存器、建好临时页表再开 CR0 的 PG 位和 CR4 的 OSFXSR 位。调试阶段可以在跳转前把目标地址和栈指针打到串口上至少能确认是不是跳过去就没了。5.5 图形与内存GOP 拿不到、描述符遍历跑飞现象LocateProtocol找图形输出协议返回EFI_NOT_FOUND或者QueryMode对目标分辨率返回不支持内存描述符遍历到第 N 项时数据全乱。原因GOP 不是全局协议它挂在显卡设备的句柄上正确姿势是先用LocateHandleBuffer按协议 GUID 拿到句柄数组再对每个句柄HandleProtocol取接口分辨率不支持则是这台虚拟机的默认显示设备压根没那个模式得先QueryMode枚举一遍实际支持哪些。内存描述符遍历跑飞基本都是步进算错了——不能按结构体大小sizeof去加得按固件返回的DescriptorSize加这个值在不同固件上可能不一样。解决GOP 走LocateHandleBufferHandleProtocol两段式内存遍历统一用(UINT8*)Map i * DescriptorSize转型后访问别直接对指针做结构体加法。顺便提一句描述符里的PhysicalStart和NumberOfPages要连起来看页数乘 4096 才是这段区域的真实长度漏乘会让你的可用内存表少算一大截。6. 把引导程序当可验证单元三行自检与固件替换迭代法引导程序最难的地方在于它跑在“什么都没有”的环境里出了错没有日志、没有断点、没有 core dump唯一的反馈是重启或者黑屏。我后来养成一个习惯在ExitBootServices之前强制打三行东西出来——内存描述符条目数、GOP 当前分辨率的宽高、以及内核文件被读进来的实际字节数。这三行覆盖了引导程序最容易出错的三条路径只要它们对得上后面跳转失败基本就只剩调用约定和页表的问题排查范围一下子从“整个系统”缩到“几十行汇编”。// 交权前的三行自检把关键状态固化下来 Print (L[CHK] mem descriptors : %d\r\n, (INT32)(MapSize / DescriptorSize)); Print (L[CHK] gop resolution : %dx%d\r\n, Gop-Mode-Info-HorizontalResolution, Gop-Mode-Info-VerticalResolution); Print (L[CHK] kernel loaded : %d bytes 0x%lx\r\n, KernelSize, (UINT64)KernelBase);配合这套自检迭代方式也得改。真机刷 U 盘一轮至少两分钟中间还得反复插拔效率低到让人放弃。我的做法是全程在虚拟机里跑把第 3 章编出来的OVMF.fd直接设成虚拟机的固件文件U 盘用虚拟磁盘文件代替改代码、重编、重启虚拟机一轮二十秒。等三行自检全绿、内核能跑到第一条串口输出再往真机上搬。真机验证只做两件事确认安全启动关掉之后能引导以及确认物理内存布局和虚拟机里的差异没有把内核压垮。有个细节值得单独说内存描述符的条目数在不同固件上差别很大虚拟机里可能只有三四十条真机上轻松上百如果你的内核是按固定数组去接内存信息的在虚拟机里测通不代表真机不溢出。三行自检里的那个条目数就是给你做容量预估用的。从那以后我每次改引导代码都强制先让它在虚拟机里把这三行打完、数字对上才允许自己碰真机。这套流程救过我至少三次——有一次是内核文件读进来少了两百多字节查下去发现是文件系统协议里Read的缓冲区偏移算错了如果直接上真机表现只会是内核跑飞根本想不到是读文件的问题。希望帮到你。本文还有配套的精品资源点击获取
