简介统一可扩展固件接口UEFI正逐步取代传统BIOS成为现代计算机的启动基础。这份PDF版《一个UEFI引导程序的实现》面向操作系统开发者和底层软件爱好者系统讲解从零构建UEFI引导程序的核心流程深入对比BIOS与UEFI的结构组成和启动流程差异分析UEFI取代BIOS的原因随后从搭建TianoCore EDK2开发环境、理解GPT磁盘布局与ESP文件系统入手编写Hello World程序认识UEFI镜像、系统表、调用约定与协议再进一步实现显示模式配置、物理内存获取、存储介质文件读取以及64位平台下的内核引导启动。书中内容与《一个64位操作系统的设计与实现》互补既适合初学者系统入门也适合有经验的工程师结合源码和运行示例深入巩固并为后续研读Linux内核源码打下基础。压缩包内共1个PDF文件大小约2.36MB已有2379人学习下载。1. UEFI引导程序的起点先看懂启动流程再动手写UEFI引导程序难点不在C语言和汇编而在芯片上电后那一整套固件流程。BIOS时代CPU从实模式的物理地址0xFFFF0取到第一条跳转指令接着靠中断向量表访问硬件到了UEFI这里程序运行在保护模式甚至IA-32e长模式下默认加载的不是「引导扇区」而是一个PE/COFF格式的.efi镜像。想要实现《一个UEFI引导程序的实现》里描述的那套引导逻辑绕不开一个前提先把SEC、PEI、DXE、BDS、TSL、RT、AL这七个阶段发生过什么弄清楚。这份资源不是泛泛讲UEFI规范而是直接落到「从EDK2环境搭建、UEFI Shell编译到GPT分区与ESP部署再到GOP显示模式、GetMemoryMap、从ESP读取内核文件、最终跳进64位内核」的完整链路。适合正在写操作系统、卡在引导逻辑上的人也适合想搞明白固件到底怎么把控制权交出去的开发者和爱好者。下面按我实际拆解的顺序把每一步值得注意的参数和坑都过一遍。2. 搭建EDK2并编译部署UEFI Shell依赖、分支、分区与虚拟机一条龙把UEFI Shell跑起来是这条链路里最值得先做的一件事。Shell本身是一个UEFI应用程序编译它等于用最小代价验证了整个EDK2工具链是否可用。这一章把从装依赖到虚拟机启动Shell的完整流程串起来讲。2.1 装依赖与克隆源码CentOS下别照着Debian包名敲资料里给出的安装命令是yum install build-essential git uuid-dev iasl nasm libuuid-devel但这里有个会让新手直接卡住的细节build-essential和uuid-dev是Debian/Ubuntu系的包名CentOS 7的yum源里根本找不到它们直接执行会报No package build-essential available。这是原书笔误还是环境差异不好说实际在CentOS 7下我一般这样装yum install -y gcc make git nasm iasl uuid-devel libuuid-devel git clone https://github.com/tianocore/edk2.git cd edk2 git checkout UDK2018 git submodule update --init --recursive逐个解释这几个包gcc和make是编译BaseTools必需的nasm是汇编器EDK2里部分模块的启动代码是汇编写的iasl是ACPI源语言编译器编译某些固件模块时要用来生成ACPI表uuid-devel和libuuid-devel提供GUID类型和操作函数UEFI里所有协议、分区类型都靠GUID标识这两个包装不上后续会有大量头文件缺失的报错。克隆完成后一定要切换到UDK2018分支。EDK2的master分支演进很快模块路径和编译配置都变过照着资料里的路径去编译master版本会到处碰壁。git submodule update --init --recursive这步很多人会漏——UDK2018有不少子模块比如OpenSSL和FatPkg相关依赖不拉下来build时会在链接阶段报一堆找不到符号的错误。2.2 编译BaseTools并初始化构建环境BaseTools是EDK2自己的编译工具集合包含GenFv、GenFds、GenFw这些后续生成固件镜像和UEFI可执行文件的工具必须先编译出来才能继续。make -C BaseTools/ . ./edksetup.shmake -C BaseTools/会进入BaseTools子目录编译所有宿主工具编译产物放在BaseTools/Source/Scripts和Bin目录下。. ./edksetup.sh等价于source edksetup.sh会设置EDK2构建环境需要的环境变量主要是WORKSPACE指向当前目录并把BaseTools的二进制目录加进PATH。执行完edksetup.sh后可以先手动确认一下环境是否生效echo $WORKSPACE能输出edk2目录路径which build能找到build命令就说明环境初始化成功。如果找不到build命令最可能的原因是当前Shell没重新登录或者上一步BaseTools编译失败了回头检查编译日志里的error行。2.3 配置target.txt并编译Shell.efiEDK2用一个全局配置文件Conf/target.txt描述「要编译哪个模块组、用什么编译器、编什么架构」。这个文件在第一次执行edksetup.sh时自动生成。编译UEFI Shell需要改三个变量sed -i s/^ACTIVE_PLATFORM.*/ACTIVE_PLATFORM ShellPkg\/ShellPkg.dsc/ Conf/target.txt sed -i s/^TOOL_CHAIN_TAG.*/TOOL_CHAIN_TAG GCC48/ Conf/target.txt sed -i s/^TARGET_ARCH.*/TARGET_ARCH X64/ Conf/target.txt build用vi手动改也一样关键是理解这三个变量的含义。ACTIVE_PLATFORM指向模块组描述文件这里用ShellPkg/ShellPkg.dsc它定义了要编译Shell包含哪些库和组件TOOL_CHAIN_TAG GCC48指定编译器标签CentOS 7自带的GCC版本是4.8EDK2里对应代号就是GCC48TARGET_ARCH X64表示生成64位PE/COFF镜像如果机器是32位UEFI固件就改成IA32但当前主流平台基本都是X64。编译完成后Shell.efi的产物路径是Build/Shell/DEBUG_GCC48/X64/Shell.efi。这个路径结构是固定的Build目录下按「模块名/构建类型_编译器/架构」组织。DEBUG表示调试构建包含完整调试信息体积偏大但排错方便想压体积可以改用RELEASE构建类型。2.4 把U盘转成GPT并创建ESP分区编译好的Shell.efi需要在UEFI环境下执行最方便的方式是U盘启动。U盘不能直接拿来用必须是GPT分区布局并且至少有一个ESPEFI System Partition分区。这一步我用DiskGenius操作用DiskGenius清空U盘所有扇区数据然后转换分区表类型为GUID格式软件会弹确认框提示原分区将失效确认即可。点击「新建分区」勾选「建立ESP分区」给ESP分配20MB空间勾选对齐到4096扇区2097152字节。再新建一个10MB的FAT32主分区。GPT磁盘没有扩展分区和逻辑分区概念所以这里只有主分区类型有效。为什么要两个分区ESP分区在Windows资源管理器里是看不到的Windows为了安全隐藏了它单独建一个FAT32普通分区方便在Windows下交换文件。ESP的大小20MB完全够用——它只放引导程序、驱动和启动配置内核文件可以放普通FAT分区引导程序运行时再跨分区读取。4096扇区对齐是为闪存类设备考虑的U盘和SSD的物理块大小通常是4096字节不对齐会让随机读写性能很差极端情况下固件扫描分区也会异常。2.5 挂载ESP并改名拷贝BOOTx64.EFIWindows访问不了ESP但Linux可以直接挂载。把U盘插到CentOS机器上先确认设备节点再操作fdisk -l /dev/sdb ls /dev/sdb* mount /dev/sdb1 /mnt/ mkdir -p /mnt/EFI/BOOT cp /root/Desktop/edk2/Build/Shell/DEBUG_GCC48/X64/Shell.efi /mnt/EFI/BOOT/BOOTx64.EFI sync umount /mnt/这里有两个容易让人误判的点。第一fdisk -l /dev/sdb会显示磁盘标签类型为dos并且只有一个/dev/sdb1、起始LBA到4294967295——这不是磁盘真的没转成GPT而是fdisk把GPT的protective MBR当成了普通分区表用ls /dev/sdb*能看到sdb1、sdb2两个分区才说明Linux内核正确识别了GPT布局sdb1是ESPsdb2是FAT32分区。第二拷贝时必须重命名成BOOTx64.EFI并放在/EFI/BOOT/目录下。这是UEFI规范规定的默认引导路径固件在ESP分区里找不到其他启动项时会去\EFI\BOOT\BOOTx64.EFI找64位引导程序。目录名和文件名严格区分大小写写成/efi/boot/bootx64.efi在大多数固件上是不认的。sync确保数据落盘再拔U盘否则拷贝看似完成实际没写进去。2.6 虚机切换UEFI固件与启动Shell真机测试UEFI引导程序有变砖风险还是先用虚拟机验证。VMware默认用BIOS引导需要手动改固件类型创建虚拟机时系统类型选64位否则后续固件选项里不会出现UEFI。虚拟机设置 → 选项 → 高级 → 固件类型改成UEFI。如果硬件配置里没有USB控制器先添加一个兼容性选USB 2.0或3.0都行。把U盘连接到虚拟机开机。这里有两个小技巧一是如果觉得UEFI固件引导时网络适配器初始化耗时太长直接把网络适配器卸掉启动能快不少二是通电后如果固件没找到操作系统加载器会自动执行默认路径的BOOTx64.EFI也就是我们刚拷进去的Shell。正常的话虚拟机屏幕会出现UEFI Shell的命令行界面输入map -r能看到fs0:这样的设备映射说明整个「编译→分区→部署→启动」链路已经全部打通。3. 解剖一个UEFI程序镜像格式、系统表与调用约定Shell跑起来只是验证了工具链。真正要写属于自己的引导程序得先搞清楚一个UEFI程序内部长什么样、怎么被固件加载、又是怎么和固件通信的。这一章用最小Hello World切入讲透三个核心概念。3.1 Hello World骨架入口、系统表与ConOutUEFI程序的入口函数不是C语言里的main而是UefiMain。EDK2在编译时会通过AutoGen机制生成一个内部入口完成运行时环境初始化后调用我们写的UefiMain。最小骨架长这样#include Uefi.h #include Library/UefiLib.h #include Library/UefiBootServicesTableLib.h EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) { SystemTable-ConOut-OutputString(SystemTable-ConOut, LHello UEFI\r\n); return EFI_SUCCESS; }ImageHandle是当前程序镜像的句柄后续调用很多UEFI服务时都要用到SystemTable是UEFI系统表指针相当于整个UEFI世界的入口——通过它能拿到控制台、引导服务、运行时服务。ConOut是EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL实例OutputString往屏幕上输出UTF-16编码字符串所以字符串字面量必须加L前缀。一个非常容易踩的细节换行要用\r\n不能只写\n。UEFI控制台协议对\n的处理在各固件实现上不一致只发\n在一些平台会出现不换行、只把光标移回行首的诡异现象这就是典型的「玄学」问题实际是文本协议定义不严谨导致的。另外要在EDK2工程里编译这个C文件还需要配套的.inf模块描述文件并在其中声明ENTRY_POINT UefiMain这样AutoGen生成代码时才知道入口放在哪。3.2 PE/COFF镜像格式与安全启动UEFI可执行文件本质上就是PE/COFF格式和Windows的exe/dll同源后缀名变成.efi而已。Shell.efi也好、我们编译的Hello World也好都是这个格式。PE/COFF镜像由DOS头、PE头、节区三大部分组成UEFI固件通过LoadImage服务把镜像加载到内存解析PE头后跳转到入口点执行。这里有个值得记住的事实UEFI程序不是像BIOS时代的MBR那样从固定地址加载的它由固件的镜像加载器按PE规范解析——这意味着UEFI引导程序可以做到与位置无关的加载方式但前提是编译时要正确处理重定位表。EDK2默认生成的PE/COFF镜像包含.reloc重定位节如果哪一天你看到引导程序在真机上随机崩溃先检查是不是编译时把重定位信息裁掉了。安全启动Secure Boot和镜像格式直接相关开启后固件在执行任何UEFI应用程序或驱动前会先校验镜像签名块里的证书只有证书在信任数据库里才放行。签名数据放在PE/COFF镜像的证书表中WIN_CERTIFICATE结构所以LoadImage返回EFI_SECURITY_VIOLATION时第一反应不该是怀疑代码逻辑而是先确认签名状态。3.3 句柄、协议与MS64调用约定UEFI里没有syscall程序访问硬件和固件功能全靠协议。协议的本质是一组函数指针加数据字段的结构体每个协议实例挂在某个句柄上。句柄是一个不透明指针可以粗浅理解为「挂着若干协议实例的设备或对象」。找一个协议实例的经典操作是LocateHandleBufferEFI_STATUS Status; EFI_HANDLE *HandleBuffer NULL; UINTN HandleCount 0; Status gBS-LocateHandleBuffer( ByProtocol, gEfiSimpleFileSystemProtocolGuid, NULL, HandleCount, HandleBuffer ); if (EFI_ERROR(Status)) { return Status; } // 用完后释放句柄缓冲 gBS-FreePool(HandleBuffer);四个参数的含义ByProtocol表示按协议GUID搜索第二个参数是目标协议的GUID指针这里以文件系统协议为例第三个参数是搜索关键字传NULL代表不限定最后两个参数返回匹配的数量和句柄数组。gBS是EDK2封装好的BootServices表全称叫EFI_BOOT_SERVICES所有引导阶段的系统服务都在这里面。调用约定方面UEFI在x64平台上规定使用MS64调用约定——也就是Windows上的Microsoft x64 calling convention前四个整数参数依次放RCX、RDX、R8、R9剩余参数压栈栈保持16字节对齐返回值放RAX。这意味着UEFI程序不能直接用GCC默认的System V调用约定去调用固件提供的函数指针EDK2在头文件里用EFIAPI宏做了声明标注。自己写汇编调用UEFI服务时这是最容易出错的点——漏了EFIAPI修饰符函数指针的调用约定对不上轻则参数错位重则栈不平衡导致系统崩溃。4. 逐步实现引导程序显示、内存、文件与64位跳转当你需要在屏幕上显示引导菜单或者要加载一个64位内核就要处理四类核心任务设置显示模式、获取物理内存布局、从ESP读出内核文件、最后切到内核入口。这四步是引导程序的主干每一步都有对应的UEFI协议和服务。4.1 GOP显示模式查询与切换UEFI下的显示控制几乎绕不开EFI_GRAPHICS_OUTPUT_PROTOCOL简称GOP。无论是想切分辨率还是访问帧缓冲都要先拿到这个协议。EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info; UINTN SizeOfInfo; UINT32 Mode; Status gBS-LocateProtocol(gEfiGraphicsOutputProtocolGuid, NULL, (VOID **)Gop); if (EFI_ERROR(Status)) { return Status; } // 遍历所有支持的模式打印分辨率 for (Mode 0; Mode Gop-Mode-MaxMode; Mode) { Status Gop-QueryMode(Gop, Mode, SizeOfInfo, Info); if (!EFI_ERROR(Status)) { // Info-HorizontalResolution, Info-VerticalResolution } } // 切到指定模式 Status Gop-SetMode(Gop, 1);Gop-Mode-MaxMode表示固件支持的显示模式总数QueryMode返回某个模式的详细信息Info-HorizontalResolution和Info-VerticalResolution分别是宽高。典型做法是先遍历打印所有模式再按目标分辨率匹配模式号最后SetMode切换。这里有一个我必须强调的细节切显示模式之后帧缓冲的地址和大小会变化Gop-Mode-FrameBufferBase和FrameBufferSize要重新读取。很多引导程序在真实机器上切模式后屏幕花屏就是因为还在用切换前的帧缓冲地址写数据。4.2 GetMemoryMap内存描述符怎么读引导内核前必须拿到物理内存布局否则内核不知道哪些内存可用、哪些被固件占用。UEFI提供GetMemoryMap服务但它有个让人第一次用就翻车的设计需要先调用一次探测缓冲区大小再调用一次真正获取数据。UINTN MemoryMapSize 0; EFI_MEMORY_DESCRIPTOR *MemoryMap NULL; UINTN MapKey 0; UINTN DescriptorSize 0; UINTN DescriptorVersion 0; // 第一次调用故意传NULL只为了拿到需要的缓冲区大小 Status gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion); // 此时返回 EFI_BUFFER_TOO_SMALL MemoryMap AllocatePool(MemoryMapSize); Status gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion);关键点是遍历内存描述符时不能直接用sizeof(EFI_MEMORY_DESCRIPTOR)必须用返回的DescriptorSize做步长。原因很简单UEFI规范允许固件在描述符末尾追加额外字段实际描述符大小可能大于结构体本身。用错步长会让内存布局解析得面目全非内核装进错误地址是迟早的事。拿到内存映射后要关注描述符里的类型字段EfiConventionalMemory是常规可用内存EfiLoaderCode和EfiLoaderData是引导程序自身占用的区域EfiRuntimeServicesCode和EfiRuntimeServicesData是运行时服务驻留区这些区域即使退出引导服务后也保留给固件不能交给内核随便用。4.3 从ESP读取内核Simple File System链路从磁盘读文件在UEFI下走的是文件系统协议。链路是LocateProtocol找到EFI_SIMPLE_FILE_SYSTEM_PROTOCOL→OpenVolume打开卷根目录 →Open打开目标文件 →Read读取内容。EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Sfsp; EFI_FILE_PROTOCOL *RootFs; EFI_FILE_PROTOCOL *KernelFile; CHAR16 *Path L\\EFI\\BOOT\\kernel.elf; UINTN FileSize 0x800000; // 预分配8MB缓冲区 VOID *Buffer AllocatePool(FileSize); Status gBS-LocateProtocol(gEfiSimpleFileSystemProtocolGuid, NULL, (VOID **)Sfsp); Status Sfsp-OpenVolume(Sfsp, RootFs); Status RootFs-Open(RootFs, KernelFile, Path, EFI_FILE_MODE_READ, 0); // 确保从文件头开始读 Status KernelFile-SetPosition(KernelFile, 0); Status KernelFile-Read(KernelFile, FileSize, Buffer);路径分隔符用反斜杠\且必须以\开头表示卷根目录所以\EFI\BOOT\kernel.elf里那对双反斜杠是C语言转义后的结果实际字符串是「反斜杠EFI反斜杠BOOT…」。Open的第四个参数是访问模式EFI_FILE_MODE_READ表示只读第五个参数是文件属性打开已存在文件时传0即可。Read的第二个参数既是输入也是输出调用前传入缓冲区容量返回时被改写为实际读取的字节数。这一步的文件名和路径必须和实际部署完全一致而且区分大小写。曾经有个项目把内核文件命名为KERNEL.ELF引导代码里写的是kernel.elfFAT32文件系统在大小写不敏感的Windows下看去没问题到了严格要求大小写匹配的UEFI固件里直接EFI_NOT_FOUND排查了半天。4.4 退出BootServices并跳入64位内核内核文件已经读到内存显示模式已切好内存映射已拿到——最后一步是调用ExitBootServices交出控制权。这一步不可逆调用之后UEFI引导服务全部销毁BootServices全被回收只有RuntimeServices还活着。// MapKey 必须来自最近一次 GetMemoryMap Status gBS-ExitBootServices(ImageHandle, MapKey); if (EFI_ERROR(Status)) { // 失败的唯一原因通常是 MapKey 过期 // 需要重新 GetMemoryMap 再试一次 gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion); Status gBS-ExitBootServices(ImageHandle, MapKey); }ExitBootServices失败最常见的原因就是MapKey过期——在GetMemoryMap之后如果有任何事件触发导致内存映射变化固件会递增MapKey。所以规范建议的做法是失败后重新获取内存映射并重试一次代码里这样写就是标准姿势。跳入64位内核之前我一般会做三件事关闭中断CLI指令建立自己的页表并把CR3指过去设置新的GDT和IDT。注意一个容易误解的点UEFI固件在启动完Shell时CPU已经跑在64位长模式了引导程序不需要自己从实模式切过来——但固件给你的是它的GDT和页表退出BootServices后这些是否继续有效是未知数所以引导程序必须准备好属于自己的那套环境再跳转内核入口。跳转时的参数传递没有统一标准常见做法是把内存映射信息地址放在某个寄存器比如RDI传给内核具体的调用约定在引导程序和内核之间自行约定双方必须保持一致这也是整个引导链路中「设计约定」色彩最重的一环。5. UEFI引导路上的常见坑编译、部署与运行期排查这部分内容来自反复操作和帮别人排障的真实经验。按阶段分成编译期和部署运行期两组每一条都是「现象 → 原因 → 解决」的结构。5.1 编译期两个典型故障故障一yum安装报错提示找不到build-essential包。现象照搬资料命令执行yum install build-essential提示No package build-essential available后面所有包都不装了。原因build-essential是Debian/Ubuntu的元包名CentOS对应的包是gcc和make两者包管理机制完全不同。解决改用yum install -y gcc make git nasm iasl uuid-devel libuuid-devel。这条错在CentOS上几乎必然出现说是坑其实是Linux发行版差异的基本功。故障二build编译中断报找不到OpenSSL头文件或子模块相关错误。现象克隆源码后直接执行build编译到一半报错提示各种头文件缺失错误信息里能看到openssl或edk2/CryptoPkg相关字样。原因UDK2018分支的某些模块依赖git子模块尤其是CryptoPkg里的OpenSSL克隆时不加--recursive参数就不会下载子模块内容。解决git submodule update --init --recursive然后再执行build链接阶段就不会再报符号未定义。这个坑几乎每个初次搭建EDK2的人都会踩一次而且在国内网络环境下子模块下载缓慢建议提前执行并耐心等待完成。5.2 部署与运行期三个故障故障三U盘插进虚拟机Shell里看不到任何文件系统输入fs0:报错。现象Shell已正常启动但map命令列出的设备映射里没有U盘或者只有光驱没有U盘。原因U盘是在固件启动完成之后才被虚拟机识别到的Shell的设备映射表是启动时生成的快照不会自动包含后插入的设备。解决在Shell里先执行map -r强制重扫设备然后再map查看U盘的FAT分区一般会出现为fs0:。如果重扫后依然看不到优先检查USB控制器是否添加成功、固件类型是否真的切到了UEFI。故障四固件直接进固件设置界面或者黑屏就是不进Shell。现象U盘部署完后虚拟机开机直接进入UEFI固件设置或者屏幕黑屏无反应没有任何Shell界面出现。原因固件在BDS阶段按启动顺序扫描启动设备找不到可识别的启动项时退回固件设置界面。最常见的情况是拷贝路径不对——文件没有放在\EFI\BOOT\BOOTx64.EFI或者目录大小写错/efi/boot/而不是/EFI/BOOT/也可能是文件拷到了普通FAT分区而没拷进ESP分区。解决回Linux下重新检查挂载点里的目录结构确认路径完全一致另外确认ESP分区的分区类型GUID是C12A7328-F81F-11D2-BA4B-00A0C93EC93B用gdisk -l /dev/sdb可以查看普通FAT分区即使放对了文件固件也不会去扫描。故障五Shell能进但执行自己编译的Hello World时提示Not Found或安全性错误。现象在Shell里切换到fs0:后执行文件路径时返回EFI_NOT_FOUND或Security Violation。原因一是路径没写对比如漏了\开头二是安全启动处于开启状态未经签名的程序被固件拦截。解决先执行map确认当前文件系统再用ls逐层确认文件确实存在如果是安全启动拦截就在固件设置里关闭Secure Boot或者给镜像做签名。这里要记住Shell本身能启动不代表自己的编译产物也能启动Shell是固件信任路径下的签名程序而你的程序不是。6. 验证引导程序从Shell加载内核的最后一公里把引导程序、内核文件都准备好之后最后一个实用技巧是绕开手动敲命令用UEFI Shell的启动脚本实现自动化加载同时给自己留一条可验证的调试后路。在ESP分区根目录放一个startup.nsh脚本文件Shell启动时会自动执行它。脚本内容可以很简单\EFI\BOOT\kernel.elf这一行的意思是Shell启动后自动执行\EFI\BOOT\kernel.elf这个引导程序。更复杂的场景可以在脚本里先map -r刷新设备再用echo打印调试信息。这样虚拟机一开机从固件到Shell再到引导程序全部自动跑不用每次手动敲路径——手动敲路径看似小事但在频繁编译、频繁重启验证的迭代过程中省下的时间和减少的输入错误非常可观。引导程序内部的验证手法我习惯在三个关键节点加打印输出GOP切完模式后打印一次当前分辨率和帧缓冲地址GetMemoryMap返回后打印描述符总数和可用内存总量内核文件读取完成后打印实际读取字节数。这三个输出分别验证显示、内存、存储三条链路是否工作正常。如果某一步的输出和预期不符比如分辨率没变、描述符数量为0、读取字节数是0问题定位范围瞬间缩小到对应环节而不是在内核panic之后从头查。再补充一个调试层面的习惯阶段性的引导程序不要追求一次写到位我会让每个版本必须能独立验证后再进入下一阶段。比如先只做「GOP切模式 打印」验证稳定后再加「读文件」每加一个功能就重新走一遍启动脚本确认。有一次偷懒把内存映射解析和文件读取一起加进去结果内核没起来分不清是映射问题还是文件读取问题回头拆成两个版本才找到原因——从那以后我每次改引导程序都强制走一遍「切模式打印 → 读文件打印 → 跳转打印」三步确认任何一步的输出不对就回到上一步不再往下加代码。这篇UEFI引导程序的实现链路每一环都不算高深但环环相扣任何一环出问题都会让后面的所有工作看起来像黑匣子。希望这篇拆解能帮你把黑匣子打开从环境搭建到内核跳转每一步都踩在实地上。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 5:02:28 · 阅读 1.2k UEFI引导程序实现全解析：从EDK2环境到64位内核跳转
简介统一可扩展固件接口UEFI正逐步取代传统BIOS成为现代计算机的启动基础。这份PDF版《一个UEFI引导程序的实现》面向操作系统开发者和底层软件爱好者系统讲解从零构建UEFI引导程序的核心流程深入对比BIOS与UEFI的结构组成和启动流程差异分析UEFI取代BIOS的原因随后从搭建TianoCore EDK2开发环境、理解GPT磁盘布局与ESP文件系统入手编写Hello World程序认识UEFI镜像、系统表、调用约定与协议再进一步实现显示模式配置、物理内存获取、存储介质文件读取以及64位平台下的内核引导启动。书中内容与《一个64位操作系统的设计与实现》互补既适合初学者系统入门也适合有经验的工程师结合源码和运行示例深入巩固并为后续研读Linux内核源码打下基础。压缩包内共1个PDF文件大小约2.36MB已有2379人学习下载。1. UEFI引导程序的起点先看懂启动流程再动手写UEFI引导程序难点不在C语言和汇编而在芯片上电后那一整套固件流程。BIOS时代CPU从实模式的物理地址0xFFFF0取到第一条跳转指令接着靠中断向量表访问硬件到了UEFI这里程序运行在保护模式甚至IA-32e长模式下默认加载的不是「引导扇区」而是一个PE/COFF格式的.efi镜像。想要实现《一个UEFI引导程序的实现》里描述的那套引导逻辑绕不开一个前提先把SEC、PEI、DXE、BDS、TSL、RT、AL这七个阶段发生过什么弄清楚。这份资源不是泛泛讲UEFI规范而是直接落到「从EDK2环境搭建、UEFI Shell编译到GPT分区与ESP部署再到GOP显示模式、GetMemoryMap、从ESP读取内核文件、最终跳进64位内核」的完整链路。适合正在写操作系统、卡在引导逻辑上的人也适合想搞明白固件到底怎么把控制权交出去的开发者和爱好者。下面按我实际拆解的顺序把每一步值得注意的参数和坑都过一遍。2. 搭建EDK2并编译部署UEFI Shell依赖、分支、分区与虚拟机一条龙把UEFI Shell跑起来是这条链路里最值得先做的一件事。Shell本身是一个UEFI应用程序编译它等于用最小代价验证了整个EDK2工具链是否可用。这一章把从装依赖到虚拟机启动Shell的完整流程串起来讲。2.1 装依赖与克隆源码CentOS下别照着Debian包名敲资料里给出的安装命令是yum install build-essential git uuid-dev iasl nasm libuuid-devel但这里有个会让新手直接卡住的细节build-essential和uuid-dev是Debian/Ubuntu系的包名CentOS 7的yum源里根本找不到它们直接执行会报No package build-essential available。这是原书笔误还是环境差异不好说实际在CentOS 7下我一般这样装yum install -y gcc make git nasm iasl uuid-devel libuuid-devel git clone https://github.com/tianocore/edk2.git cd edk2 git checkout UDK2018 git submodule update --init --recursive逐个解释这几个包gcc和make是编译BaseTools必需的nasm是汇编器EDK2里部分模块的启动代码是汇编写的iasl是ACPI源语言编译器编译某些固件模块时要用来生成ACPI表uuid-devel和libuuid-devel提供GUID类型和操作函数UEFI里所有协议、分区类型都靠GUID标识这两个包装不上后续会有大量头文件缺失的报错。克隆完成后一定要切换到UDK2018分支。EDK2的master分支演进很快模块路径和编译配置都变过照着资料里的路径去编译master版本会到处碰壁。git submodule update --init --recursive这步很多人会漏——UDK2018有不少子模块比如OpenSSL和FatPkg相关依赖不拉下来build时会在链接阶段报一堆找不到符号的错误。2.2 编译BaseTools并初始化构建环境BaseTools是EDK2自己的编译工具集合包含GenFv、GenFds、GenFw这些后续生成固件镜像和UEFI可执行文件的工具必须先编译出来才能继续。make -C BaseTools/ . ./edksetup.shmake -C BaseTools/会进入BaseTools子目录编译所有宿主工具编译产物放在BaseTools/Source/Scripts和Bin目录下。. ./edksetup.sh等价于source edksetup.sh会设置EDK2构建环境需要的环境变量主要是WORKSPACE指向当前目录并把BaseTools的二进制目录加进PATH。执行完edksetup.sh后可以先手动确认一下环境是否生效echo $WORKSPACE能输出edk2目录路径which build能找到build命令就说明环境初始化成功。如果找不到build命令最可能的原因是当前Shell没重新登录或者上一步BaseTools编译失败了回头检查编译日志里的error行。2.3 配置target.txt并编译Shell.efiEDK2用一个全局配置文件Conf/target.txt描述「要编译哪个模块组、用什么编译器、编什么架构」。这个文件在第一次执行edksetup.sh时自动生成。编译UEFI Shell需要改三个变量sed -i s/^ACTIVE_PLATFORM.*/ACTIVE_PLATFORM ShellPkg\/ShellPkg.dsc/ Conf/target.txt sed -i s/^TOOL_CHAIN_TAG.*/TOOL_CHAIN_TAG GCC48/ Conf/target.txt sed -i s/^TARGET_ARCH.*/TARGET_ARCH X64/ Conf/target.txt build用vi手动改也一样关键是理解这三个变量的含义。ACTIVE_PLATFORM指向模块组描述文件这里用ShellPkg/ShellPkg.dsc它定义了要编译Shell包含哪些库和组件TOOL_CHAIN_TAG GCC48指定编译器标签CentOS 7自带的GCC版本是4.8EDK2里对应代号就是GCC48TARGET_ARCH X64表示生成64位PE/COFF镜像如果机器是32位UEFI固件就改成IA32但当前主流平台基本都是X64。编译完成后Shell.efi的产物路径是Build/Shell/DEBUG_GCC48/X64/Shell.efi。这个路径结构是固定的Build目录下按「模块名/构建类型_编译器/架构」组织。DEBUG表示调试构建包含完整调试信息体积偏大但排错方便想压体积可以改用RELEASE构建类型。2.4 把U盘转成GPT并创建ESP分区编译好的Shell.efi需要在UEFI环境下执行最方便的方式是U盘启动。U盘不能直接拿来用必须是GPT分区布局并且至少有一个ESPEFI System Partition分区。这一步我用DiskGenius操作用DiskGenius清空U盘所有扇区数据然后转换分区表类型为GUID格式软件会弹确认框提示原分区将失效确认即可。点击「新建分区」勾选「建立ESP分区」给ESP分配20MB空间勾选对齐到4096扇区2097152字节。再新建一个10MB的FAT32主分区。GPT磁盘没有扩展分区和逻辑分区概念所以这里只有主分区类型有效。为什么要两个分区ESP分区在Windows资源管理器里是看不到的Windows为了安全隐藏了它单独建一个FAT32普通分区方便在Windows下交换文件。ESP的大小20MB完全够用——它只放引导程序、驱动和启动配置内核文件可以放普通FAT分区引导程序运行时再跨分区读取。4096扇区对齐是为闪存类设备考虑的U盘和SSD的物理块大小通常是4096字节不对齐会让随机读写性能很差极端情况下固件扫描分区也会异常。2.5 挂载ESP并改名拷贝BOOTx64.EFIWindows访问不了ESP但Linux可以直接挂载。把U盘插到CentOS机器上先确认设备节点再操作fdisk -l /dev/sdb ls /dev/sdb* mount /dev/sdb1 /mnt/ mkdir -p /mnt/EFI/BOOT cp /root/Desktop/edk2/Build/Shell/DEBUG_GCC48/X64/Shell.efi /mnt/EFI/BOOT/BOOTx64.EFI sync umount /mnt/这里有两个容易让人误判的点。第一fdisk -l /dev/sdb会显示磁盘标签类型为dos并且只有一个/dev/sdb1、起始LBA到4294967295——这不是磁盘真的没转成GPT而是fdisk把GPT的protective MBR当成了普通分区表用ls /dev/sdb*能看到sdb1、sdb2两个分区才说明Linux内核正确识别了GPT布局sdb1是ESPsdb2是FAT32分区。第二拷贝时必须重命名成BOOTx64.EFI并放在/EFI/BOOT/目录下。这是UEFI规范规定的默认引导路径固件在ESP分区里找不到其他启动项时会去\EFI\BOOT\BOOTx64.EFI找64位引导程序。目录名和文件名严格区分大小写写成/efi/boot/bootx64.efi在大多数固件上是不认的。sync确保数据落盘再拔U盘否则拷贝看似完成实际没写进去。2.6 虚机切换UEFI固件与启动Shell真机测试UEFI引导程序有变砖风险还是先用虚拟机验证。VMware默认用BIOS引导需要手动改固件类型创建虚拟机时系统类型选64位否则后续固件选项里不会出现UEFI。虚拟机设置 → 选项 → 高级 → 固件类型改成UEFI。如果硬件配置里没有USB控制器先添加一个兼容性选USB 2.0或3.0都行。把U盘连接到虚拟机开机。这里有两个小技巧一是如果觉得UEFI固件引导时网络适配器初始化耗时太长直接把网络适配器卸掉启动能快不少二是通电后如果固件没找到操作系统加载器会自动执行默认路径的BOOTx64.EFI也就是我们刚拷进去的Shell。正常的话虚拟机屏幕会出现UEFI Shell的命令行界面输入map -r能看到fs0:这样的设备映射说明整个「编译→分区→部署→启动」链路已经全部打通。3. 解剖一个UEFI程序镜像格式、系统表与调用约定Shell跑起来只是验证了工具链。真正要写属于自己的引导程序得先搞清楚一个UEFI程序内部长什么样、怎么被固件加载、又是怎么和固件通信的。这一章用最小Hello World切入讲透三个核心概念。3.1 Hello World骨架入口、系统表与ConOutUEFI程序的入口函数不是C语言里的main而是UefiMain。EDK2在编译时会通过AutoGen机制生成一个内部入口完成运行时环境初始化后调用我们写的UefiMain。最小骨架长这样#include Uefi.h #include Library/UefiLib.h #include Library/UefiBootServicesTableLib.h EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) { SystemTable-ConOut-OutputString(SystemTable-ConOut, LHello UEFI\r\n); return EFI_SUCCESS; }ImageHandle是当前程序镜像的句柄后续调用很多UEFI服务时都要用到SystemTable是UEFI系统表指针相当于整个UEFI世界的入口——通过它能拿到控制台、引导服务、运行时服务。ConOut是EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL实例OutputString往屏幕上输出UTF-16编码字符串所以字符串字面量必须加L前缀。一个非常容易踩的细节换行要用\r\n不能只写\n。UEFI控制台协议对\n的处理在各固件实现上不一致只发\n在一些平台会出现不换行、只把光标移回行首的诡异现象这就是典型的「玄学」问题实际是文本协议定义不严谨导致的。另外要在EDK2工程里编译这个C文件还需要配套的.inf模块描述文件并在其中声明ENTRY_POINT UefiMain这样AutoGen生成代码时才知道入口放在哪。3.2 PE/COFF镜像格式与安全启动UEFI可执行文件本质上就是PE/COFF格式和Windows的exe/dll同源后缀名变成.efi而已。Shell.efi也好、我们编译的Hello World也好都是这个格式。PE/COFF镜像由DOS头、PE头、节区三大部分组成UEFI固件通过LoadImage服务把镜像加载到内存解析PE头后跳转到入口点执行。这里有个值得记住的事实UEFI程序不是像BIOS时代的MBR那样从固定地址加载的它由固件的镜像加载器按PE规范解析——这意味着UEFI引导程序可以做到与位置无关的加载方式但前提是编译时要正确处理重定位表。EDK2默认生成的PE/COFF镜像包含.reloc重定位节如果哪一天你看到引导程序在真机上随机崩溃先检查是不是编译时把重定位信息裁掉了。安全启动Secure Boot和镜像格式直接相关开启后固件在执行任何UEFI应用程序或驱动前会先校验镜像签名块里的证书只有证书在信任数据库里才放行。签名数据放在PE/COFF镜像的证书表中WIN_CERTIFICATE结构所以LoadImage返回EFI_SECURITY_VIOLATION时第一反应不该是怀疑代码逻辑而是先确认签名状态。3.3 句柄、协议与MS64调用约定UEFI里没有syscall程序访问硬件和固件功能全靠协议。协议的本质是一组函数指针加数据字段的结构体每个协议实例挂在某个句柄上。句柄是一个不透明指针可以粗浅理解为「挂着若干协议实例的设备或对象」。找一个协议实例的经典操作是LocateHandleBufferEFI_STATUS Status; EFI_HANDLE *HandleBuffer NULL; UINTN HandleCount 0; Status gBS-LocateHandleBuffer( ByProtocol, gEfiSimpleFileSystemProtocolGuid, NULL, HandleCount, HandleBuffer ); if (EFI_ERROR(Status)) { return Status; } // 用完后释放句柄缓冲 gBS-FreePool(HandleBuffer);四个参数的含义ByProtocol表示按协议GUID搜索第二个参数是目标协议的GUID指针这里以文件系统协议为例第三个参数是搜索关键字传NULL代表不限定最后两个参数返回匹配的数量和句柄数组。gBS是EDK2封装好的BootServices表全称叫EFI_BOOT_SERVICES所有引导阶段的系统服务都在这里面。调用约定方面UEFI在x64平台上规定使用MS64调用约定——也就是Windows上的Microsoft x64 calling convention前四个整数参数依次放RCX、RDX、R8、R9剩余参数压栈栈保持16字节对齐返回值放RAX。这意味着UEFI程序不能直接用GCC默认的System V调用约定去调用固件提供的函数指针EDK2在头文件里用EFIAPI宏做了声明标注。自己写汇编调用UEFI服务时这是最容易出错的点——漏了EFIAPI修饰符函数指针的调用约定对不上轻则参数错位重则栈不平衡导致系统崩溃。4. 逐步实现引导程序显示、内存、文件与64位跳转当你需要在屏幕上显示引导菜单或者要加载一个64位内核就要处理四类核心任务设置显示模式、获取物理内存布局、从ESP读出内核文件、最后切到内核入口。这四步是引导程序的主干每一步都有对应的UEFI协议和服务。4.1 GOP显示模式查询与切换UEFI下的显示控制几乎绕不开EFI_GRAPHICS_OUTPUT_PROTOCOL简称GOP。无论是想切分辨率还是访问帧缓冲都要先拿到这个协议。EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info; UINTN SizeOfInfo; UINT32 Mode; Status gBS-LocateProtocol(gEfiGraphicsOutputProtocolGuid, NULL, (VOID **)Gop); if (EFI_ERROR(Status)) { return Status; } // 遍历所有支持的模式打印分辨率 for (Mode 0; Mode Gop-Mode-MaxMode; Mode) { Status Gop-QueryMode(Gop, Mode, SizeOfInfo, Info); if (!EFI_ERROR(Status)) { // Info-HorizontalResolution, Info-VerticalResolution } } // 切到指定模式 Status Gop-SetMode(Gop, 1);Gop-Mode-MaxMode表示固件支持的显示模式总数QueryMode返回某个模式的详细信息Info-HorizontalResolution和Info-VerticalResolution分别是宽高。典型做法是先遍历打印所有模式再按目标分辨率匹配模式号最后SetMode切换。这里有一个我必须强调的细节切显示模式之后帧缓冲的地址和大小会变化Gop-Mode-FrameBufferBase和FrameBufferSize要重新读取。很多引导程序在真实机器上切模式后屏幕花屏就是因为还在用切换前的帧缓冲地址写数据。4.2 GetMemoryMap内存描述符怎么读引导内核前必须拿到物理内存布局否则内核不知道哪些内存可用、哪些被固件占用。UEFI提供GetMemoryMap服务但它有个让人第一次用就翻车的设计需要先调用一次探测缓冲区大小再调用一次真正获取数据。UINTN MemoryMapSize 0; EFI_MEMORY_DESCRIPTOR *MemoryMap NULL; UINTN MapKey 0; UINTN DescriptorSize 0; UINTN DescriptorVersion 0; // 第一次调用故意传NULL只为了拿到需要的缓冲区大小 Status gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion); // 此时返回 EFI_BUFFER_TOO_SMALL MemoryMap AllocatePool(MemoryMapSize); Status gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion);关键点是遍历内存描述符时不能直接用sizeof(EFI_MEMORY_DESCRIPTOR)必须用返回的DescriptorSize做步长。原因很简单UEFI规范允许固件在描述符末尾追加额外字段实际描述符大小可能大于结构体本身。用错步长会让内存布局解析得面目全非内核装进错误地址是迟早的事。拿到内存映射后要关注描述符里的类型字段EfiConventionalMemory是常规可用内存EfiLoaderCode和EfiLoaderData是引导程序自身占用的区域EfiRuntimeServicesCode和EfiRuntimeServicesData是运行时服务驻留区这些区域即使退出引导服务后也保留给固件不能交给内核随便用。4.3 从ESP读取内核Simple File System链路从磁盘读文件在UEFI下走的是文件系统协议。链路是LocateProtocol找到EFI_SIMPLE_FILE_SYSTEM_PROTOCOL→OpenVolume打开卷根目录 →Open打开目标文件 →Read读取内容。EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Sfsp; EFI_FILE_PROTOCOL *RootFs; EFI_FILE_PROTOCOL *KernelFile; CHAR16 *Path L\\EFI\\BOOT\\kernel.elf; UINTN FileSize 0x800000; // 预分配8MB缓冲区 VOID *Buffer AllocatePool(FileSize); Status gBS-LocateProtocol(gEfiSimpleFileSystemProtocolGuid, NULL, (VOID **)Sfsp); Status Sfsp-OpenVolume(Sfsp, RootFs); Status RootFs-Open(RootFs, KernelFile, Path, EFI_FILE_MODE_READ, 0); // 确保从文件头开始读 Status KernelFile-SetPosition(KernelFile, 0); Status KernelFile-Read(KernelFile, FileSize, Buffer);路径分隔符用反斜杠\且必须以\开头表示卷根目录所以\EFI\BOOT\kernel.elf里那对双反斜杠是C语言转义后的结果实际字符串是「反斜杠EFI反斜杠BOOT…」。Open的第四个参数是访问模式EFI_FILE_MODE_READ表示只读第五个参数是文件属性打开已存在文件时传0即可。Read的第二个参数既是输入也是输出调用前传入缓冲区容量返回时被改写为实际读取的字节数。这一步的文件名和路径必须和实际部署完全一致而且区分大小写。曾经有个项目把内核文件命名为KERNEL.ELF引导代码里写的是kernel.elfFAT32文件系统在大小写不敏感的Windows下看去没问题到了严格要求大小写匹配的UEFI固件里直接EFI_NOT_FOUND排查了半天。4.4 退出BootServices并跳入64位内核内核文件已经读到内存显示模式已切好内存映射已拿到——最后一步是调用ExitBootServices交出控制权。这一步不可逆调用之后UEFI引导服务全部销毁BootServices全被回收只有RuntimeServices还活着。// MapKey 必须来自最近一次 GetMemoryMap Status gBS-ExitBootServices(ImageHandle, MapKey); if (EFI_ERROR(Status)) { // 失败的唯一原因通常是 MapKey 过期 // 需要重新 GetMemoryMap 再试一次 gBS-GetMemoryMap(MemoryMapSize, MemoryMap, MapKey, DescriptorSize, DescriptorVersion); Status gBS-ExitBootServices(ImageHandle, MapKey); }ExitBootServices失败最常见的原因就是MapKey过期——在GetMemoryMap之后如果有任何事件触发导致内存映射变化固件会递增MapKey。所以规范建议的做法是失败后重新获取内存映射并重试一次代码里这样写就是标准姿势。跳入64位内核之前我一般会做三件事关闭中断CLI指令建立自己的页表并把CR3指过去设置新的GDT和IDT。注意一个容易误解的点UEFI固件在启动完Shell时CPU已经跑在64位长模式了引导程序不需要自己从实模式切过来——但固件给你的是它的GDT和页表退出BootServices后这些是否继续有效是未知数所以引导程序必须准备好属于自己的那套环境再跳转内核入口。跳转时的参数传递没有统一标准常见做法是把内存映射信息地址放在某个寄存器比如RDI传给内核具体的调用约定在引导程序和内核之间自行约定双方必须保持一致这也是整个引导链路中「设计约定」色彩最重的一环。5. UEFI引导路上的常见坑编译、部署与运行期排查这部分内容来自反复操作和帮别人排障的真实经验。按阶段分成编译期和部署运行期两组每一条都是「现象 → 原因 → 解决」的结构。5.1 编译期两个典型故障故障一yum安装报错提示找不到build-essential包。现象照搬资料命令执行yum install build-essential提示No package build-essential available后面所有包都不装了。原因build-essential是Debian/Ubuntu的元包名CentOS对应的包是gcc和make两者包管理机制完全不同。解决改用yum install -y gcc make git nasm iasl uuid-devel libuuid-devel。这条错在CentOS上几乎必然出现说是坑其实是Linux发行版差异的基本功。故障二build编译中断报找不到OpenSSL头文件或子模块相关错误。现象克隆源码后直接执行build编译到一半报错提示各种头文件缺失错误信息里能看到openssl或edk2/CryptoPkg相关字样。原因UDK2018分支的某些模块依赖git子模块尤其是CryptoPkg里的OpenSSL克隆时不加--recursive参数就不会下载子模块内容。解决git submodule update --init --recursive然后再执行build链接阶段就不会再报符号未定义。这个坑几乎每个初次搭建EDK2的人都会踩一次而且在国内网络环境下子模块下载缓慢建议提前执行并耐心等待完成。5.2 部署与运行期三个故障故障三U盘插进虚拟机Shell里看不到任何文件系统输入fs0:报错。现象Shell已正常启动但map命令列出的设备映射里没有U盘或者只有光驱没有U盘。原因U盘是在固件启动完成之后才被虚拟机识别到的Shell的设备映射表是启动时生成的快照不会自动包含后插入的设备。解决在Shell里先执行map -r强制重扫设备然后再map查看U盘的FAT分区一般会出现为fs0:。如果重扫后依然看不到优先检查USB控制器是否添加成功、固件类型是否真的切到了UEFI。故障四固件直接进固件设置界面或者黑屏就是不进Shell。现象U盘部署完后虚拟机开机直接进入UEFI固件设置或者屏幕黑屏无反应没有任何Shell界面出现。原因固件在BDS阶段按启动顺序扫描启动设备找不到可识别的启动项时退回固件设置界面。最常见的情况是拷贝路径不对——文件没有放在\EFI\BOOT\BOOTx64.EFI或者目录大小写错/efi/boot/而不是/EFI/BOOT/也可能是文件拷到了普通FAT分区而没拷进ESP分区。解决回Linux下重新检查挂载点里的目录结构确认路径完全一致另外确认ESP分区的分区类型GUID是C12A7328-F81F-11D2-BA4B-00A0C93EC93B用gdisk -l /dev/sdb可以查看普通FAT分区即使放对了文件固件也不会去扫描。故障五Shell能进但执行自己编译的Hello World时提示Not Found或安全性错误。现象在Shell里切换到fs0:后执行文件路径时返回EFI_NOT_FOUND或Security Violation。原因一是路径没写对比如漏了\开头二是安全启动处于开启状态未经签名的程序被固件拦截。解决先执行map确认当前文件系统再用ls逐层确认文件确实存在如果是安全启动拦截就在固件设置里关闭Secure Boot或者给镜像做签名。这里要记住Shell本身能启动不代表自己的编译产物也能启动Shell是固件信任路径下的签名程序而你的程序不是。6. 验证引导程序从Shell加载内核的最后一公里把引导程序、内核文件都准备好之后最后一个实用技巧是绕开手动敲命令用UEFI Shell的启动脚本实现自动化加载同时给自己留一条可验证的调试后路。在ESP分区根目录放一个startup.nsh脚本文件Shell启动时会自动执行它。脚本内容可以很简单\EFI\BOOT\kernel.elf这一行的意思是Shell启动后自动执行\EFI\BOOT\kernel.elf这个引导程序。更复杂的场景可以在脚本里先map -r刷新设备再用echo打印调试信息。这样虚拟机一开机从固件到Shell再到引导程序全部自动跑不用每次手动敲路径——手动敲路径看似小事但在频繁编译、频繁重启验证的迭代过程中省下的时间和减少的输入错误非常可观。引导程序内部的验证手法我习惯在三个关键节点加打印输出GOP切完模式后打印一次当前分辨率和帧缓冲地址GetMemoryMap返回后打印描述符总数和可用内存总量内核文件读取完成后打印实际读取字节数。这三个输出分别验证显示、内存、存储三条链路是否工作正常。如果某一步的输出和预期不符比如分辨率没变、描述符数量为0、读取字节数是0问题定位范围瞬间缩小到对应环节而不是在内核panic之后从头查。再补充一个调试层面的习惯阶段性的引导程序不要追求一次写到位我会让每个版本必须能独立验证后再进入下一阶段。比如先只做「GOP切模式 打印」验证稳定后再加「读文件」每加一个功能就重新走一遍启动脚本确认。有一次偷懒把内存映射解析和文件读取一起加进去结果内核没起来分不清是映射问题还是文件读取问题回头拆成两个版本才找到原因——从那以后我每次改引导程序都强制走一遍「切模式打印 → 读文件打印 → 跳转打印」三步确认任何一步的输出不对就回到上一步不再往下加代码。这篇UEFI引导程序的实现链路每一环都不算高深但环环相扣任何一环出问题都会让后面的所有工作看起来像黑匣子。希望这篇拆解能帮你把黑匣子打开从环境搭建到内核跳转每一步都踩在实地上。希望帮到你。本文还有配套的精品资源点击获取