1. UEFI Shell到底是什么为什么调试固件绕不开它先讲个亲身经历。前两年帮朋友修一台进不去系统的老机器开机黑屏连BIOS Setup都进不去风扇转、电源灯亮就是没画面。折腾半天最后是靠着UEFI Shell进去用几条命令定位到启动项损坏直接从Shell里把默认启动项拉回来机器才救活。那时候我就觉得UEFI Shell这玩意儿看着不起眼真到关键时刻比什么PE盘、LiveCD都管用。UEFI Shell是运行在UEFI固件环境下的一个命令行解释器你可以把它理解成BIOS年代的DOS——系统没起来之前它先给你一个能操作硬件、读写文件、执行脚本的入口。它不依赖硬盘上的操作系统只要板子上的UEFI固件能跑起来Shell就能用。很多人分不清UEFI Shell和BIOS Setup的关系。简单说BIOS Setup是图形化或半图形化的配置界面能改的东西被厂商锁死了无非是启动顺序、电源管理、虚拟化开关这些。UEFI Shell则是另一层东西它面向的是真正能操作固件和硬件的人——你可以直接访问EFI系统分区里的文件可以加载驱动可以读写内存和IO端口可以用脚本批量执行命令甚至可以操作ACPI表、管理启动项、刷写固件。如果你在做固件开发、主板验证、系统集成或者单纯喜欢折腾底层这玩意儿是绕不开的。这篇文章我不会去贴那份几百页的UEFI Shell规范文档而是按我自己实际使用的路径把脚本语法这块彻底讲透变量、参数、分支循环、文件操作、外部命令加载再到真实场景下的完整脚本拆解。最后一部分我会把这几年前前后后踩过的大坑一并列出来这些才是文档里查不到的东西。如果你是完全没接触过UEFI Shell的新手建议你把前两节看完再上手如果你已经写过几个.nsh脚本可以直接跳到第4和第6节里面有不少细节值得对照。2. 搭建实操环境Shell不是所有机器都自带2.1 主流板卡上怎么进UEFI Shell先解决一个实际问题Shell从哪来大多数商业主板默认不预装UEFI Shell你得自己想办法。常见的入口有几个部分工作站和服务器主板比如某些品牌的商务机型在BIOS Setup里提供一个Launch UEFI Shell的选项打开后重启就能直接进。没有内置Shell的机器可以把Shell.efi放到FAT32格式的U盘或EFI系统分区里然后在启动菜单里选UEFI: U盘名进入。前提是U盘根目录下有EFI/BOOT/BOOTX64.EFI64位x86机器或者你把Shell.efi命名为这个路径下的启动文件。在EDK2开发环境里直接用QEMU加OVMF固件跑一个虚拟机启动时也能进Shell这个方法对学习语法来说反而是最省事的。我自己平时调试用的组合是一台装了Linux的笔记本跑QEMUOVMF固件里直接集成Shell配合虚拟的FAT32磁盘镜像脚本写完不用烧到真实板卡就能验证语法。这个方法强烈推荐——因为真机上反复重启测试时间成本太高了而且有些机器进Shell的快捷键和菜单路径差异很大会打断你调试的思路。2.2 版本差异Shell 2.0与细节变化UEFI Shell有两种主版本Shell 1.0和Shell 2.0。2.0是EDK2默认的版本功能强很多比如支持for循环、支持-b分页参数、支持环境变量的字符串操作等。1.0基本只在内嵌的老固件里能碰到。到了2.0之后不同固件版本的具体实现其实也有差异。有的厂商自己编译的Shell会砍掉一些命令有的则集成了一堆EFI Shell下的DXE驱动。所以在某个机器上能用的脚本换台机器可能就提示命令找不到。这种事儿我遇到过不止一次后面第6节会专门讲怎么排查。现阶段你只需要记住一个原则写脚本时尽量用最基础的内置命令少依赖厂商自定义的扩展命令。2.3 文件系统支持与Shell下的盘符逻辑进到Shell之后第一件事通常是敲map命令看当前有哪些可用映射。UEFI Shell下没有C盘D盘的概念它用FS0:、FS1:这样的格式来表示文件系统BLK0:、BLK1:表示块设备。比如Shell map输出会列出当前能访问的所有设备映射。你输入FS0:回车就能切换到第一个文件系统然后ls看目录结构。这里有个容易懵的地方一个U盘分一个区是FS0:如果某个磁盘上有多个FAT分区可能会映射成FS0:、FS1:而且映射顺序不一定等于你的物理顺序和UEFI固件对设备的枚举顺序有关。还有一点Shell只认FAT12/16/32格式的文件系统NTFS、ext4这些在纯Shell环境下是不认的。你要想从U盘加载脚本U盘必须是FAT32格式别踩这个坑。3. UEFI Shell脚本的母语内置命令与帮助体系3.1 先弄清楚Shell的命令从哪里来在动手写脚本之前得先搞明白Shell命令的分类。UEFI Shell下的命令大致分三类Shell内置命令Shell自己实现的比如cd、ls、cp、mv、rm、set、alias、for、if等。这些不依赖外部文件永远可用。EFI应用程序编译出来的.efi文件放在某一路径下通过Shell去加载执行。最典型的就是Shell.efi本身以及你写的一些.efi小工具。Shell命令脚本.nsh本次重点。本质是一个包含若干Shell命令的文本文件Shell逐行解释执行。你在Shell里敲一条命令Shell会先查内置命令表然后查当前目录下有没有对应的.efi或.nsh文件再根据path环境变量的设置去一系列目录里查找。这个查找顺序很重要后面会讲一个因此引发的诡异Bug。3.2 常用内置命令的功能分组我按使用场景把常用命令分了几组这比死记命令列表高效得多文件操作类ls、cd、cp、mv、rm、mkdir、touch、type查看文本文件内容、edit文本编辑器、hexedit十六进制编辑器。其中edit写短脚本非常实用不用来回在Shell和操作系统之间切换。系统信息类mem内存信息、devices设备列表、drivers驱动列表、bcfg启动项管理、smbiosviewSMBIOS信息、acpiACPI表信息、ver版本信息。内存与端口操作类mm内存读写、io端口读写、dmemdump内存、dmesg类似Linux的dmesg。这些属于固件调试的利器也是Shell最危险的一面——改错一个内存地址系统直接就挂。脚本控制类set、if、for、while、goto、shift、pause、stall延时、exit退出脚本或Shell、reset重启。这些是脚本语法的核心。Shell环境类alias命令别名、path可执行文件搜索路径、map设备映射、echo、cls。其中map命令本身还能用来修改映射关系。3.3 用好-help参数比查文档快十倍UEFI Shell每个命令都支持-?也就是help的缩写参数。比如Shell ls -?就会输出ls的完整用法、参数说明、示例。这个参数信息是命令自己内置的不需要联网查文档。我写脚本的日常流程基本上是拿不准某个参数就先命令 -?看一遍然后开一个Shell窗口在机器上验证另一个窗口用edit写脚本。有一个小细节-?和-h不一定等价。部分命令只支持-?你要敲-h反而会被当成非法参数。这个和Linux下的习惯不一样很多人上来就敲-h然后提示参数错误还以为命令坏了。4. 脚本语法核心变量、参数、流程控制写法到这里开始进入正题。UEFI Shell脚本文件是.nsh后缀的纯文本文件一行一条命令支持#注释。我把语法拆成几个相对独立的部分来讲。4.1 变量与环境变量%符号的用法UEFI Shell里所有变量都是环境变量没有单独的局部变量概念。你用它它就是一个全局的环境变量你删它用set命令。设置和引用的语法set MYVAR hello echo %MYVAR%第一行把环境变量MYVAR设成hello第二行输出hello。注意引用变量时必须用%包裹这和Windows批处理里的%VAR%写法一样。删除变量用set MYVAR后面不跟值就是删除。或者set -d MYVAR。看当前所有环境变量直接敲set不带参数。有一个必须记住的坑**环境变量的值里如果包含特殊字符解析顺序会导致意想不到的结果。**Shell对%的解析是在执行命令之前做替换所以如果你在脚本里想输出一个字面上的%得写两个%转义——echo %%输出一个%。这一点和批处理脚本一模一样。Shell自带一些内置变量经常用到的有%path%可执行文件搜索路径多个目录用分号分隔。%cwd%当前工作目录。%lasterror%上一条命令的返回值/错误码。%startup%是否以startup.nsh方式启动脚本里可以用它判断当前是不是开机自启。我实际写脚本用到%lasterror%的频率非常高。因为脚本本身没有try-catch机制判断命令是否执行成功唯一的办法就是检查错误码。4.2 脚本参数与shift处理执行一个.nsh脚本时可以带参数比如Shell test.nsh arg1 arg2在脚本内部%0拿到的是脚本名自身%1到%9依次是参数1到参数9%*是全部参数从参数1开始。有一个比较坑的地方UEFI Shell虽然支持shift命令但它的shift不太好用——它是把参数整体左移一位%1变成原来的%2以此类推。如果你拿%1做循环取出所有参数写到第三四个参数之后容易乱套。我自己写脚本处理不定长参数时通常直接绕开%1~%9改用%*配合字符串截取操作。字符串操作指令在UEFI Shell里是%VAR:~start,len%这种风格比如set fullarg %* set firsttwo %fullarg:~0,2%这可以截取参数的前两个字符。语法风格接近Windows批处理的%VAR:~m,n%。但因为Shell对%的解析比较严格这种写法在嵌套环境里偶尔会出问题。所以遇到特别复杂的字符串处理我更推荐在脚本里调用echo加重定向生成一个新的临时脚本再执行这个临时脚本——虽然笨但可控。4.3 分支if/then/else/endifUEFI Shell的if语法支持三种基础形式if 条件 then 命令 endifif 条件 then 命令 else 命令 endifif 条件 then 命令 elseif 条件 then 命令 endif条件判定的写法分两种。一种是判断环境变量是否存在或等于某个值if %MYVAR% hello then echo match endif另一种是文件存在性判断if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo found bootloader endif注意两边我习惯都加引号这是从批处理时代养成的习惯——如果%MYVAR%是空值不加引号会导致整个条件表达式语法不完整脚本会报错。加了引号之后空值就变成了一个空字符串参与比较稳妥很多。还有三个逻辑运算符可以用AND、OR、NOT。比如if exist FS0:\flag.txt AND %mode% test then echo enter test mode endif4.4 循环for和whilefor循环的语法是for %i in (val1 val2 val3) echo %i endfor注意循环变量用单个%不是双%for %i in (1 2 3 4) echo %i endfor如果想遍历文件列表可以这么写for %i in FS0:\*.nsh echo %i endforShell会自己展开通配符把匹配到的文件路径依次赋给%i。while循环的语法也类似while 条件 命令 endwhile这里有一个重要限制UEFI Shell的循环没有计数器自动递增的能力如果你要用while计数必须自己修改变量。set counter 0 while %counter% 5 echo count is %counter% set counter %counter%1 endwhile等一下UEFI Shell的set命令不支持算术运算。set counter %counter%1的结果是字符串01不是数字1。这是Shell脚本最让人抓狂的地方——它没有内置的整数运算能力。那怎么实现计数两个办法。一是借助for %i in (1 2 3 4 5)这种显式列表实现固定次数循环二是用外部工具比如edk2自带的parse命令或者其他小工具去处理数值。或者退一步循环次数已知就用for循环条件是基于环境变量且不需要自增的情况才用while。这个思路能让你的脚本少走很多弯路。4.5 传说中的goto和标签UEFI Shell支持goto跳转和标签goto :start ... :start echo start here标签是冒号加名字goto语句跳转到指定标签。注意goto不能跳出当前脚本文件的边界——你没法在一个.nsh里goto到另一个.nsh的标签。这和批处理一样。但goto在Shell里还有一个比较危险的行为如果标签不存在Shell不会报错退出而是直接跳到脚本末尾然后返回一个%lasterror%错误码。如果脚本是开机自启动的startup.nsh这种静默失败很容易被忽略后面真正要用的操作没执行你还不明所以。4.6 把多个命令串起来重定向和管道UEFI Shell支持重定向是覆盖写是追加写。比如把命令输出保存到文件ls FS0:\filelist.txt smbiosview -b FS0:\smbios.txt管道|在UEFI Shell里的支持比我想象中弱一些。实测下来管道在某些版本的Shell里能工作在另一些版本里会直接报语法错误。比如ls | grep .efi这个命令在部分EDK2版本里能用Shell内置了grep的简易实现但换到另一块主板上可能就失败了。我的经验是正式脚本里尽量少用管道需要过滤输出就先把结果重定向到临时文件再用search命令或type加parse去处理。宁可多写两行也不要在管道这个特性上赌固件实现。5. 一个能直接上机跑的诊断备份脚本逐步拆解语法讲再多不如一个完整的例子。下面这个脚本是我在某次批量主板测试中实际用的一个简化版本功能包括检查设备映射、备份当前BIOS区域模拟、收集SMBIOS信息、检查关键启动文件是否存在。5.1 脚本的目标与运行逻辑这个脚本解决一个很实际的问题现场运维人员拿U盘插到机器上跑一下自动把诊断信息和备份文件落盘然后退出。不需要他们懂Shell命令不需要手动敲一堆指令。脚本放在U盘根目录启动进入Shell后执行FS0:\debug.nsh所有输出写到同一个日志目录下。5.2 完整脚本内容# debug.nsh - 简易固件诊断与备份脚本 # 用法: debug.nsh [日志目录] set LOGDIR %1 if %LOGDIR% then set LOGDIR FS0:\LOGS endif if not exist %LOGDIR% then mkdir %LOGDIR% endif set LOGFILE %LOGDIR%\debug_%lasterror%.log # 1. dump设备映射 echo %LOGFILE% echo Device Map %LOGFILE% map %LOGFILE% # 2. dump SMBIOS信息 echo %LOGFILE% echo SMBIOS Info %LOGFILE% smbiosview -b %LOGFILE% # 3. 检查关键EFI启动文件 echo %LOGFILE% echo Check BootLoaders %LOGFILE% set FOUND 0 if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo FS0: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif if exist FS1:\EFI\BOOT\BOOTX64.EFI then echo FS1: BOOTX64.EFI found %LOGFILE% set FOUND 1 endif # 4. dump启动项 echo %LOGFILE% echo Boot Option List %LOGFILE% bcfg boot dump %LOGFILE% # 5. 备份当前启动项配置 echo %LOGFILE% echo Boot Option Backup %LOGFILE% bcfg boot dump -v %LOGFILE% echo %LOGFILE% echo Done. Log saved to %LOGFILE% pause exit5.3 逐段讲解为什么这样写参数与默认值脚本开头先取%1作为日志目录如果没传参就默认用FS0:\LOGS。这里用到了前面讲过的空判断技巧——if %LOGDIR% 空值时%LOGDIR%被替换成空字符串表达式就变成了if 成立进入默认赋值逻辑。日志文件的命名我在这里耍了个小聪明debug_%lasterror%.log。第一次执行时%lasterror%可能为空或0第二次执行时它等于上一次某个命令的返回值。这个命名其实不够严谨最终生成的文件名可能不唯一但胜在简单。严格一点的做法是用%time%或%date%拼一个时间戳但UEFI Shell里的时间格式依赖固件实现输出经常是10:20:30带冒号Windows文件系统不认冒号所以用时间戳反而容易踩坑。smbiosview -b参数smbiosview是EDK2自带的SMBIOS查看命令-b表示分页输出。在重定向到文件时分页参数不仅不会打断输出反而能让内容一次性完整落盘不会因为控制台缓冲区限制丢行。这个细节最开始我不知道导致dump出来的SMBIOS信息只有前几行排查了半天。bcfg boot dumpbcfg是启动项管理命令。bcfg boot dump列出当前所有启动项-v参数会输出更详细的信息比如关联的设备路径。这个命令对排查为什么开不了机类问题非常有用。注意bcfg在某些精简固件里可能没被编译进去如果提示命令不存在回头看我第6节的排查方法。5.4 执行与验证这个脚本写完后实际执行时我用了一个小技巧先在QEMU里跑一遍确认语法没问题再放到真实U盘上跑。QEMU里跑的时候第一次执行会报一堆smbiosview: command not found之类的错误吗其实不会因为OVMF固件里带了SHELL的完整命令集。但真机上确实可能缺命令所以我在脚本里做了一件事所有可能失败的命令后面都靠%lasterror%去判断。更关键的一点写脚本时每条命令的返回值都是独立的。比如mkdir %LOGDIR%在目录已存在时会返回错误码但这不影响脚本继续执行——Shell脚本默认不会因为单条命令失败而中止除非你显式写-exit或使用abort命令。这也是很多新手感到困惑的地方明明上一行报错脚本还是往下跑了。理解这一点就能明白为什么脚本里要手动检查关键步骤的%lasterror%。6. 踩坑实录六年UEFI Shell使用中遇到的典型问题这一部分单独拎出来因为这些坑我几乎都实实在在踩过每一类都花过不少时间排查。写出来帮你省点时间。6.1 文件系统大小写与路径分隔符UEFI Shell的文件系统和UEFI规范一样不区分大小写但输出时可能混合大小写。有次我写了一个判断if exist fs0:\EFI\BOOT\BOOTX64.EFI then注意我写的是小写fs0。Shell能认出这个盘符吗在大多数固件实现里可以但有些严谨的实现可能要求必须用FS0:全部大写。我的建议是脚本里统一用大写盘符、大写路径分隔符避免在固件兼容性上赌运气。路径分隔符一律用反斜杠\不要用正斜杠/。UEFI规范里正斜杠在某些上下文里有特殊含义比如作为参数前缀万一你把路径写错排查起来非常痛苦。6.2 命令找不到环境变量和当前目录的坑path环境变量影响Shell对可执行文件的查找范围。有次我脚本里用了一个自研的诊断.efi工具放在U盘的EFI\Tools目录下。脚本第一行执行set path FS0:\EFI\Tools;%path%结果下一行调用这个工具时Shell提示命令找不到。排查了半天发现是set path这个操作本身的问题——当一个环境变量名是path时Shell在执行set path ...之后当前这条命令的解析还没结束它用的还是旧的path。等到下一条命令时新的path才生效。这看起来很正常但问题在于脚本第一行设置path第二行就要用应该没问题啊后来发现真正的原因是UEFI Shell在解析脚本时某些实现会在每行执行前重新读取path变量而另一些实现只在脚本开始执行时读取一次path快照。第一种实现里你中途改path对后续行生效第二种实现里你必须把path设置放在脚本最开头或者用一个外层的wrapper脚本去设置path再调用真正的脚本。 这个行为差异没有写在规范里纯靠实测发现。现在的处理策略是把path设置独立放在一个env.nsh文件里所有需要环境变量的脚本第一行都改成include env.nsh或直接复制那两行set命令。绕开实现差异。6.3include指令别对它寄予太多希望UEFI Shell有一个include命令可以理解为类似C语言的#include。用法include FS0:\env.nsh但实测下来include在多个版本里行为不太稳定有的要求被include的文件必须带.nsh扩展名否则拒绝执行有的在相对路径下解析失败。而且它不能传参数被include的脚本里%1~%9会被清空还是保留原调用者的参数不同版本表现不一样。我后来基本不用include需要复用代码就直接把内容复制进主脚本或者通过执行子脚本的方式传递参数call FS0:\subtask.nsh %parm%call是执行另一个脚本的正确姿势它会等子脚本执行完再回到当前脚本继续。虽然每启动一次子脚本有开销但在脚本规模不大的前提下可维护性比include强太多。6.4 脚本编码与不可见字符UEFI Shell脚本文本文件的编码要求不算严格但必须注意两点。第一**保存为Unix换行LF还是Windows换行CRLF**实测而言Shell对两种换行都能处理但混合换行会出问题。如果脚本在Windows下编辑完放到Linux环境改了一行再拷回U盘文件中同时出现LF和CRLFShell会在某些版本里把一个\r当成命令的一部分导致命令不存在之类的报错而且报错指向的行和你实际出错的行对不上——因为逐行解析时CR被吞掉与否取决于实现。第二如果脚本里含非ASCII字符比如中文注释必须在文件头部加BOM否则Shell的文本解析可能乱码。这个问题在UEFI Shell 2.0之后有所缓解但保险起见脚本里我一般只用纯英文注释。6.5%lasterror%的时效性%lasterror%变量在每条命令执行后都会更新但它有个特点内置变量对set命令本身也会被更新。也就是说你执行set foo 1之后%lasterror%变成的是这次set是否成功的状态而不是最初那条你想检查的命令的状态。所以正确的检查姿势是这样的bcfg boot dump FS0:\boot.txt set ERRCODE %lasterror% if %ERRCODE% 0 then echo dump ok else echo dump failed with %ERRCODE% endif先把%lasterror%存到一个普通环境变量里再拿去判断。直接写if %lasterror% 0虽然也能用但中间一旦插入别的命令比如echo值可能已经变了。还有一个小细节%lasterror%虽说是错误码但Shell命令成功时的返回值不一定是0。有些命令返回的不是标准0而是自定义状态码。所以判断成功时更可靠的方式是检查输出文件的内容是不是符合预期而不是只看返回码。6.6 内存读写命令的危险性mm命令可以在Shell里直接读写物理内存和IO端口Shell mm 0xE0000000 # 读这个地址的内容 Shell mm 0xE0000000 0x1F # 往这个地址写0x1F这是固件调试的利器但也是最大的危险源。写错一个地址轻则系统死机重则把SPI Flash里的固件搞坏。我见过同事在调试时用mm往某个不知道是什么的地址写了个值重启后板子直接起不来最后靠编程器重新烧固件才救回来。在脚本里涉及mm操作我的建议是先dmem或mem把目标区域读一遍确认地址有效。写操作前人工确认三次地址没错。不要在自动化脚本里放未验证的mm写操作。操作完马上reset重启观察不要继续跑后面的脚本。6.7startup.nsh的自动执行机制如果你把U盘插上Shell启动时会自动尝试执行U盘根目录下的startup.nsh。这是一个很方便的机制但也容易出事故。有一次我调试脚本把startup.nsh放到U盘根目录内容是一个死循环等待某个条件。结果每次开机进Shell就卡死拔U盘都来不及——因为Shell启动时读不到文件系统U盘被占住拔掉就报错。最后只能重启进BIOS把启动顺序改成直接进系统再把U盘格式化才解决。所以我对startup.nsh的态度是开发阶段不要把调试脚本命名为startup.nsh用普通文件名手动执行。需要自动执行时startup.nsh里只放一个调用其他脚本的语句不要写长逻辑。重要操作前先pause给你自己留一个取消执行的机会。6.8 脚本超时与交互Shell脚本执行过程中如果需要人工输入通常用pause命令等按任意键。但pause在无人值守场景下会卡住整个流程。如果需要倒计时自动继续可以写一个循环配合stall命令单位是微秒实现延时set countdown 5 while %countdown% 0 echo Continue in %countdown% ... stall 1000000 set countdown ... endwhile这里有个矛盾set不支持算术运算所以set countdown %countdown%-1是无效的。实际做法是把倒计时变量拆成多个if判断或者干脆用固定次数的for循环。比如for %i in (5 4 3 2 1) echo Continue in %i ... stall 1000000 endfor这个方案最简单既不依赖算术运算也不容易出错。7. 把Shell脚本用在自动化测试里的工程化思路最后一部分聊聊怎么把.nsh脚本写得像工程代码而不是随手写的玩具。这几年我在固件验证项目里逐渐摸索出一套自己的规范分享出来供参考。7.1 约定目录结构一个完整的U盘工具包目录结构建议如下FS0:\ ├── startup.nsh # 入口脚本可选 ├── scripts\ │ ├── common.nsh # 公共函数用call调用 │ ├── debug.nsh │ ├── backup.nsh │ └── flash.nsh ├── tools\ │ ├── shell.efi # 备用Shell │ ├── xxxdiag.efi # 自定义诊断工具 │ └── ... └── logs\ # 日志输出目录脚本里统一用scripts\和tools\的绝对路径不要在几十行里到处写FS0:\这种硬编码。如果U盘盘符变了比如插到不同USB口变成FS1:至少还有救——你只需要改顶部的几个set变量。7.2 输出规范与日志级别UEFI Shell的echo命令没有彩色输出也没法区分日志级别。我的做法是在脚本里统一一个日志函数的概念用子脚本实现:log_info echo [INFO] %1 %LOGFILE% goto :EOF但前面说过goto :EOF在UEFI Shell里的支持不完全可靠所以这种函数写法我很少用。更实际的做法是每条输出都同时打到屏幕和日志文件屏幕输出帮助操作者实时了解进展日志文件用于事后审计。具体写法是这样echo Step 1: dump smbios... | tee %LOGFILE%等等tee命令在UEFI Shell里通常没有。所以实际做法是写两行echo Step 1: dump smbios... %LOGFILE% echo Step 1: dump smbios...麻烦是麻烦一点但可靠。我已经不指望Shell脚本能写出多优雅的日志框架了能稳定执行比什么都强。7.3 与UEFI固件内部的交互变量命名空间环境变量名不要起得太通用。比如你脚本里用了一个set boot后面某段代码也用了set boot互相覆盖了排查起来非常费劲。我建议所有脚本变量统一加前缀比如项目名缩写set DBG_LOGDIR FS0:\LOGS set DBG_MODE 1这样不同脚本之间的变量冲突概率大大降低。另外注意UEFI Shell的环境变量会随脚本退出而保留除非你显式删除或整个Shell重启。也就是说一个脚本设置的变量另一个脚本能看到。这既是便利也是隐患——一个写坏了的变量可能在半小时后的另一个脚本里莫名出现。7.4 错误码传递与失败处理脚本失败时的退出码是%lasterror%。在自动化测试框架里我们经常在Shell脚本的最外层套一个Linux或Windows侧的驱动脚本用串口或网络和Shell交互。Shell侧接收参数、执行测试、返回错误码宿主侧解析。这种模式下exit %lasterror%就非常关键确保Shell退出时把最后的错误码带出去。但有两点要特别小心不是所有版本的Shell都支持exit %lasterror%的语法。部分实现只支持exit不带参数返回码永远是0。如果你在.nsh里执行了另一个.efi程序该程序的退出码会通过%lasterror%暴露出来但前提是Shell没在这之间执行其他命令。任何一条命令都可能覆盖它。为了确保错误码正确传递在测试框架里我会专门写一个report.nshset TEST_RESULT %lasterror% if %TEST_RESULT% 0 then echo PASS FS0:\logs\result.txt else echo FAIL:%TEST_RESULT% FS0:\logs\result.txt endif exit %TEST_RESULT%宿主侧的脚本只认result.txt里的内容不依赖Shell退出码——因为实测下来有的固件版本退出码头几位的字节会被截断导致宿主侧收到奇怪的值。7.5 与DXE驱动和EFI应用的配合UEFI Shell最有意思的地方是可以加载DXE驱动和运行各种EFI应用。比如在测试过程中你可能需要先加载一个自定义的协议驱动再跑测试工具。典型写法load FS0:\tools\MyDriver.efi if %lasterror% 0 then echo driver loaded else echo driver load failed endifload命令加载驱动后驱动常驻内存。此时可以用drivers命令查看驱动列表用devices查看设备节点。如果有新设备出现说明驱动生效了。加载驱动时特别需要注意驱动一旦加载成功直到系统重启前都不会被卸载。你连续加载同一驱动两次第二次会返回错误但这个错误并不影响第一次加载的效果。所以脚本里不要因为某次加载报错就判定驱动有问题要结合drivers输出确认是否已在列表里。7.6 QEMU联调不烧板子练脚本最后安利一下QEMU调试法。EDK2项目官方就提供OVMF固件配合QEMU可以完整模拟UEFI环境。具体步骤下载编译好的OVMF.fd固件或者自己从EDK2源码编译。准备一个FAT32格式的磁盘镜像把写好的.nsh文件放进去。启动命令大致是qemu-system-x86_64 -drive ifpflash,formatraw,fileOVMF.fd -drive formatraw,filefat:rw:./diskQEMU启动时会自动进入OVMF的菜单选择UEFI Shell即可。这个方法有两个好处一是完全不用碰真实硬件脚本写错了重启一下虚拟机就行二是QEMU支持GDB调试你可以结合EDK2源码单步跟踪Shell命令的执行流程理解每一条命令背后的逻辑。不过对大多数应用场景来说能快速验证语法就够了也不必深入到那个程度。8. 最后分享几个关于Shell脚本的心得回想这几年跟UEFI Shell打交道的经历最深的感触是这工具看着像Linux终端用起来像DOS批处理但它的很多细节都夹在固件实现和硬件平台的缝隙里。同一个脚本在这块板子上跑得好好的换一块板子可能就行为迥异。所以我的建议一直没变——脚本要向最基础的命令看齐不要赌固件实现的一致性和文档没有覆盖的边界行为。具体到日常使用有几件事是我每次上手都会做的拿到一台新机器先敲ver看Shell版本再敲map看设备最后ls -?、bcfg -?看命令支持情况。花五分钟快速评估这台机器的Shell能力边界比后面盲写脚本踩坑强得多。写任何涉及硬件操作的脚本前先在虚拟机里跑通逻辑再在真机上人工跑一遍验证命令可用性和输出格式最后才正式使用。遇到诡异问题先用type或hexedit看脚本文本有没有不可见字符然后再怀疑语法。这个排查路径能解决相当一部分奇怪的问题。如果你平时做BIOS开发或固件测试UEFI Shell脚本看着不起眼但熟练之后真的能帮你把很多重复的调试工作变成一条命令的事。把这篇文章里的语法和踩坑点消化掉你大概率就能写出属于自己的第一版可复用脚本了。