1. UEFI Shell到底是什么為什么調(diào)試固件繞不開它先講個(gè)親身經(jīng)歷。前兩年幫朋友修一臺(tái)進(jìn)不去系統(tǒng)的老機(jī)器開機(jī)黑屏連BIOS Setup都進(jìn)不去風(fēng)扇轉(zhuǎn)、電源燈亮就是沒(méi)畫面。折騰半天最后是靠著UEFI Shell進(jìn)去用幾條命令定位到啟動(dòng)項(xiàng)損壞直接從Shell里把默認(rèn)啟動(dòng)項(xiàng)拉回來(lái)機(jī)器才救活。那時(shí)候我就覺(jué)得UEFI Shell這玩意兒看著不起眼真到關(guān)鍵時(shí)刻比什么PE盤、LiveCD都管用。UEFI Shell是運(yùn)行在UEFI固件環(huán)境下的一個(gè)命令行解釋器你可以把它理解成BIOS年代的DOS——系統(tǒng)沒(méi)起來(lái)之前它先給你一個(gè)能操作硬件、讀寫文件、執(zhí)行腳本的入口。它不依賴硬盤上的操作系統(tǒng)只要板子上的UEFI固件能跑起來(lái)Shell就能用。很多人分不清UEFI Shell和BIOS Setup的關(guān)系。簡(jiǎn)單說(shuō)BIOS Setup是圖形化或半圖形化的配置界面能改的東西被廠商鎖死了無(wú)非是啟動(dòng)順序、電源管理、虛擬化開關(guān)這些。UEFI Shell則是另一層?xùn)|西它面向的是真正能操作固件和硬件的人——你可以直接訪問(wèn)EFI系統(tǒng)分區(qū)里的文件可以加載驅(qū)動(dòng)可以讀寫內(nèi)存和IO端口可以用腳本批量執(zhí)行命令甚至可以操作ACPI表、管理啟動(dòng)項(xiàng)、刷寫固件。如果你在做固件開發(fā)、主板驗(yàn)證、系統(tǒng)集成或者單純喜歡折騰底層這玩意兒是繞不開的。這篇文章我不會(huì)去貼那份幾百頁(yè)的UEFI Shell規(guī)范文檔而是按我自己實(shí)際使用的路徑把腳本語(yǔ)法這塊徹底講透變量、參數(shù)、分支循環(huán)、文件操作、外部命令加載再到真實(shí)場(chǎng)景下的完整腳本拆解。最后一部分我會(huì)把這幾年前前后后踩過(guò)的大坑一并列出來(lái)這些才是文檔里查不到的東西。如果你是完全沒(méi)接觸過(guò)UEFI Shell的新手建議你把前兩節(jié)看完再上手如果你已經(jīng)寫過(guò)幾個(gè).nsh腳本可以直接跳到第4和第6節(jié)里面有不少細(xì)節(jié)值得對(duì)照。2. 搭建實(shí)操環(huán)境Shell不是所有機(jī)器都自帶2.1 主流板卡上怎么進(jìn)UEFI Shell先解決一個(gè)實(shí)際問(wèn)題Shell從哪來(lái)大多數(shù)商業(yè)主板默認(rèn)不預(yù)裝UEFI Shell你得自己想辦法。常見的入口有幾個(gè)部分工作站和服務(wù)器主板比如某些品牌的商務(wù)機(jī)型在BIOS Setup里提供一個(gè)Launch UEFI Shell的選項(xiàng)打開后重啟就能直接進(jìn)。沒(méi)有內(nèi)置Shell的機(jī)器可以把Shell.efi放到FAT32格式的U盤或EFI系統(tǒng)分區(qū)里然后在啟動(dòng)菜單里選UEFI: U盤名進(jìn)入。前提是U盤根目錄下有EFI/BOOT/BOOTX64.EFI64位x86機(jī)器或者你把Shell.efi命名為這個(gè)路徑下的啟動(dòng)文件。在EDK2開發(fā)環(huán)境里直接用QEMU加OVMF固件跑一個(gè)虛擬機(jī)啟動(dòng)時(shí)也能進(jìn)Shell這個(gè)方法對(duì)學(xué)習(xí)語(yǔ)法來(lái)說(shuō)反而是最省事的。我自己平時(shí)調(diào)試用的組合是一臺(tái)裝了Linux的筆記本跑QEMUOVMF固件里直接集成Shell配合虛擬的FAT32磁盤鏡像腳本寫完不用燒到真實(shí)板卡就能驗(yàn)證語(yǔ)法。這個(gè)方法強(qiáng)烈推薦——因?yàn)檎鏅C(jī)上反復(fù)重啟測(cè)試時(shí)間成本太高了而且有些機(jī)器進(jìn)Shell的快捷鍵和菜單路徑差異很大會(huì)打斷你調(diào)試的思路。2.2 版本差異Shell 2.0與細(xì)節(jié)變化UEFI Shell有兩種主版本Shell 1.0和Shell 2.0。2.0是EDK2默認(rèn)的版本功能強(qiáng)很多比如支持for循環(huán)、支持-b分頁(yè)參數(shù)、支持環(huán)境變量的字符串操作等。1.0基本只在內(nèi)嵌的老固件里能碰到。到了2.0之后不同固件版本的具體實(shí)現(xiàn)其實(shí)也有差異。有的廠商自己編譯的Shell會(huì)砍掉一些命令有的則集成了一堆EFI Shell下的DXE驅(qū)動(dòng)。所以在某個(gè)機(jī)器上能用的腳本換臺(tái)機(jī)器可能就提示命令找不到。這種事兒我遇到過(guò)不止一次后面第6節(jié)會(huì)專門講怎么排查。現(xiàn)階段你只需要記住一個(gè)原則寫腳本時(shí)盡量用最基礎(chǔ)的內(nèi)置命令少依賴廠商自定義的擴(kuò)展命令。2.3 文件系統(tǒng)支持與Shell下的盤符邏輯進(jìn)到Shell之后第一件事通常是敲map命令看當(dāng)前有哪些可用映射。UEFI Shell下沒(méi)有C盤D盤的概念它用FS0:、FS1:這樣的格式來(lái)表示文件系統(tǒng)BLK0:、BLK1:表示塊設(shè)備。比如Shell map輸出會(huì)列出當(dāng)前能訪問(wèn)的所有設(shè)備映射。你輸入FS0:回車就能切換到第一個(gè)文件系統(tǒng)然后ls看目錄結(jié)構(gòu)。這里有個(gè)容易懵的地方一個(gè)U盤分一個(gè)區(qū)是FS0:如果某個(gè)磁盤上有多個(gè)FAT分區(qū)可能會(huì)映射成FS0:、FS1:而且映射順序不一定等于你的物理順序和UEFI固件對(duì)設(shè)備的枚舉順序有關(guān)。還有一點(diǎn)Shell只認(rèn)FAT12/16/32格式的文件系統(tǒng)NTFS、ext4這些在純Shell環(huán)境下是不認(rèn)的。你要想從U盤加載腳本U盤必須是FAT32格式別踩這個(gè)坑。3. UEFI Shell腳本的母語(yǔ)內(nèi)置命令與幫助體系3.1 先弄清楚Shell的命令從哪里來(lái)在動(dòng)手寫腳本之前得先搞明白Shell命令的分類。UEFI Shell下的命令大致分三類Shell內(nèi)置命令Shell自己實(shí)現(xiàn)的比如cd、ls、cp、mv、rm、set、alias、for、if等。這些不依賴外部文件永遠(yuǎn)可用。EFI應(yīng)用程序編譯出來(lái)的.efi文件放在某一路徑下通過(guò)Shell去加載執(zhí)行。最典型的就是Shell.efi本身以及你寫的一些.efi小工具。Shell命令腳本.nsh本次重點(diǎn)。本質(zhì)是一個(gè)包含若干Shell命令的文本文件Shell逐行解釋執(zhí)行。你在Shell里敲一條命令Shell會(huì)先查內(nèi)置命令表然后查當(dāng)前目錄下有沒(méi)有對(duì)應(yīng)的.efi或.nsh文件再根據(jù)path環(huán)境變量的設(shè)置去一系列目錄里查找。這個(gè)查找順序很重要后面會(huì)講一個(gè)因此引發(fā)的詭異Bug。3.2 常用內(nèi)置命令的功能分組我按使用場(chǎng)景把常用命令分了幾組這比死記命令列表高效得多文件操作類ls、cd、cp、mv、rm、mkdir、touch、type查看文本文件內(nèi)容、edit文本編輯器、hexedit十六進(jìn)制編輯器。其中edit寫短腳本非常實(shí)用不用來(lái)回在Shell和操作系統(tǒng)之間切換。系統(tǒng)信息類mem內(nèi)存信息、devices設(shè)備列表、drivers驅(qū)動(dòng)列表、bcfg啟動(dòng)項(xiàng)管理、smbiosviewSMBIOS信息、acpiACPI表信息、ver版本信息。內(nèi)存與端口操作類mm內(nèi)存讀寫、io端口讀寫、dmemdump內(nèi)存、dmesg類似Linux的dmesg。這些屬于固件調(diào)試的利器也是Shell最危險(xiǎn)的一面——改錯(cuò)一個(gè)內(nèi)存地址系統(tǒng)直接就掛。腳本控制類set、if、for、while、goto、shift、pause、stall延時(shí)、exit退出腳本或Shell、reset重啟。這些是腳本語(yǔ)法的核心。Shell環(huán)境類alias命令別名、path可執(zhí)行文件搜索路徑、map設(shè)備映射、echo、cls。其中map命令本身還能用來(lái)修改映射關(guān)系。3.3 用好-help參數(shù)比查文檔快十倍UEFI Shell每個(gè)命令都支持-?也就是help的縮寫參數(shù)。比如Shell ls -?就會(huì)輸出ls的完整用法、參數(shù)說(shuō)明、示例。這個(gè)參數(shù)信息是命令自己內(nèi)置的不需要聯(lián)網(wǎng)查文檔。我寫腳本的日常流程基本上是拿不準(zhǔn)某個(gè)參數(shù)就先命令 -?看一遍然后開一個(gè)Shell窗口在機(jī)器上驗(yàn)證另一個(gè)窗口用edit寫腳本。有一個(gè)小細(xì)節(jié)-?和-h不一定等價(jià)。部分命令只支持-?你要敲-h反而會(huì)被當(dāng)成非法參數(shù)。這個(gè)和Linux下的習(xí)慣不一樣很多人上來(lái)就敲-h然后提示參數(shù)錯(cuò)誤還以為命令壞了。4. 腳本語(yǔ)法核心變量、參數(shù)、流程控制寫法到這里開始進(jìn)入正題。UEFI Shell腳本文件是.nsh后綴的純文本文件一行一條命令支持#注釋。我把語(yǔ)法拆成幾個(gè)相對(duì)獨(dú)立的部分來(lái)講。4.1 變量與環(huán)境變量%符號(hào)的用法UEFI Shell里所有變量都是環(huán)境變量沒(méi)有單獨(dú)的局部變量概念。你用它它就是一個(gè)全局的環(huán)境變量你刪它用set命令。設(shè)置和引用的語(yǔ)法set MYVAR hello echo %MYVAR%第一行把環(huán)境變量MYVAR設(shè)成hello第二行輸出hello。注意引用變量時(shí)必須用%包裹這和Windows批處理里的%VAR%寫法一樣。刪除變量用set MYVAR后面不跟值就是刪除。或者set -d MYVAR?？串?dāng)前所有環(huán)境變量直接敲set不帶參數(shù)。有一個(gè)必須記住的坑**環(huán)境變量的值里如果包含特殊字符解析順序會(huì)導(dǎo)致意想不到的結(jié)果。**Shell對(duì)%的解析是在執(zhí)行命令之前做替換所以如果你在腳本里想輸出一個(gè)字面上的%得寫兩個(gè)%轉(zhuǎn)義——echo %%輸出一個(gè)%。這一點(diǎn)和批處理腳本一模一樣。Shell自帶一些內(nèi)置變量經(jīng)常用到的有%path%可執(zhí)行文件搜索路徑多個(gè)目錄用分號(hào)分隔。%cwd%當(dāng)前工作目錄。%lasterror%上一條命令的返回值/錯(cuò)誤碼。%startup%是否以startup.nsh方式啟動(dòng)腳本里可以用它判斷當(dāng)前是不是開機(jī)自啟。我實(shí)際寫腳本用到%lasterror%的頻率非常高。因?yàn)槟_本本身沒(méi)有try-catch機(jī)制判斷命令是否執(zhí)行成功唯一的辦法就是檢查錯(cuò)誤碼。4.2 腳本參數(shù)與shift處理執(zhí)行一個(gè).nsh腳本時(shí)可以帶參數(shù)比如Shell test.nsh arg1 arg2在腳本內(nèi)部%0拿到的是腳本名自身%1到%9依次是參數(shù)1到參數(shù)9%*是全部參數(shù)從參數(shù)1開始。有一個(gè)比較坑的地方UEFI Shell雖然支持shift命令但它的shift不太好用——它是把參數(shù)整體左移一位%1變成原來(lái)的%2以此類推。如果你拿%1做循環(huán)取出所有參數(shù)寫到第三四個(gè)參數(shù)之后容易亂套。我自己寫腳本處理不定長(zhǎng)參數(shù)時(shí)通常直接繞開%1~%9改用%*配合字符串截取操作。字符串操作指令在UEFI Shell里是%VAR:~start,len%這種風(fēng)格比如set fullarg %* set firsttwo %fullarg:~0,2%這可以截取參數(shù)的前兩個(gè)字符。語(yǔ)法風(fēng)格接近Windows批處理的%VAR:~m,n%。但因?yàn)镾hell對(duì)%的解析比較嚴(yán)格這種寫法在嵌套環(huán)境里偶爾會(huì)出問(wèn)題。所以遇到特別復(fù)雜的字符串處理我更推薦在腳本里調(diào)用echo加重定向生成一個(gè)新的臨時(shí)腳本再執(zhí)行這個(gè)臨時(shí)腳本——雖然笨但可控。4.3 分支if/then/else/endifUEFI Shell的if語(yǔ)法支持三種基礎(chǔ)形式if 條件 then 命令 endifif 條件 then 命令 else 命令 endifif 條件 then 命令 elseif 條件 then 命令 endif條件判定的寫法分兩種。一種是判斷環(huán)境變量是否存在或等于某個(gè)值if %MYVAR% hello then echo match endif另一種是文件存在性判斷if exist FS0:\EFI\BOOT\BOOTX64.EFI then echo found bootloader endif注意兩邊我習(xí)慣都加引號(hào)這是從批處理時(shí)代養(yǎng)成的習(xí)慣——如果%MYVAR%是空值不加引號(hào)會(huì)導(dǎo)致整個(gè)條件表達(dá)式語(yǔ)法不完整腳本會(huì)報(bào)錯(cuò)。加了引號(hào)之后空值就變成了一個(gè)空字符串參與比較穩(wěn)妥很多。還有三個(gè)邏輯運(yùn)算符可以用AND、OR、NOT。比如if exist FS0:\flag.txt AND %mode% test then echo enter test mode endif4.4 循環(huán)for和whilefor循環(huán)的語(yǔ)法是for %i in (val1 val2 val3) echo %i endfor注意循環(huán)變量用單個(gè)%不是雙%for %i in (1 2 3 4) echo %i endfor如果想遍歷文件列表可以這么寫for %i in FS0:\*.nsh echo %i endforShell會(huì)自己展開通配符把匹配到的文件路徑依次賦給%i。while循環(huán)的語(yǔ)法也類似while 條件 命令 endwhile這里有一個(gè)重要限制UEFI Shell的循環(huán)沒(méi)有計(jì)數(shù)器自動(dòng)遞增的能力如果你要用while計(jì)數(shù)必須自己修改變量。set counter 0 while %counter% 5 echo count is %counter% set counter %counter%1 endwhile等一下UEFI Shell的set命令不支持算術(shù)運(yùn)算。set counter %counter%1的結(jié)果是字符串01不是數(shù)字1。這是Shell腳本最讓人抓狂的地方——它沒(méi)有內(nèi)置的整數(shù)運(yùn)算能力。那怎么實(shí)現(xiàn)計(jì)數(shù)兩個(gè)辦法。一是借助for %i in (1 2 3 4 5)這種顯式列表實(shí)現(xiàn)固定次數(shù)循環(huán)二是用外部工具比如edk2自帶的parse命令或者其他小工具去處理數(shù)值?；蛘咄艘徊窖h(huán)次數(shù)已知就用for循環(huán)條件是基于環(huán)境變量且不需要自增的情況才用while。這個(gè)思路能讓你的腳本少走很多彎路。4.5 傳說(shuō)中的goto和標(biāo)簽UEFI Shell支持goto跳轉(zhuǎn)和標(biāo)簽goto :start ... :start echo start here標(biāo)簽是冒號(hào)加名字goto語(yǔ)句跳轉(zhuǎn)到指定標(biāo)簽。注意goto不能跳出當(dāng)前腳本文件的邊界——你沒(méi)法在一個(gè).nsh里goto到另一個(gè).nsh的標(biāo)簽。這和批處理一樣。但goto在Shell里還有一個(gè)比較危險(xiǎn)的行為如果標(biāo)簽不存在Shell不會(huì)報(bào)錯(cuò)退出而是直接跳到腳本末尾然后返回一個(gè)%lasterror%錯(cuò)誤碼。如果腳本是開機(jī)自啟動(dòng)的startup.nsh這種靜默失敗很容易被忽略后面真正要用的操作沒(méi)執(zhí)行你還不明所以。4.6 把多個(gè)命令串起來(lái)重定向和管道UEFI Shell支持重定向是覆蓋寫是追加寫。比如把命令輸出保存到文件ls FS0:\filelist.txt smbiosview -b FS0:\smbios.txt管道|在UEFI Shell里的支持比我想象中弱一些。實(shí)測(cè)下來(lái)管道在某些版本的Shell里能工作在另一些版本里會(huì)直接報(bào)語(yǔ)法錯(cuò)誤。比如ls | grep .efi這個(gè)命令在部分EDK2版本里能用Shell內(nèi)置了grep的簡(jiǎn)易實(shí)現(xiàn)但換到另一塊主板上可能就失敗了。我的經(jīng)驗(yàn)是正式腳本里盡量少用管道需要過(guò)濾輸出就先把結(jié)果重定向到臨時(shí)文件再用search命令或type加parse去處理。寧可多寫兩行也不要在管道這個(gè)特性上賭固件實(shí)現(xiàn)。5. 一個(gè)能直接上機(jī)跑的診斷備份腳本逐步拆解語(yǔ)法講再多不如一個(gè)完整的例子。下面這個(gè)腳本是我在某次批量主板測(cè)試中實(shí)際用的一個(gè)簡(jiǎn)化版本功能包括檢查設(shè)備映射、備份當(dāng)前BIOS區(qū)域模擬、收集SMBIOS信息、檢查關(guān)鍵啟動(dòng)文件是否存在。5.1 腳本的目標(biāo)與運(yùn)行邏輯這個(gè)腳本解決一個(gè)很實(shí)際的問(wèn)題現(xiàn)場(chǎng)運(yùn)維人員拿U盤插到機(jī)器上跑一下自動(dòng)把診斷信息和備份文件落盤然后退出。不需要他們懂Shell命令不需要手動(dòng)敲一堆指令。腳本放在U盤根目錄啟動(dòng)進(jìn)入Shell后執(zhí)行FS0:\debug.nsh所有輸出寫到同一個(gè)日志目錄下。5.2 完整腳本內(nèi)容# debug.nsh - 簡(jiǎn)易固件診斷與備份腳本 # 用法: debug.nsh [日志目錄](méi) 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設(shè)備映射 echo %LOGFILE% echo Device Map %LOGFILE% map %LOGFILE% # 2. dump SMBIOS信息 echo %LOGFILE% echo SMBIOS Info %LOGFILE% smbiosview -b %LOGFILE% # 3. 檢查關(guān)鍵EFI啟動(dòng)文件 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啟動(dòng)項(xiàng) echo %LOGFILE% echo Boot Option List %LOGFILE% bcfg boot dump %LOGFILE% # 5. 備份當(dāng)前啟動(dòng)項(xiàng)配置 echo %LOGFILE% echo Boot Option Backup %LOGFILE% bcfg boot dump -v %LOGFILE% echo %LOGFILE% echo Done. Log saved to %LOGFILE% pause exit5.3 逐段講解為什么這樣寫參數(shù)與默認(rèn)值腳本開頭先取%1作為日志目錄如果沒(méi)傳參就默認(rèn)用FS0:\LOGS。這里用到了前面講過(guò)的空判斷技巧——if %LOGDIR% 空值時(shí)%LOGDIR%被替換成空字符串表達(dá)式就變成了if 成立進(jìn)入默認(rèn)賦值邏輯。日志文件的命名我在這里耍了個(gè)小聰明debug_%lasterror%.log。第一次執(zhí)行時(shí)%lasterror%可能為空或0第二次執(zhí)行時(shí)它等于上一次某個(gè)命令的返回值。這個(gè)命名其實(shí)不夠嚴(yán)謹(jǐn)最終生成的文件名可能不唯一但勝在簡(jiǎn)單。嚴(yán)格一點(diǎn)的做法是用%time%或%date%拼一個(gè)時(shí)間戳但UEFI Shell里的時(shí)間格式依賴固件實(shí)現(xiàn)輸出經(jīng)常是10:20:30帶冒號(hào)Windows文件系統(tǒng)不認(rèn)冒號(hào)所以用時(shí)間戳反而容易踩坑。smbiosview -b參數(shù)smbiosview是EDK2自帶的SMBIOS查看命令-b表示分頁(yè)輸出。在重定向到文件時(shí)分頁(yè)參數(shù)不僅不會(huì)打斷輸出反而能讓內(nèi)容一次性完整落盤不會(huì)因?yàn)榭刂婆_(tái)緩沖區(qū)限制丟行。這個(gè)細(xì)節(jié)最開始我不知道導(dǎo)致dump出來(lái)的SMBIOS信息只有前幾行排查了半天。bcfg boot dumpbcfg是啟動(dòng)項(xiàng)管理命令。bcfg boot dump列出當(dāng)前所有啟動(dòng)項(xiàng)-v參數(shù)會(huì)輸出更詳細(xì)的信息比如關(guān)聯(lián)的設(shè)備路徑。這個(gè)命令對(duì)排查為什么開不了機(jī)類問(wèn)題非常有用。注意bcfg在某些精簡(jiǎn)固件里可能沒(méi)被編譯進(jìn)去如果提示命令不存在回頭看我第6節(jié)的排查方法。5.4 執(zhí)行與驗(yàn)證這個(gè)腳本寫完后實(shí)際執(zhí)行時(shí)我用了一個(gè)小技巧先在QEMU里跑一遍確認(rèn)語(yǔ)法沒(méi)問(wèn)題再放到真實(shí)U盤上跑。QEMU里跑的時(shí)候第一次執(zhí)行會(huì)報(bào)一堆smbiosview: command not found之類的錯(cuò)誤嗎其實(shí)不會(huì)因?yàn)镺VMF固件里帶了SHELL的完整命令集。但真機(jī)上確實(shí)可能缺命令所以我在腳本里做了一件事所有可能失敗的命令后面都靠%lasterror%去判斷。更關(guān)鍵的一點(diǎn)寫腳本時(shí)每條命令的返回值都是獨(dú)立的。比如mkdir %LOGDIR%在目錄已存在時(shí)會(huì)返回錯(cuò)誤碼但這不影響腳本繼續(xù)執(zhí)行——Shell腳本默認(rèn)不會(huì)因?yàn)閱螚l命令失敗而中止除非你顯式寫-exit或使用abort命令。這也是很多新手感到困惑的地方明明上一行報(bào)錯(cuò)腳本還是往下跑了。理解這一點(diǎn)就能明白為什么腳本里要手動(dòng)檢查關(guān)鍵步驟的%lasterror%。6. 踩坑實(shí)錄六年UEFI Shell使用中遇到的典型問(wèn)題這一部分單獨(dú)拎出來(lái)因?yàn)檫@些坑我?guī)缀醵紝?shí)實(shí)在在踩過(guò)每一類都花過(guò)不少時(shí)間排查。寫出來(lái)幫你省點(diǎn)時(shí)間。6.1 文件系統(tǒng)大小寫與路徑分隔符UEFI Shell的文件系統(tǒng)和UEFI規(guī)范一樣不區(qū)分大小寫但輸出時(shí)可能混合大小寫。有次我寫了一個(gè)判斷if exist fs0:\EFI\BOOT\BOOTX64.EFI then注意我寫的是小寫fs0。Shell能認(rèn)出這個(gè)盤符嗎在大多數(shù)固件實(shí)現(xiàn)里可以但有些嚴(yán)謹(jǐn)?shù)膶?shí)現(xiàn)可能要求必須用FS0:全部大寫。我的建議是腳本里統(tǒng)一用大寫盤符、大寫路徑分隔符避免在固件兼容性上賭運(yùn)氣。路徑分隔符一律用反斜杠\不要用正斜杠/。UEFI規(guī)范里正斜杠在某些上下文里有特殊含義比如作為參數(shù)前綴萬(wàn)一你把路徑寫錯(cuò)排查起來(lái)非常痛苦。6.2 命令找不到環(huán)境變量和當(dāng)前目錄的坑path環(huán)境變量影響Shell對(duì)可執(zhí)行文件的查找范圍。有次我腳本里用了一個(gè)自研的診斷.efi工具放在U盤的EFI\Tools目錄下。腳本第一行執(zhí)行set path FS0:\EFI\Tools;%path%結(jié)果下一行調(diào)用這個(gè)工具時(shí)Shell提示命令找不到。排查了半天發(fā)現(xiàn)是set path這個(gè)操作本身的問(wèn)題——當(dāng)一個(gè)環(huán)境變量名是path時(shí)Shell在執(zhí)行set path ...之后當(dāng)前這條命令的解析還沒(méi)結(jié)束它用的還是舊的path。等到下一條命令時(shí)新的path才生效。這看起來(lái)很正常但問(wèn)題在于腳本第一行設(shè)置path第二行就要用應(yīng)該沒(méi)問(wèn)題啊后來(lái)發(fā)現(xiàn)真正的原因是UEFI Shell在解析腳本時(shí)某些實(shí)現(xiàn)會(huì)在每行執(zhí)行前重新讀取path變量而另一些實(shí)現(xiàn)只在腳本開始執(zhí)行時(shí)讀取一次path快照。第一種實(shí)現(xiàn)里你中途改path對(duì)后續(xù)行生效第二種實(shí)現(xiàn)里你必須把path設(shè)置放在腳本最開頭或者用一個(gè)外層的wrapper腳本去設(shè)置path再調(diào)用真正的腳本。 這個(gè)行為差異沒(méi)有寫在規(guī)范里純靠實(shí)測(cè)發(fā)現(xiàn)?，F(xiàn)在的處理策略是把path設(shè)置獨(dú)立放在一個(gè)env.nsh文件里所有需要環(huán)境變量的腳本第一行都改成include env.nsh或直接復(fù)制那兩行set命令。繞開實(shí)現(xiàn)差異。6.3include指令別對(duì)它寄予太多希望UEFI Shell有一個(gè)include命令可以理解為類似C語(yǔ)言的#include。用法include FS0:\env.nsh但實(shí)測(cè)下來(lái)include在多個(gè)版本里行為不太穩(wěn)定有的要求被include的文件必須帶.nsh擴(kuò)展名否則拒絕執(zhí)行有的在相對(duì)路徑下解析失敗。而且它不能傳參數(shù)被include的腳本里%1~%9會(huì)被清空還是保留原調(diào)用者的參數(shù)不同版本表現(xiàn)不一樣。我后來(lái)基本不用include需要復(fù)用代碼就直接把內(nèi)容復(fù)制進(jìn)主腳本或者通過(guò)執(zhí)行子腳本的方式傳遞參數(shù)call FS0:\subtask.nsh %parm%call是執(zhí)行另一個(gè)腳本的正確姿勢(shì)它會(huì)等子腳本執(zhí)行完再回到當(dāng)前腳本繼續(xù)。雖然每啟動(dòng)一次子腳本有開銷但在腳本規(guī)模不大的前提下可維護(hù)性比include強(qiáng)太多。6.4 腳本編碼與不可見字符UEFI Shell腳本文本文件的編碼要求不算嚴(yán)格但必須注意兩點(diǎn)。第一**保存為Unix換行LF還是Windows換行CRLF**實(shí)測(cè)而言Shell對(duì)兩種換行都能處理但混合換行會(huì)出問(wèn)題。如果腳本在Windows下編輯完放到Linux環(huán)境改了一行再拷回U盤文件中同時(shí)出現(xiàn)LF和CRLFShell會(huì)在某些版本里把一個(gè)\r當(dāng)成命令的一部分導(dǎo)致命令不存在之類的報(bào)錯(cuò)而且報(bào)錯(cuò)指向的行和你實(shí)際出錯(cuò)的行對(duì)不上——因?yàn)橹鹦薪馕鰰r(shí)CR被吞掉與否取決于實(shí)現(xiàn)。第二如果腳本里含非ASCII字符比如中文注釋必須在文件頭部加BOM否則Shell的文本解析可能亂碼。這個(gè)問(wèn)題在UEFI Shell 2.0之后有所緩解但保險(xiǎn)起見腳本里我一般只用純英文注釋。6.5%lasterror%的時(shí)效性%lasterror%變量在每條命令執(zhí)行后都會(huì)更新但它有個(gè)特點(diǎn)內(nèi)置變量對(duì)set命令本身也會(huì)被更新。也就是說(shuō)你執(zhí)行set foo 1之后%lasterror%變成的是這次set是否成功的狀態(tài)而不是最初那條你想檢查的命令的狀態(tài)。所以正確的檢查姿勢(shì)是這樣的bcfg boot dump FS0:\boot.txt set ERRCODE %lasterror% if %ERRCODE% 0 then echo dump ok else echo dump failed with %ERRCODE% endif先把%lasterror%存到一個(gè)普通環(huán)境變量里再拿去判斷。直接寫if %lasterror% 0雖然也能用但中間一旦插入別的命令比如echo值可能已經(jīng)變了。還有一個(gè)小細(xì)節(jié)%lasterror%雖說(shuō)是錯(cuò)誤碼但Shell命令成功時(shí)的返回值不一定是0。有些命令返回的不是標(biāo)準(zhǔn)0而是自定義狀態(tài)碼。所以判斷成功時(shí)更可靠的方式是檢查輸出文件的內(nèi)容是不是符合預(yù)期而不是只看返回碼。6.6 內(nèi)存讀寫命令的危險(xiǎn)性mm命令可以在Shell里直接讀寫物理內(nèi)存和IO端口Shell mm 0xE0000000 # 讀這個(gè)地址的內(nèi)容 Shell mm 0xE0000000 0x1F # 往這個(gè)地址寫0x1F這是固件調(diào)試的利器但也是最大的危險(xiǎn)源。寫錯(cuò)一個(gè)地址輕則系統(tǒng)死機(jī)重則把SPI Flash里的固件搞壞。我見過(guò)同事在調(diào)試時(shí)用mm往某個(gè)不知道是什么的地址寫了個(gè)值重啟后板子直接起不來(lái)最后靠編程器重新燒固件才救回來(lái)。在腳本里涉及mm操作我的建議是先dmem或mem把目標(biāo)區(qū)域讀一遍確認(rèn)地址有效。寫操作前人工確認(rèn)三次地址沒(méi)錯(cuò)。不要在自動(dòng)化腳本里放未驗(yàn)證的mm寫操作。操作完馬上reset重啟觀察不要繼續(xù)跑后面的腳本。6.7startup.nsh的自動(dòng)執(zhí)行機(jī)制如果你把U盤插上Shell啟動(dòng)時(shí)會(huì)自動(dòng)嘗試執(zhí)行U盤根目錄下的startup.nsh。這是一個(gè)很方便的機(jī)制但也容易出事故。有一次我調(diào)試腳本把startup.nsh放到U盤根目錄內(nèi)容是一個(gè)死循環(huán)等待某個(gè)條件。結(jié)果每次開機(jī)進(jìn)Shell就卡死拔U盤都來(lái)不及——因?yàn)镾hell啟動(dòng)時(shí)讀不到文件系統(tǒng)U盤被占住拔掉就報(bào)錯(cuò)。最后只能重啟進(jìn)BIOS把啟動(dòng)順序改成直接進(jìn)系統(tǒng)再把U盤格式化才解決。所以我對(duì)startup.nsh的態(tài)度是開發(fā)階段不要把調(diào)試腳本命名為startup.nsh用普通文件名手動(dòng)執(zhí)行。需要自動(dòng)執(zhí)行時(shí)startup.nsh里只放一個(gè)調(diào)用其他腳本的語(yǔ)句不要寫長(zhǎng)邏輯。重要操作前先pause給你自己留一個(gè)取消執(zhí)行的機(jī)會(huì)。6.8 腳本超時(shí)與交互Shell腳本執(zhí)行過(guò)程中如果需要人工輸入通常用pause命令等按任意鍵。但pause在無(wú)人值守場(chǎng)景下會(huì)卡住整個(gè)流程。如果需要倒計(jì)時(shí)自動(dòng)繼續(xù)可以寫一個(gè)循環(huán)配合stall命令單位是微秒實(shí)現(xiàn)延時(shí)set countdown 5 while %countdown% 0 echo Continue in %countdown% ... stall 1000000 set countdown ... endwhile這里有個(gè)矛盾set不支持算術(shù)運(yùn)算所以set countdown %countdown%-1是無(wú)效的。實(shí)際做法是把倒計(jì)時(shí)變量拆成多個(gè)if判斷或者干脆用固定次數(shù)的for循環(huán)。比如for %i in (5 4 3 2 1) echo Continue in %i ... stall 1000000 endfor這個(gè)方案最簡(jiǎn)單既不依賴算術(shù)運(yùn)算也不容易出錯(cuò)。7. 把Shell腳本用在自動(dòng)化測(cè)試?yán)锏墓こ袒悸纷詈笠徊糠至牧脑趺窗?nsh腳本寫得像工程代碼而不是隨手寫的玩具。這幾年我在固件驗(yàn)證項(xiàng)目里逐漸摸索出一套自己的規(guī)范分享出來(lái)供參考。7.1 約定目錄結(jié)構(gòu)一個(gè)完整的U盤工具包目錄結(jié)構(gòu)建議如下FS0:\ ├── startup.nsh # 入口腳本可選 ├── scripts\ │ ├── common.nsh # 公共函數(shù)用call調(diào)用 │ ├── debug.nsh │ ├── backup.nsh │ └── flash.nsh ├── tools\ │ ├── shell.efi # 備用Shell │ ├── xxxdiag.efi # 自定義診斷工具 │ └── ... └── logs\ # 日志輸出目錄腳本里統(tǒng)一用scripts\和tools\的絕對(duì)路徑不要在幾十行里到處寫FS0:\這種硬編碼。如果U盤盤符變了比如插到不同USB口變成FS1:至少還有救——你只需要改頂部的幾個(gè)set變量。7.2 輸出規(guī)范與日志級(jí)別UEFI Shell的echo命令沒(méi)有彩色輸出也沒(méi)法區(qū)分日志級(jí)別。我的做法是在腳本里統(tǒng)一一個(gè)日志函數(shù)的概念用子腳本實(shí)現(xiàn):log_info echo [INFO] %1 %LOGFILE% goto :EOF但前面說(shuō)過(guò)goto :EOF在UEFI Shell里的支持不完全可靠所以這種函數(shù)寫法我很少用。更實(shí)際的做法是每條輸出都同時(shí)打到屏幕和日志文件屏幕輸出幫助操作者實(shí)時(shí)了解進(jìn)展日志文件用于事后審計(jì)。具體寫法是這樣echo Step 1: dump smbios... | tee %LOGFILE%等等tee命令在UEFI Shell里通常沒(méi)有。所以實(shí)際做法是寫兩行echo Step 1: dump smbios... %LOGFILE% echo Step 1: dump smbios...麻煩是麻煩一點(diǎn)但可靠。我已經(jīng)不指望Shell腳本能寫出多優(yōu)雅的日志框架了能穩(wěn)定執(zhí)行比什么都強(qiáng)。7.3 與UEFI固件內(nèi)部的交互變量命名空間環(huán)境變量名不要起得太通用。比如你腳本里用了一個(gè)set boot后面某段代碼也用了set boot互相覆蓋了排查起來(lái)非常費(fèi)勁。我建議所有腳本變量統(tǒng)一加前綴比如項(xiàng)目名縮寫set DBG_LOGDIR FS0:\LOGS set DBG_MODE 1這樣不同腳本之間的變量沖突概率大大降低。另外注意UEFI Shell的環(huán)境變量會(huì)隨腳本退出而保留除非你顯式刪除或整個(gè)Shell重啟。也就是說(shuō)一個(gè)腳本設(shè)置的變量另一個(gè)腳本能看到。這既是便利也是隱患——一個(gè)寫壞了的變量可能在半小時(shí)后的另一個(gè)腳本里莫名出現(xiàn)。7.4 錯(cuò)誤碼傳遞與失敗處理腳本失敗時(shí)的退出碼是%lasterror%。在自動(dòng)化測(cè)試框架里我們經(jīng)常在Shell腳本的最外層套一個(gè)Linux或Windows側(cè)的驅(qū)動(dòng)腳本用串口或網(wǎng)絡(luò)和Shell交互。Shell側(cè)接收參數(shù)、執(zhí)行測(cè)試、返回錯(cuò)誤碼宿主側(cè)解析。這種模式下exit %lasterror%就非常關(guān)鍵確保Shell退出時(shí)把最后的錯(cuò)誤碼帶出去。但有兩點(diǎn)要特別小心不是所有版本的Shell都支持exit %lasterror%的語(yǔ)法。部分實(shí)現(xiàn)只支持exit不帶參數(shù)返回碼永遠(yuǎn)是0。如果你在.nsh里執(zhí)行了另一個(gè).efi程序該程序的退出碼會(huì)通過(guò)%lasterror%暴露出來(lái)但前提是Shell沒(méi)在這之間執(zhí)行其他命令。任何一條命令都可能覆蓋它。為了確保錯(cuò)誤碼正確傳遞在測(cè)試框架里我會(huì)專門寫一個(gè)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%宿主側(cè)的腳本只認(rèn)result.txt里的內(nèi)容不依賴Shell退出碼——因?yàn)閷?shí)測(cè)下來(lái)有的固件版本退出碼頭幾位的字節(jié)會(huì)被截?cái)鄬?dǎo)致宿主側(cè)收到奇怪的值。7.5 與DXE驅(qū)動(dòng)和EFI應(yīng)用的配合UEFI Shell最有意思的地方是可以加載DXE驅(qū)動(dòng)和運(yùn)行各種EFI應(yīng)用。比如在測(cè)試過(guò)程中你可能需要先加載一個(gè)自定義的協(xié)議驅(qū)動(dòng)再跑測(cè)試工具。典型寫法load FS0:\tools\MyDriver.efi if %lasterror% 0 then echo driver loaded else echo driver load failed endifload命令加載驅(qū)動(dòng)后驅(qū)動(dòng)常駐內(nèi)存。此時(shí)可以用drivers命令查看驅(qū)動(dòng)列表用devices查看設(shè)備節(jié)點(diǎn)。如果有新設(shè)備出現(xiàn)說(shuō)明驅(qū)動(dòng)生效了。加載驅(qū)動(dòng)時(shí)特別需要注意驅(qū)動(dòng)一旦加載成功直到系統(tǒng)重啟前都不會(huì)被卸載。你連續(xù)加載同一驅(qū)動(dòng)兩次第二次會(huì)返回錯(cuò)誤但這個(gè)錯(cuò)誤并不影響第一次加載的效果。所以腳本里不要因?yàn)槟炒渭虞d報(bào)錯(cuò)就判定驅(qū)動(dòng)有問(wèn)題要結(jié)合drivers輸出確認(rèn)是否已在列表里。7.6 QEMU聯(lián)調(diào)不燒板子練腳本最后安利一下QEMU調(diào)試法。EDK2項(xiàng)目官方就提供OVMF固件配合QEMU可以完整模擬UEFI環(huán)境。具體步驟下載編譯好的OVMF.fd固件或者自己從EDK2源碼編譯。準(zhǔn)備一個(gè)FAT32格式的磁盤鏡像把寫好的.nsh文件放進(jìn)去。啟動(dòng)命令大致是qemu-system-x86_64 -drive ifpflash,formatraw,fileOVMF.fd -drive formatraw,filefat:rw:./diskQEMU啟動(dòng)時(shí)會(huì)自動(dòng)進(jìn)入OVMF的菜單選擇UEFI Shell即可。這個(gè)方法有兩個(gè)好處一是完全不用碰真實(shí)硬件腳本寫錯(cuò)了重啟一下虛擬機(jī)就行二是QEMU支持GDB調(diào)試你可以結(jié)合EDK2源碼單步跟蹤Shell命令的執(zhí)行流程理解每一條命令背后的邏輯。不過(guò)對(duì)大多數(shù)應(yīng)用場(chǎng)景來(lái)說(shuō)能快速驗(yàn)證語(yǔ)法就夠了也不必深入到那個(gè)程度。8. 最后分享幾個(gè)關(guān)于Shell腳本的心得回想這幾年跟UEFI Shell打交道的經(jīng)歷最深的感觸是這工具看著像Linux終端用起來(lái)像DOS批處理但它的很多細(xì)節(jié)都夾在固件實(shí)現(xiàn)和硬件平臺(tái)的縫隙里。同一個(gè)腳本在這塊板子上跑得好好的換一塊板子可能就行為迥異。所以我的建議一直沒(méi)變——腳本要向最基礎(chǔ)的命令看齊不要賭固件實(shí)現(xiàn)的一致性和文檔沒(méi)有覆蓋的邊界行為。具體到日常使用有幾件事是我每次上手都會(huì)做的拿到一臺(tái)新機(jī)器先敲ver看Shell版本再敲map看設(shè)備最后ls -?、bcfg -?看命令支持情況?；ㄎ宸昼娍焖僭u(píng)估這臺(tái)機(jī)器的Shell能力邊界比后面盲寫腳本踩坑強(qiáng)得多。寫任何涉及硬件操作的腳本前先在虛擬機(jī)里跑通邏輯再在真機(jī)上人工跑一遍驗(yàn)證命令可用性和輸出格式最后才正式使用。遇到詭異問(wèn)題先用type或hexedit看腳本文本有沒(méi)有不可見字符然后再懷疑語(yǔ)法。這個(gè)排查路徑能解決相當(dāng)一部分奇怪的問(wèn)題。如果你平時(shí)做BIOS開發(fā)或固件測(cè)試UEFI Shell腳本看著不起眼但熟練之后真的能幫你把很多重復(fù)的調(diào)試工作變成一條命令的事。把這篇文章里的語(yǔ)法和踩坑點(diǎn)消化掉你大概率就能寫出屬于自己的第一版可復(fù)用腳本了。