你有没有遇到过这种情况开机卡在固件 Logo 前系统进不去进设置界面翻来覆去也只有几个基础选项想修引导、跑诊断工具却感觉无从下手。如果你搞过固件开发、做过嵌入式软件或者维护过一批工控设备一定知道 UEFI Shell 这个藏在固件里的命令行环境。它本质上就是一个运行在固件层的小型 Shell提供文件浏览、设备映射、环境变量管理等能力更重要的是它能加载并运行扩展名为 .efi 的标准应用程序也就是 UEFI 规范里定义的 EFI Application。我在实际项目里就用它做过固件升级、硬件自检和启动项修复今天把“UEFI Shell 下加载标准应用程序”这件事完整拆开讲透适合固件开发、嵌入式软件和做系统维护的同学参考。1. UEFI Shell 到底是一个什么样的环境1.1 它和操作系统的命令行有什么本质区别很多人第一次进 UEFI Shell 会觉得它长得像 DOS也像 Linux 的 busybox但它的底层逻辑和操作系统 Shell 完全不同。操作系统里的 Shell 跑在内核之上靠的是设备驱动、进程调度、文件系统挂载这些机制而 UEFI Shell 跑在固件环境中是在 CPU 刚初始化完、内存可用、基本 I/O 可用的阶段直接运行。它没有“内核态”和“用户态”的概念没有虚拟内存也没有多进程调度一切操作都是单线程的、实模式的准确说是保护模式或长模式下的平坦寻址所有地址都是物理地址。这个差异带来的实际影响非常直观你在 UEFI Shell 里写个小工具能直接读写物理内存映射、访问固件协议、操作 I/O 端口不需要通过什么“驱动层”转换。换一句话说Shell 就是固件留给你的一扇后门让你绕过操作系统直接和设备固件对话。但 Shell 本身也不是固件里必须存在的组件。传统 BIOS 没有 Shell 的概念UEFI 规范也没有强制要求每个平台都内置 Shell。很多商用机器出厂时固件里确实带了一个也有不少平台只留了引导功能需要你手动把 Shell.efi 放到启动介质里加载。这也是为什么“Shell 下加载标准应用程序”这个技能很实用不管固件里有没有 Shell你都能自己搭一个出来然后用它加载任何合规的 EFI 应用。很多人会误以为“UEFI Shell 是操作系统里的一个工具”这是另一个常见误区。它不依赖 Windows 或 Linux不依赖硬盘上的任何系统文件只要固件能初始化 USB 控制器、能从 FAT 分区读取文件Shell 就能跑起来。正因如此当操作系统崩溃、引导丢失、甚至硬盘分区表损坏时Shell 往往是唯一还能正常工作的“救援环境”。1.2 “标准应用程序”在 UEFI 体系里到底是什么定义所谓“标准应用程序”英文是 Standard Application对应的规范术语是 EFI Application。它是一类遵循 UEFI 规范的可执行映像扩展名约定为 .efi文件格式是 PE/COFF在 UEFI 2.x 规范中明确要求的格式。和普通操作系统里的 exe、ELF 不同EFI 应用的加载和执行不依赖任何操作系统内核而是由固件中的 Boot Services 直接完成。EFI 应用有两种最常见的形态。一种是纯粹的应用程序比如硬件诊断工具、固件升级工具、启动修复工具跑完返回退出码控制权交还给加载它的环境可能是 Shell也可能是 Boot Manager。另一种是 OS Loader比如 grubx64.efi、Windows 的 bootmgfw.efi它们本质上也是 EFI 应用只不过在运行的最后阶段会调用 ExitBootServices 把硬件控制权从固件手里接管过来再启动操作系统内核。从这个角度理解“加载标准应用程序”就不仅仅是“在 Shell 里跑个程序”这么简单。Shell 其实只是加载器的一种学会在 Shell 下加载应用你同时也就理解了固件如何通过 Boot Manager 启动操作系统。两者底层走的是同一套机制只是入口和参数不同。2. Shell 加载 EFI 应用底层到底干了什么2.1 从文件到内存LoadImage 在做什么Shell 在加载一个 .efi 文件时并不是简单地把文件字节流扔到内存里跳过去执行。它遵守一套严格步骤核心是调用 EFI_BOOT_SERVICES 中的 LoadImage。这个函数的职责是把可执行映像从某个来源加载进内存并且完成格式校验和重定位准备。具体来说Shell 解析完命令行路径后会通过文件系统协议找到目标文件打开并读取它的头部确认它是一个合法的 PE/COFF 映像校验机器类型、子系统的有效性。子系统必须是 EFI_APPLICATION常量值 10或者 EFI_BS_DRIVER、EFI_RUNTIME_DRIVER 之类可加载的映像类型。如果是 X64 平台的 Shell遇到一个 IA32 架构的 .efiLoadImage 会在这一步直接报不支持根本不会进入执行阶段。校验通过后LoadImage 会根据 PE 头里的段信息分配内存页把代码段、数据段、只读数据段分别拷贝到对应位置处理基址重定位表。对于地址相关的指令它还要在加载阶段把绝对地址修正成实际的物理地址。这一步完成之后LoadImage 返回一个 EFI_HANDLE也就是这个映像的句柄它将在后续的 StartImage 中被使用。这里有个关键细节LoadImage 本身的参数包括 BootPolicy。Shell 调用它时BootPolicy 必须设为 FALSE因为 Shell 走的是普通的文件系统路径解析不是固件定义的启动策略路径。只有 Boot Manager 在加载引导项时BootPolicy 才会是 TRUE允许固件尝试各种复杂启动路径。这个区别平时感觉不到但排查某些加载失败问题时非常有用。2.2 从内存到运行StartImage 之后的旅程LoadImage 做完静态工作后Shell 接着调用 StartImage把控制权真正交给应用程序。StartImage 做的事可以理解成“跳到入口点并传参”。EFI 应用的入口点是 UefiMain 函数它接收两个参数一个是 ImageHandle也就是 LoadImage 返回的那个句柄另一个是 EFI_SYSTEM_TABLE也就是指向系统表的指针。系统表是个百宝箱里面包含了 Console 输出、启动服务表、运行时服务表、固件厂商信息和配置表等一堆关键指针。UEFI 应用拿到 SystemTable就能调用 gBS-OutputString 往屏幕打字符调用 gRT-GetTime 读时间或者通过 LocateProtocol 去拿各种协议接口。Shell 本身也是这么工作的它并不是应用的主人所应用不依赖 Shell只依赖固件提供的服务。这也是“标准应用”能跨平台运行的根基。应用运行结束有两种方式。最常见的是从 UefiMain 返回一个 EFI_STATUSStartImage 会把这个返回值传给调用者Shell 收到后决定下一步是继续等待命令还是报错。另一种方式是应用在内部主动调用 gBS-Exit这相当于提前结束自己效果和正常返回一样。需要特别注意应用运行期间如果它调用了 ExitBootServices那整个固件环境就失效了Shell 也没法再继续运行。这就是 OS Loader 和普通诊断工具的本质分界线。2.3 为什么要在 Shell 里加载而不是开机自动运行既然固件的 Boot Manager 也能加载 EFI 应用那 Shell 加载的意义在哪里说白了就两个字灵活。Boot Manager 的加载流程是固定的它读取 NVRAM 里的 BootOrder按顺序遍历启动项对每个启动项的 FilePath 调用 LoadImage 和 StartImage。这个过程在启动时自动发生不需要人干预但也意味着如果你想临时跑一个不在启动项里的工具Boot Manager 帮不上忙。Shell 则不同你可以随时插入 U 盘进 Shell手动敲入工具路径立刻执行执行完还能回到 Shell 继续操作。这种交互性在调试、量产、返修场景中极其重要。实际项目中我还经常用 Shell 配合 bcfg 命令把某个 EFI 应用注册成启动项。执行bcfg boot add 0 fs0:\Tools\InfoDemo.efi Info Demo之后固件重启就会在 Boot Manager 里直接加载这个应用不需要先进 Shell。但要注意这个命令只是在 NVRAM 里写了启动项真正加载时走的还是 LoadImage/StartImage 那套流程。所以你把 Shell 下的加载机制吃透了Boot Manager 那个“自动加载”也就没什么神秘的了。3. 动手编译一个可加载的 EFI 应用3.1 工具链选型edk2 还是 gnu-efi要把一个 C 程序变成能被 Shell 加载的 .efi你得先选工具链。目前主流方案有两个基于 TianoCore 的 EDK2 和轻量级的 gnu-efi。EDK2 是固件开发领域的标准工程套件体积大、依赖重但它提供了完整的库封装、构建系统和协议定义。你在 EDK2 里写应用可以使用 Print、内存分配、设备路径解析等常用函数不用担心底层细节。缺点是环境配置和工程结构对新手来说有一定门槛第一次搭环境可能要花不少时间。gnu-efi 则更小巧它只是把 UEFI 规范里的类型定义和常用库函数做了一套 GNU 工具链下的封装。写起来很直接适合快速验证概念。缺点是库不完整高级一点的操作经常要自己直接调用 Boot Services出错概率大。对比项EDK2gnu-efi工程规模大适合正式项目小适合快速实验库函数支持完整封装度高精简需手动处理细节构建复杂度需要配置构建环境Makefile 一行搞定产物质量规范适合产品化可运行但扩展较麻烦如果是正式做项目或者要长期维护工具集我还是建议直接上 EDK2虽然前期投入大但后面写复杂应用时省心得多。3.2 一个能读取 Shell 参数的示例程序程序的功能设计成打印系统信息和 Shell 传入的命令行参数。这样既能演示“应用被 Shell 加载”这个事件也能展示应用如何反向获取 Shell 的环境信息。用 EDK2 写一个最小的 UEFI Application需要准备两个核心文件一个 .c 源文件和一个 .inf 构建描述文件。先看源文件我命名为 InfoDemo.c#include Uefi.h #include Library/UefiLib.h #include Library/UefiBootServicesTableLib.h #include Protocol/ShellParameters.h EFI_STATUS EFIAPI UefiMain ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable ) { EFI_SHELL_PARAMETERS_PROTOCOL *ShellParams; EFI_STATUS Status; UINTN Index; Print(LInfoDemo loaded by UEFI Shell.\r\n); Print(LFirmware Vendor: %s, Revision: 0x%x\r\n, SystemTable-FirmwareVendor, SystemTable-FirmwareRevision); Status gBS-OpenProtocol ( ImageHandle, gEfiShellParametersProtocolGuid, (VOID **)ShellParams, ImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL ); if (EFI_ERROR (Status)) { Print(LWarning: no shell parameters protocol found.\r\n); return EFI_SUCCESS; } Print(LShell passed %d argument(s):\r\n, ShellParams-Argc); for (Index 0; Index ShellParams-Argc; Index) { Print(L Argv[%d] %s\r\n, Index, ShellParams-Argv[Index]); } Print(LDone.\r\n); return EFI_SUCCESS; }这个程序先通过 SystemTable 打印固件信息然后尝试打开 EFI_SHELL_PARAMETERS_PROTOCOL 获取 Shell 传给应用的参数。需要注意这个协议只有在应用被 Shell 加载时才存在。如果你把同一个 .efi 加进了 Boot Manager 启动项OpenProtocol 会返回错误所以程序里做了兼容处理。对应的 InfoDemo.inf 文件也不复杂[Defines] INF_VERSION 0x00010005 BASE_NAME InfoDemo FILE_GUID F3E8F7D0-0B67-4B6E-9F6E-6C3A6B7A4E2B MODULE_TYPE UEFI_APPLICATION VERSION_STRING 1.0 ENTRY_POINT UefiMain [Sources] InfoDemo.c [Packages] MdePkg/MdePkg.dec ShellPkg/ShellPkg.dec [LibraryClasses] UefiLib UefiBootServicesTableLib.inf 文件是 EDK2 的模块描述文件MODULE_TYPE 必须是 UEFI_APPLICATIONENTRY_POINT 指向 UefiMain。Packages 里要声明用到了 MdePkg 和 ShellPkg这样编译系统才能找到对应头文件和 GUID 定义。LibraryClasses 里的 UefiLib 提供 Print 函数UefiBootServicesTableLib 提供全局的 gBS 指针。3.3 编译得到 .efi 文件编译的前提是机器上装好了 EDK2 环境和对应的交叉工具链。以 Linux 下的 GCC5 工具链为例先进入 edk2 源码目录初始化编译环境然后执行构建命令。cd edk2 source edksetup.sh build -a X64 -t GCC5 -b RELEASE \ -p YourPlatformPkg/YourPlatformPkg.dsc \ -m YourModulePath/InfoDemo.inf如果你的模块已经写进了平台 DSC 文件的 [Components] 区域也可以只指定 -p 的 DSC 文件不指定 -m让 build 把 [Components] 下所有模块一起编出来。产物一般在 Build 目录下路径类似Build/YourPlatform/RELEASE_GCC5/X64/InfoDemo.efi。这里有个容易困惑的细节GCC 工具链编译出来的中间文件其实是 ELF 格式EDK2 的构建系统会在最后一步调用 GenFw 工具把 ELF 转换成 PE/COFF 格式的 .efi。所以不要用file InfoDemo.efi查出来是 PE32 就觉得奇怪这是正常流程。如果你用 gnu-efiMakefile 里也会做同样的格式转换只不过它把细节藏得更深。4. Shell 下加载运行的完整实操4.1 准备 FAT32 介质与 Shell 环境拿到 .efi 文件后下一步是把它放到一个 Shell 能读到的文件系统里。Shell 对不同文件系统的支持取决于固件里有没有对应的文件系统驱动但 FAT32 是默认标配所以 U 盘格式化成 FAT32 是最省事的选择。需要准备两份文件Shell.efi 和 InfoDemo.efi。Shell.efi 的来源有两种一是你的固件设置菜单里直接有“UEFI Shell”或类似入口这就什么都不用做二是在没有内置 Shell 的平台上去 EDK2 源码里手动编译一份命令是build -a X64 -t GCC5 -b RELEASE -p ShellPkg/ShellPkg.dsc产物是Build/Shell/RELEASE_GCC5/X64/Shell.efi。把 U 盘分一个 FAT32 分区根目录放 Shell.efi再建一个 Tools 目录放 InfoDemo.efi。我个人习惯把所有自研工具都放 Tools 目录里避免根目录堆满文件也方便在 startup.nsh 里统一引用。插入 U 盘后开机进固件设置找到启动选择界面选“UEFI Shell”或“从 USB 启动的 Shell 入口”。如果固件不认还有一个笨办法把 Shell.efi 重命名成\EFI\BOOT\BOOTX64.EFI放在 U 盘对应目录很多固件在找不到启动项时会尝试这个默认路径也能把 Shell 拉起来。4.2 进入 Shell 并运行 InfoDemo.efiShell 启动后看到的是Shell提示符。第一步先用 map 命令看看当前固件映射了哪些设备。Shell map输出里会列出 FS0、FS1 这类文件系统映射以及 BLK0、BLK1 这种原始块设备。U 盘通常会被映射成 FS0 或者编号靠后的文件系统。如果你的 U 盘插上后没有被识别可以先执行map -r强制重新扫描一次很多时候能解决。确认 U 盘映射后切换文件系统查看文件Shell fs0: FS0:\ ls FS0:\ ls Tools看到 InfoDemo.efi 之后直接输入文件名就能加载运行。Shell 的规则是不带扩展名写也行但我习惯写全名。FS0:\ Tools\InfoDemo.efi -a 3 -check程序立刻被加载执行屏幕会先打印固件厂商和版本信息然后列出 Shell 传给它的两个参数-a和-check。整个过程看起来就像在 Linux 里运行一个二进制程序但背后的 LoadImage/StartImage 流程已经走了一遍。运行结束后控制权自动回到 Shell提示符重新出现。4.3 结合 startup.nsh 实现自动加载如果不想每次手动敲命令可以用 startup.nsh 脚本实现自动化。Shell 启动时会自动读取根目录下的 startup.nsh 并逐行执行这个机制非常适合做现场运维。在 U 盘根目录新建 startup.nsh内容写成这样echo -off fs0: Tools\InfoDemo.efi -auto保存后重新启动Shell 会自动切换文件系统并加载 InfoDemo.efi整个过程不需要人工干预。在实际量产测试里我经常把硬件自检工具、内存测试工具、网络配置工具都写进不同的 .nsh 脚本测试人员只需要选择对应脚本执行就能完成一轮完整的板级验证。如果你希望应用在开机时直接被固件加载不经 Shell也可以在 Shell 里用 bcfg 把它注册成启动项。命令示例如下bcfg boot add 0 fs0:\Tools\InfoDemo.efi Info Demo重启后 Boot Manager 会直接加载这个应用跳过 Shell。不过要提醒一句bcfg 修改的是 NVRAM 里的启动项操作不当会影响正常启动顺序改之前最好备份原有内容。5. 踩坑记录加载过程中的典型问题5.1 文件系统与路径问题最常见的坑是 Shell 找不到 U 盘分区。现象是进 Shell 后执行 map只有 BLK 设备列表没有 FS 映射。这种情况八成的根源是 U 盘用了 NTFS 或 exFAT 格式Shell 默认只认 FAT/FAT32除非你在 Shell 里额外加载过第三方文件系统驱动。处理办法很简单重新格式化成 FAT32容量大于 32GB 的分区在 Windows 下格式化时没有 FAT32 选项可以用第三方分区工具或者命令行工具处理。路径问题也值得说。Shell 对路径大小写不敏感但它不接受反斜杠和正斜杠混用也不接受文件路径里有空格时不加引号。如果执行后提示 Command Not Found先用 ls 确认文件确实在那个目录下再检查命令里有没有多打或者少打分隔符。安全排第一。FAT32 是兼容性最好的选择虽然它单文件不能超过 4GB但对放 EFI 工具来说完全够用。5.2 映像格式与架构问题“Invalid Image”是所有 EFI 应用开发者都会撞上的错误。它通常意味着 LoadImage 在解析 PE/COFF 文件时发现了不合法的地方。最常见的是架构不匹配X64 的 Shell 不能加载 IA32 的 .efiARM 平台的 Shell 也不能加载 X64 的 .efi。编译前务必确认build -a参数和你的目标平台一致。还有一种情况是入口点设置错误。如果你在 .inf 里写的 ENTRY_POINT 名字和 .c 里的函数名不一致编译产物会缺失入口表LoadImage 时就会报 Invalid Image。另外模块类型也很关键确认 MODULE_TYPE 是 UEFI_APPLICATION而不是 UEFI_DRIVER。驱动类型的映像在加载时走的是 DriverBinding 流程不会作为普通应用被 StartImage 直接跳转到入口点。5.3 运行时崩溃与调试技巧如果应用加载成功但运行过程中黑屏、死机或者直接重启问题往往出在应用自身对固件资源的使用上。最常见的错误是空指针解引用比如直接使用某个协议却没有先检查 OpenProtocol 的返回值。UEFI 环境没有操作系统的内存保护访问非法地址不会触发段错误而是会直接触发 CPU 异常最终表现为机器重启。我的调试习惯是三步走。第一步打开编译时的 DEBUG 选项用 DEBUG 宏打印关键路径日志配合串口重定向观察输出。很多 EDK2 平台默认开启串口输出执行build -b DEBUG可以得到带完整日志的版本。第二步在 UefiMain 入口处先打印一行固定字符串确认入口正常再逐步注释代码用二分法定位到出问题的调用。第三步检查所有返回值尤其是 OpenProtocol、AllocatePool 这类容易失败的调用。5.4 快速排查参考表整理了一个速查表方便直接对照现象可能原因处理方式找不到 FS 映射U 盘不是 FAT32 / 未重新扫描格式化为 FAT32执行 map -rCommand Not Found路径写错 / 文件名错误用 ls 确认路径后重试Invalid Image架构不匹配 / PE 格式错误确认 target arch 和模块类型加载后直接重启空指针 / 协议未打开就使用检查所有返回码补全判空参数获取不到应用被 Boot Manager 加载而非 Shell改用 LoadOptions 获取参数调试 EFI 应用的路子一旦走通了后面很多东西都会变得顺理成章。Shell 不过是个入口你掌握的是固件对“标准应用程序”的完整装载机制。我个人在项目里最珍惜的经验反而是“少折腾”的智慧工具尽量保持无状态、输出尽量走串口、脚本尽量全部放在一个分区目录里。遇到现场问题时插上 U 盘启动 Shell跑一遍自检日志出来问题基本就能锁定到模块级别。这套流程在研发实验室、产线测试和售后返修中都反复验证过稳得很。至于再往后还能做什么——通过 Shell 加载自研驱动做内存压力测试、用诊断工具批量刷写固件、把网络工具集成进 .efi 做远程运维每一层都有得挖。先把加载这条路走扎实后面的故事自然慢慢展开。 
长河君 · 2026/10/14 4:59:03 · 阅读 1.2k UEFI Shell 加载 EFI 应用：从固件环境到标准程序的完整解析
你有没有遇到过这种情况开机卡在固件 Logo 前系统进不去进设置界面翻来覆去也只有几个基础选项想修引导、跑诊断工具却感觉无从下手。如果你搞过固件开发、做过嵌入式软件或者维护过一批工控设备一定知道 UEFI Shell 这个藏在固件里的命令行环境。它本质上就是一个运行在固件层的小型 Shell提供文件浏览、设备映射、环境变量管理等能力更重要的是它能加载并运行扩展名为 .efi 的标准应用程序也就是 UEFI 规范里定义的 EFI Application。我在实际项目里就用它做过固件升级、硬件自检和启动项修复今天把“UEFI Shell 下加载标准应用程序”这件事完整拆开讲透适合固件开发、嵌入式软件和做系统维护的同学参考。1. UEFI Shell 到底是一个什么样的环境1.1 它和操作系统的命令行有什么本质区别很多人第一次进 UEFI Shell 会觉得它长得像 DOS也像 Linux 的 busybox但它的底层逻辑和操作系统 Shell 完全不同。操作系统里的 Shell 跑在内核之上靠的是设备驱动、进程调度、文件系统挂载这些机制而 UEFI Shell 跑在固件环境中是在 CPU 刚初始化完、内存可用、基本 I/O 可用的阶段直接运行。它没有“内核态”和“用户态”的概念没有虚拟内存也没有多进程调度一切操作都是单线程的、实模式的准确说是保护模式或长模式下的平坦寻址所有地址都是物理地址。这个差异带来的实际影响非常直观你在 UEFI Shell 里写个小工具能直接读写物理内存映射、访问固件协议、操作 I/O 端口不需要通过什么“驱动层”转换。换一句话说Shell 就是固件留给你的一扇后门让你绕过操作系统直接和设备固件对话。但 Shell 本身也不是固件里必须存在的组件。传统 BIOS 没有 Shell 的概念UEFI 规范也没有强制要求每个平台都内置 Shell。很多商用机器出厂时固件里确实带了一个也有不少平台只留了引导功能需要你手动把 Shell.efi 放到启动介质里加载。这也是为什么“Shell 下加载标准应用程序”这个技能很实用不管固件里有没有 Shell你都能自己搭一个出来然后用它加载任何合规的 EFI 应用。很多人会误以为“UEFI Shell 是操作系统里的一个工具”这是另一个常见误区。它不依赖 Windows 或 Linux不依赖硬盘上的任何系统文件只要固件能初始化 USB 控制器、能从 FAT 分区读取文件Shell 就能跑起来。正因如此当操作系统崩溃、引导丢失、甚至硬盘分区表损坏时Shell 往往是唯一还能正常工作的“救援环境”。1.2 “标准应用程序”在 UEFI 体系里到底是什么定义所谓“标准应用程序”英文是 Standard Application对应的规范术语是 EFI Application。它是一类遵循 UEFI 规范的可执行映像扩展名约定为 .efi文件格式是 PE/COFF在 UEFI 2.x 规范中明确要求的格式。和普通操作系统里的 exe、ELF 不同EFI 应用的加载和执行不依赖任何操作系统内核而是由固件中的 Boot Services 直接完成。EFI 应用有两种最常见的形态。一种是纯粹的应用程序比如硬件诊断工具、固件升级工具、启动修复工具跑完返回退出码控制权交还给加载它的环境可能是 Shell也可能是 Boot Manager。另一种是 OS Loader比如 grubx64.efi、Windows 的 bootmgfw.efi它们本质上也是 EFI 应用只不过在运行的最后阶段会调用 ExitBootServices 把硬件控制权从固件手里接管过来再启动操作系统内核。从这个角度理解“加载标准应用程序”就不仅仅是“在 Shell 里跑个程序”这么简单。Shell 其实只是加载器的一种学会在 Shell 下加载应用你同时也就理解了固件如何通过 Boot Manager 启动操作系统。两者底层走的是同一套机制只是入口和参数不同。2. Shell 加载 EFI 应用底层到底干了什么2.1 从文件到内存LoadImage 在做什么Shell 在加载一个 .efi 文件时并不是简单地把文件字节流扔到内存里跳过去执行。它遵守一套严格步骤核心是调用 EFI_BOOT_SERVICES 中的 LoadImage。这个函数的职责是把可执行映像从某个来源加载进内存并且完成格式校验和重定位准备。具体来说Shell 解析完命令行路径后会通过文件系统协议找到目标文件打开并读取它的头部确认它是一个合法的 PE/COFF 映像校验机器类型、子系统的有效性。子系统必须是 EFI_APPLICATION常量值 10或者 EFI_BS_DRIVER、EFI_RUNTIME_DRIVER 之类可加载的映像类型。如果是 X64 平台的 Shell遇到一个 IA32 架构的 .efiLoadImage 会在这一步直接报不支持根本不会进入执行阶段。校验通过后LoadImage 会根据 PE 头里的段信息分配内存页把代码段、数据段、只读数据段分别拷贝到对应位置处理基址重定位表。对于地址相关的指令它还要在加载阶段把绝对地址修正成实际的物理地址。这一步完成之后LoadImage 返回一个 EFI_HANDLE也就是这个映像的句柄它将在后续的 StartImage 中被使用。这里有个关键细节LoadImage 本身的参数包括 BootPolicy。Shell 调用它时BootPolicy 必须设为 FALSE因为 Shell 走的是普通的文件系统路径解析不是固件定义的启动策略路径。只有 Boot Manager 在加载引导项时BootPolicy 才会是 TRUE允许固件尝试各种复杂启动路径。这个区别平时感觉不到但排查某些加载失败问题时非常有用。2.2 从内存到运行StartImage 之后的旅程LoadImage 做完静态工作后Shell 接着调用 StartImage把控制权真正交给应用程序。StartImage 做的事可以理解成“跳到入口点并传参”。EFI 应用的入口点是 UefiMain 函数它接收两个参数一个是 ImageHandle也就是 LoadImage 返回的那个句柄另一个是 EFI_SYSTEM_TABLE也就是指向系统表的指针。系统表是个百宝箱里面包含了 Console 输出、启动服务表、运行时服务表、固件厂商信息和配置表等一堆关键指针。UEFI 应用拿到 SystemTable就能调用 gBS-OutputString 往屏幕打字符调用 gRT-GetTime 读时间或者通过 LocateProtocol 去拿各种协议接口。Shell 本身也是这么工作的它并不是应用的主人所应用不依赖 Shell只依赖固件提供的服务。这也是“标准应用”能跨平台运行的根基。应用运行结束有两种方式。最常见的是从 UefiMain 返回一个 EFI_STATUSStartImage 会把这个返回值传给调用者Shell 收到后决定下一步是继续等待命令还是报错。另一种方式是应用在内部主动调用 gBS-Exit这相当于提前结束自己效果和正常返回一样。需要特别注意应用运行期间如果它调用了 ExitBootServices那整个固件环境就失效了Shell 也没法再继续运行。这就是 OS Loader 和普通诊断工具的本质分界线。2.3 为什么要在 Shell 里加载而不是开机自动运行既然固件的 Boot Manager 也能加载 EFI 应用那 Shell 加载的意义在哪里说白了就两个字灵活。Boot Manager 的加载流程是固定的它读取 NVRAM 里的 BootOrder按顺序遍历启动项对每个启动项的 FilePath 调用 LoadImage 和 StartImage。这个过程在启动时自动发生不需要人干预但也意味着如果你想临时跑一个不在启动项里的工具Boot Manager 帮不上忙。Shell 则不同你可以随时插入 U 盘进 Shell手动敲入工具路径立刻执行执行完还能回到 Shell 继续操作。这种交互性在调试、量产、返修场景中极其重要。实际项目中我还经常用 Shell 配合 bcfg 命令把某个 EFI 应用注册成启动项。执行bcfg boot add 0 fs0:\Tools\InfoDemo.efi Info Demo之后固件重启就会在 Boot Manager 里直接加载这个应用不需要先进 Shell。但要注意这个命令只是在 NVRAM 里写了启动项真正加载时走的还是 LoadImage/StartImage 那套流程。所以你把 Shell 下的加载机制吃透了Boot Manager 那个“自动加载”也就没什么神秘的了。3. 动手编译一个可加载的 EFI 应用3.1 工具链选型edk2 还是 gnu-efi要把一个 C 程序变成能被 Shell 加载的 .efi你得先选工具链。目前主流方案有两个基于 TianoCore 的 EDK2 和轻量级的 gnu-efi。EDK2 是固件开发领域的标准工程套件体积大、依赖重但它提供了完整的库封装、构建系统和协议定义。你在 EDK2 里写应用可以使用 Print、内存分配、设备路径解析等常用函数不用担心底层细节。缺点是环境配置和工程结构对新手来说有一定门槛第一次搭环境可能要花不少时间。gnu-efi 则更小巧它只是把 UEFI 规范里的类型定义和常用库函数做了一套 GNU 工具链下的封装。写起来很直接适合快速验证概念。缺点是库不完整高级一点的操作经常要自己直接调用 Boot Services出错概率大。对比项EDK2gnu-efi工程规模大适合正式项目小适合快速实验库函数支持完整封装度高精简需手动处理细节构建复杂度需要配置构建环境Makefile 一行搞定产物质量规范适合产品化可运行但扩展较麻烦如果是正式做项目或者要长期维护工具集我还是建议直接上 EDK2虽然前期投入大但后面写复杂应用时省心得多。3.2 一个能读取 Shell 参数的示例程序程序的功能设计成打印系统信息和 Shell 传入的命令行参数。这样既能演示“应用被 Shell 加载”这个事件也能展示应用如何反向获取 Shell 的环境信息。用 EDK2 写一个最小的 UEFI Application需要准备两个核心文件一个 .c 源文件和一个 .inf 构建描述文件。先看源文件我命名为 InfoDemo.c#include Uefi.h #include Library/UefiLib.h #include Library/UefiBootServicesTableLib.h #include Protocol/ShellParameters.h EFI_STATUS EFIAPI UefiMain ( IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable ) { EFI_SHELL_PARAMETERS_PROTOCOL *ShellParams; EFI_STATUS Status; UINTN Index; Print(LInfoDemo loaded by UEFI Shell.\r\n); Print(LFirmware Vendor: %s, Revision: 0x%x\r\n, SystemTable-FirmwareVendor, SystemTable-FirmwareRevision); Status gBS-OpenProtocol ( ImageHandle, gEfiShellParametersProtocolGuid, (VOID **)ShellParams, ImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL ); if (EFI_ERROR (Status)) { Print(LWarning: no shell parameters protocol found.\r\n); return EFI_SUCCESS; } Print(LShell passed %d argument(s):\r\n, ShellParams-Argc); for (Index 0; Index ShellParams-Argc; Index) { Print(L Argv[%d] %s\r\n, Index, ShellParams-Argv[Index]); } Print(LDone.\r\n); return EFI_SUCCESS; }这个程序先通过 SystemTable 打印固件信息然后尝试打开 EFI_SHELL_PARAMETERS_PROTOCOL 获取 Shell 传给应用的参数。需要注意这个协议只有在应用被 Shell 加载时才存在。如果你把同一个 .efi 加进了 Boot Manager 启动项OpenProtocol 会返回错误所以程序里做了兼容处理。对应的 InfoDemo.inf 文件也不复杂[Defines] INF_VERSION 0x00010005 BASE_NAME InfoDemo FILE_GUID F3E8F7D0-0B67-4B6E-9F6E-6C3A6B7A4E2B MODULE_TYPE UEFI_APPLICATION VERSION_STRING 1.0 ENTRY_POINT UefiMain [Sources] InfoDemo.c [Packages] MdePkg/MdePkg.dec ShellPkg/ShellPkg.dec [LibraryClasses] UefiLib UefiBootServicesTableLib.inf 文件是 EDK2 的模块描述文件MODULE_TYPE 必须是 UEFI_APPLICATIONENTRY_POINT 指向 UefiMain。Packages 里要声明用到了 MdePkg 和 ShellPkg这样编译系统才能找到对应头文件和 GUID 定义。LibraryClasses 里的 UefiLib 提供 Print 函数UefiBootServicesTableLib 提供全局的 gBS 指针。3.3 编译得到 .efi 文件编译的前提是机器上装好了 EDK2 环境和对应的交叉工具链。以 Linux 下的 GCC5 工具链为例先进入 edk2 源码目录初始化编译环境然后执行构建命令。cd edk2 source edksetup.sh build -a X64 -t GCC5 -b RELEASE \ -p YourPlatformPkg/YourPlatformPkg.dsc \ -m YourModulePath/InfoDemo.inf如果你的模块已经写进了平台 DSC 文件的 [Components] 区域也可以只指定 -p 的 DSC 文件不指定 -m让 build 把 [Components] 下所有模块一起编出来。产物一般在 Build 目录下路径类似Build/YourPlatform/RELEASE_GCC5/X64/InfoDemo.efi。这里有个容易困惑的细节GCC 工具链编译出来的中间文件其实是 ELF 格式EDK2 的构建系统会在最后一步调用 GenFw 工具把 ELF 转换成 PE/COFF 格式的 .efi。所以不要用file InfoDemo.efi查出来是 PE32 就觉得奇怪这是正常流程。如果你用 gnu-efiMakefile 里也会做同样的格式转换只不过它把细节藏得更深。4. Shell 下加载运行的完整实操4.1 准备 FAT32 介质与 Shell 环境拿到 .efi 文件后下一步是把它放到一个 Shell 能读到的文件系统里。Shell 对不同文件系统的支持取决于固件里有没有对应的文件系统驱动但 FAT32 是默认标配所以 U 盘格式化成 FAT32 是最省事的选择。需要准备两份文件Shell.efi 和 InfoDemo.efi。Shell.efi 的来源有两种一是你的固件设置菜单里直接有“UEFI Shell”或类似入口这就什么都不用做二是在没有内置 Shell 的平台上去 EDK2 源码里手动编译一份命令是build -a X64 -t GCC5 -b RELEASE -p ShellPkg/ShellPkg.dsc产物是Build/Shell/RELEASE_GCC5/X64/Shell.efi。把 U 盘分一个 FAT32 分区根目录放 Shell.efi再建一个 Tools 目录放 InfoDemo.efi。我个人习惯把所有自研工具都放 Tools 目录里避免根目录堆满文件也方便在 startup.nsh 里统一引用。插入 U 盘后开机进固件设置找到启动选择界面选“UEFI Shell”或“从 USB 启动的 Shell 入口”。如果固件不认还有一个笨办法把 Shell.efi 重命名成\EFI\BOOT\BOOTX64.EFI放在 U 盘对应目录很多固件在找不到启动项时会尝试这个默认路径也能把 Shell 拉起来。4.2 进入 Shell 并运行 InfoDemo.efiShell 启动后看到的是Shell提示符。第一步先用 map 命令看看当前固件映射了哪些设备。Shell map输出里会列出 FS0、FS1 这类文件系统映射以及 BLK0、BLK1 这种原始块设备。U 盘通常会被映射成 FS0 或者编号靠后的文件系统。如果你的 U 盘插上后没有被识别可以先执行map -r强制重新扫描一次很多时候能解决。确认 U 盘映射后切换文件系统查看文件Shell fs0: FS0:\ ls FS0:\ ls Tools看到 InfoDemo.efi 之后直接输入文件名就能加载运行。Shell 的规则是不带扩展名写也行但我习惯写全名。FS0:\ Tools\InfoDemo.efi -a 3 -check程序立刻被加载执行屏幕会先打印固件厂商和版本信息然后列出 Shell 传给它的两个参数-a和-check。整个过程看起来就像在 Linux 里运行一个二进制程序但背后的 LoadImage/StartImage 流程已经走了一遍。运行结束后控制权自动回到 Shell提示符重新出现。4.3 结合 startup.nsh 实现自动加载如果不想每次手动敲命令可以用 startup.nsh 脚本实现自动化。Shell 启动时会自动读取根目录下的 startup.nsh 并逐行执行这个机制非常适合做现场运维。在 U 盘根目录新建 startup.nsh内容写成这样echo -off fs0: Tools\InfoDemo.efi -auto保存后重新启动Shell 会自动切换文件系统并加载 InfoDemo.efi整个过程不需要人工干预。在实际量产测试里我经常把硬件自检工具、内存测试工具、网络配置工具都写进不同的 .nsh 脚本测试人员只需要选择对应脚本执行就能完成一轮完整的板级验证。如果你希望应用在开机时直接被固件加载不经 Shell也可以在 Shell 里用 bcfg 把它注册成启动项。命令示例如下bcfg boot add 0 fs0:\Tools\InfoDemo.efi Info Demo重启后 Boot Manager 会直接加载这个应用跳过 Shell。不过要提醒一句bcfg 修改的是 NVRAM 里的启动项操作不当会影响正常启动顺序改之前最好备份原有内容。5. 踩坑记录加载过程中的典型问题5.1 文件系统与路径问题最常见的坑是 Shell 找不到 U 盘分区。现象是进 Shell 后执行 map只有 BLK 设备列表没有 FS 映射。这种情况八成的根源是 U 盘用了 NTFS 或 exFAT 格式Shell 默认只认 FAT/FAT32除非你在 Shell 里额外加载过第三方文件系统驱动。处理办法很简单重新格式化成 FAT32容量大于 32GB 的分区在 Windows 下格式化时没有 FAT32 选项可以用第三方分区工具或者命令行工具处理。路径问题也值得说。Shell 对路径大小写不敏感但它不接受反斜杠和正斜杠混用也不接受文件路径里有空格时不加引号。如果执行后提示 Command Not Found先用 ls 确认文件确实在那个目录下再检查命令里有没有多打或者少打分隔符。安全排第一。FAT32 是兼容性最好的选择虽然它单文件不能超过 4GB但对放 EFI 工具来说完全够用。5.2 映像格式与架构问题“Invalid Image”是所有 EFI 应用开发者都会撞上的错误。它通常意味着 LoadImage 在解析 PE/COFF 文件时发现了不合法的地方。最常见的是架构不匹配X64 的 Shell 不能加载 IA32 的 .efiARM 平台的 Shell 也不能加载 X64 的 .efi。编译前务必确认build -a参数和你的目标平台一致。还有一种情况是入口点设置错误。如果你在 .inf 里写的 ENTRY_POINT 名字和 .c 里的函数名不一致编译产物会缺失入口表LoadImage 时就会报 Invalid Image。另外模块类型也很关键确认 MODULE_TYPE 是 UEFI_APPLICATION而不是 UEFI_DRIVER。驱动类型的映像在加载时走的是 DriverBinding 流程不会作为普通应用被 StartImage 直接跳转到入口点。5.3 运行时崩溃与调试技巧如果应用加载成功但运行过程中黑屏、死机或者直接重启问题往往出在应用自身对固件资源的使用上。最常见的错误是空指针解引用比如直接使用某个协议却没有先检查 OpenProtocol 的返回值。UEFI 环境没有操作系统的内存保护访问非法地址不会触发段错误而是会直接触发 CPU 异常最终表现为机器重启。我的调试习惯是三步走。第一步打开编译时的 DEBUG 选项用 DEBUG 宏打印关键路径日志配合串口重定向观察输出。很多 EDK2 平台默认开启串口输出执行build -b DEBUG可以得到带完整日志的版本。第二步在 UefiMain 入口处先打印一行固定字符串确认入口正常再逐步注释代码用二分法定位到出问题的调用。第三步检查所有返回值尤其是 OpenProtocol、AllocatePool 这类容易失败的调用。5.4 快速排查参考表整理了一个速查表方便直接对照现象可能原因处理方式找不到 FS 映射U 盘不是 FAT32 / 未重新扫描格式化为 FAT32执行 map -rCommand Not Found路径写错 / 文件名错误用 ls 确认路径后重试Invalid Image架构不匹配 / PE 格式错误确认 target arch 和模块类型加载后直接重启空指针 / 协议未打开就使用检查所有返回码补全判空参数获取不到应用被 Boot Manager 加载而非 Shell改用 LoadOptions 获取参数调试 EFI 应用的路子一旦走通了后面很多东西都会变得顺理成章。Shell 不过是个入口你掌握的是固件对“标准应用程序”的完整装载机制。我个人在项目里最珍惜的经验反而是“少折腾”的智慧工具尽量保持无状态、输出尽量走串口、脚本尽量全部放在一个分区目录里。遇到现场问题时插上 U 盘启动 Shell跑一遍自检日志出来问题基本就能锁定到模块级别。这套流程在研发实验室、产线测试和售后返修中都反复验证过稳得很。至于再往后还能做什么——通过 Shell 加载自研驱动做内存压力测试、用诊断工具批量刷写固件、把网络工具集成进 .efi 做远程运维每一层都有得挖。先把加载这条路走扎实后面的故事自然慢慢展开。