硬件調(diào)試三板斧從點(diǎn)燈到追日志的OpenHarmony實(shí)戰(zhàn)做OpenHarmony開發(fā)最痛苦的是什么不是API不會(huì)調(diào)也不是應(yīng)用寫不出來而是板子莫名其妙不干活的時(shí)候你整個(gè)人對著屏幕發(fā)呆不知道從哪里下手。我接觸OpenHarmony系統(tǒng)實(shí)戰(zhàn)開發(fā)也有一段時(shí)間了從RK3566到RK3568從官方開發(fā)板到各種第三方核心板踩過不少坑也總結(jié)出了自己的一套調(diào)試打法說白了就三樣?xùn)|西指示燈、串口日志、邏輯分析儀。這三板斧用好了大部分硬件問題都能當(dāng)場鎖定比什么高級仿真器都管用。這篇文章我就把這套方法從頭到尾捋一遍順便把最近社區(qū)里問得最多的RK3568設(shè)備樹選擇和x86版OpenHarmony電腦端相關(guān)問題也一起聊透。這篇文章不是寫給純新手的但也別被“系統(tǒng)開發(fā)”四個(gè)字嚇住只要你摸過開發(fā)板、燒過系統(tǒng)、會(huì)看log就能跟上思路。文中所有操作步驟都基于我自己的實(shí)測環(huán)境我會(huì)把選型邏輯、參數(shù)調(diào)整、坑點(diǎn)規(guī)避全部說清楚你能直接照著做也能在理解之后自己擴(kuò)展出更適合你項(xiàng)目的調(diào)試方案。1. 核心思路拆解為什么調(diào)試手段就這三板斧1.1 硬件調(diào)試的真實(shí)痛點(diǎn)OpenHarmony和安卓、Linux不一樣的地方在于它雖然也跑在標(biāo)準(zhǔn)硬件上但生態(tài)還在快速演進(jìn)中驅(qū)動(dòng)不全、文檔斷層、社區(qū)問答分散是常態(tài)。很多時(shí)候你遇到的問題不是“邏輯寫錯(cuò)了”而是“硬件根本沒按你預(yù)期去跑”。我舉個(gè)實(shí)際例子剛拿到一塊RK3568開發(fā)板時(shí)大家通常是先跑個(gè)標(biāo)準(zhǔn)鏡像點(diǎn)亮屏幕讓系統(tǒng)起來。但從編譯系統(tǒng)到燒錄完成中間任何一個(gè)環(huán)節(jié)出了問題你面臨的都是“黑屏”或者“串口無輸出”這種最原始的故障狀態(tài)。這種時(shí)候IDE里的斷點(diǎn)、gdb attach全都派不上用場因?yàn)槟氵B系統(tǒng)都進(jìn)不去。這時(shí)候三板斧的價(jià)值就體現(xiàn)出來了指示燈GPIO/LED系統(tǒng)里最小粒度的可視化反饋能告訴你代碼有沒有執(zhí)行到某個(gè)位置。串口日志系統(tǒng)運(yùn)行的“黑匣子”雖然信息量大但帶著時(shí)間戳和模塊標(biāo)簽?zāi)芫_定位崩潰點(diǎn)。邏輯分析儀查看協(xié)議時(shí)序是否正常的“照妖鏡”I2C、SPI、UART這類總線的波形異常一眼就能掃出來。這三樣?xùn)|西覆蓋面廣操作門檻低而且不需要昂貴的調(diào)試硬件是性價(jià)比最高的調(diào)試組合。1.2 為什么首選RK3568平臺(tái)做OpenHarmony實(shí)戰(zhàn)OpenHarmony官方和社區(qū)目前適配最成熟的SBC平臺(tái)之一就是RK3568系列。它在整個(gè)產(chǎn)品矩陣?yán)锒ㄎ皇恰爸卸送ㄓ眯蚐oC”四核A55帶G52 GPU內(nèi)置NPU算力1TOPS左右支持4K編解碼還集成了非常豐富的顯示、音頻、網(wǎng)絡(luò)接口。對于硬件調(diào)試教程來說RK3568的優(yōu)勢有幾點(diǎn)第一硬件設(shè)計(jì)成熟參考資料充分。官方DevBoard和第三方核心板都是按照RK3568的參考設(shè)計(jì)做的原理圖、PCB、設(shè)備樹都有現(xiàn)成源碼可以對著看。你調(diào)試時(shí)如果發(fā)現(xiàn)某個(gè)外設(shè)不工作完全是“對照參考設(shè)計(jì)就能找出差異”的節(jié)奏。第二設(shè)備樹機(jī)制透明適合學(xué)習(xí)。RK3568在Linux內(nèi)核和OpenHarmony內(nèi)核里都采用了標(biāo)準(zhǔn)的設(shè)備樹DTS來描述硬件不像某些平臺(tái)把所有硬件配置寫死在源碼里。這意味著你可以通過修改DTS動(dòng)態(tài)調(diào)整引腳的復(fù)用、電源域、時(shí)鐘頻率整套機(jī)制學(xué)通了以后換任何一顆RK芯片都能快速上手。第三驅(qū)動(dòng)覆蓋廣驗(yàn)證場景多。以太網(wǎng)、WiFi/BT、HDMI/MIPI DSI顯示、MIPI CSI攝像頭、I2C/SPI/UART傳感器全部有現(xiàn)成驅(qū)動(dòng)每個(gè)外設(shè)都可以作為調(diào)試案例來講解。我之前在多個(gè)群和社區(qū)里看到有人問“RK3568到底有多少個(gè)設(shè)備樹文件每個(gè)文件有什么區(qū)別我該選哪一個(gè)”這個(gè)問題其實(shí)問到了點(diǎn)子上因?yàn)樵O(shè)備樹選不對編譯出來的內(nèi)核壓根不認(rèn)識(shí)你的板子后面所有調(diào)試都是空中樓閣。1.3 三板斧在調(diào)試流程中的分工協(xié)作這三板斧不是各干各的而是銜接在一起形成一條完整的故障定位鏈條最外層是指示燈用于快速判斷“系統(tǒng)活了沒有”。比如U-Boot階段亮一次LED內(nèi)核啟動(dòng)階段再閃兩次init階段進(jìn)入用戶空間后常亮。這套邏輯一旦固化下來你上電后瞄一眼燈的狀態(tài)就能判斷系統(tǒng)卡在了哪個(gè)階段。第二層是串口日志用于精準(zhǔn)定位“卡在哪個(gè)模塊”。比如內(nèi)核啟動(dòng)到某個(gè)驅(qū)動(dòng)的probe函數(shù)時(shí)日志停止那你就能鎖定是這個(gè)驅(qū)動(dòng)出了問題繼續(xù)查它的依賴、時(shí)鐘、供電。第三層是邏輯分析儀用于深入細(xì)節(jié)“為什么這個(gè)模塊沒反應(yīng)”。比如I2C設(shè)備沒有被識(shí)別那就抓I2C總線波形看看地址對不對、ACK有沒有拉低、時(shí)序是不是符合規(guī)范。這個(gè)分層邏輯我強(qiáng)烈建議在做任何板級調(diào)試之前先建立起來它不僅適用于OpenHarmony做Linux、RTOS、裸機(jī)開發(fā)都通用。2. 核心細(xì)節(jié)解析設(shè)備樹選擇與硬件發(fā)現(xiàn)機(jī)制設(shè)備樹是驅(qū)動(dòng)開發(fā)繞不開的一道坎尤其是OpenHarmony這類需要嚴(yán)格匹配硬件的系統(tǒng)。很多新手第一關(guān)就倒在“不知道選哪個(gè)dts”上其實(shí)背后搞清楚機(jī)制后非常簡單。2.1 RK3568設(shè)備樹文件的命名規(guī)則與版本演進(jìn)在OpenHarmony內(nèi)核源碼中RK3568相關(guān)的設(shè)備樹文件命名通常會(huì)帶上開發(fā)板型號(hào)和SoC型號(hào)格式一般是arch/arm64/boot/dts/rockchip/rk3568-xxx-evb.dts 或 arch/arm64/boot/dts/rockchip/rk3568-xxx-rk817.dts其中rk3568代表SoC型號(hào)xx代表開發(fā)板或產(chǎn)品名稱evb表示這是評估板版本。社區(qū)里常見的有rk3568-evb1-ddr4-v10.dts、rk3568-evb2-lpddr4-v10.dts、rk3568-rock-3a.dts等。這些文件看起來很多其實(shí)規(guī)律性很強(qiáng)后綴帶evb1/evb2/evb3的是瑞芯微官方評估板分別對應(yīng)不同形態(tài)如小板、大板、帶PCIe板。后綴帶具體品牌型號(hào)如rock-3a、radxa-cm3、orangepi-3b的是第三方廠商適配的。后綴帶的ddr類型ddr4/lpddr4/lpddr3表示內(nèi)存顆粒類型這個(gè)直接決定內(nèi)存初始化參數(shù)千萬不能選錯(cuò)。選擇設(shè)備樹時(shí)最核心的原則是要和你的板子PCB完全匹配差一個(gè)型號(hào)名稱都不行。2.2 實(shí)操選擇方法三步定位正確dts具體操作我分三步講第一步確認(rèn)SoC型號(hào)和封裝。RK3568有兩個(gè)常見封裝BGA636和BGA336。BGA636引腳多功能全常見于標(biāo)準(zhǔn)核心板BGA336是精簡版去掉了部分PCIe/顯示接口多見于低成本方案。你買板子時(shí)問一句商家是哪個(gè)封裝然后直接搜對應(yīng)關(guān)鍵詞能找到很多現(xiàn)成的dts。第二步確認(rèn)DDR顆粒型號(hào)和容量。這個(gè)看似小細(xì)節(jié)實(shí)際上影響巨大。DDR初始化在U-Boot階段就開始了如果dts里寫的DDR容量和實(shí)際顆粒不一致輕則內(nèi)存少一半重則直接啟動(dòng)失敗。我試過一塊板子標(biāo)稱4GB實(shí)際焊了兩顆2GB顆粒但dts里配的是單顆4GB模式結(jié)果系統(tǒng)起來只有2GB可用這種問題從日志上很難一眼發(fā)現(xiàn)只有free -h看內(nèi)存總量時(shí)才露餡。第三步對比原理圖與dts里的IO定義。這一步最費(fèi)時(shí)間但也最值得做。你可以用dts文件里的引腳復(fù)用配置對照板子的原理圖逐個(gè)核對關(guān)鍵外設(shè)。等以后驅(qū)動(dòng)出問題了你回來查這幾個(gè)ppln。我這邊的經(jīng)驗(yàn)是拿到一塊新板子先花兩小時(shí)把設(shè)備樹過一遍比直接跑build然后盲目調(diào)驅(qū)動(dòng)要高效得多。因?yàn)檫壿嫹治鰞x抓到的波形異常絕大多數(shù)原因追根溯源都在dts配置錯(cuò)誤上。2.3 選錯(cuò)設(shè)備樹會(huì)引發(fā)哪些典型故障社區(qū)里關(guān)于“選錯(cuò)設(shè)備樹導(dǎo)致什么現(xiàn)象”的討論非常多我把常見的、我親身遇到過的總結(jié)成表格方便你以后排查癥狀原因分析排查方法系統(tǒng)起來但內(nèi)存只有一半dts中DDR容量與顆粒容量不匹配查看free -h確認(rèn)實(shí)際內(nèi)存對比板卡規(guī)格WiFi/藍(lán)牙無法掃描到設(shè)備dts中M.2或SDIO接口的IO復(fù)用被其他功能占用邏輯分析儀抓SDIO CLK/CMD波形是否有時(shí)鐘輸出HDMI無輸出顯示相關(guān)的display-subsystem節(jié)點(diǎn)未匹配串口日志搜索hdmi相關(guān)關(guān)鍵字查看是否有failed to find component報(bào)錯(cuò)觸摸屏點(diǎn)擊無反應(yīng)I2C節(jié)點(diǎn)地址錯(cuò)誤或中斷GPIO號(hào)錯(cuò)誤邏輯分析儀抓I2C總線確認(rèn)觸摸IC ACK再看中斷引腳電壓是否變化系統(tǒng)卡在內(nèi)核啟動(dòng)后半段外設(shè)驅(qū)動(dòng)probe失敗可能是電源域或時(shí)鐘配置缺失串口日志搜索probe fail、resource error逐個(gè)模塊排查以太網(wǎng)不通gmac相關(guān)IO復(fù)位腳配置錯(cuò)誤示波器/萬用表量復(fù)位引腳電平是否正常這個(gè)表格也是我一直存在筆記里的速查表排查效率最高。3. 實(shí)操過程搭建OpenHarmony硬件調(diào)試環(huán)境理論說再多不如上手干一次。這一節(jié)我?guī)阕咭槐橥暾恼{(diào)試環(huán)境搭建流程包含源碼獲取、鏡像構(gòu)建、燒錄和日志抓取。3.1 開發(fā)機(jī)準(zhǔn)備Ubuntu環(huán)境與必要工具OpenHarmony官方推薦在Ubuntu 20.04及以上版本構(gòu)建我自己用的是Ubuntu 22.04 LTS機(jī)器配置建議至少16GB內(nèi)存雙核以上CPU磁盤剩余空間不低于200GB。因?yàn)橐淮瓮暾麡?gòu)建會(huì)占用大量磁盤空間源碼加中間產(chǎn)物動(dòng)輒幾十GB起步。先安裝必要依賴sudo apt update sudo apt install -y git git-lfs gcc g make cmake ninja-build \ python3 python3-pip python3-setuptools rsync curl wget \ file unzip zip openssl libssl-dev接著配置repo工具OpenHarmony源碼用repo管理和Android的repo類似mkdir -p ~/bin curl https://storage.googleapis.com/git-repo-downloads/repo ~/bin/repo chmod ax ~/bin/repo如果這個(gè)地址不可用也可以用清華源、阿里源上的repo副本效果一樣。3.2 獲取源碼并選擇分支OpenHarmony代碼托管在Gitee上主線分支一般叫master或OpenHarmony-4.x-Release。這里有個(gè)關(guān)鍵點(diǎn)開發(fā)板的標(biāo)準(zhǔn)鏡像通常跟著某個(gè)release分支發(fā)布為了避免工具鏈和驅(qū)動(dòng)不匹配建議直接拉和板子發(fā)布時(shí)相同的分支。mkdir ohos cd ohos repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-4.1-Release --no-repo-verify repo sync -c -j8同步完后確認(rèn)一下內(nèi)核目錄下的dts是否存在ls kernel/linux/linux-5.10/arch/arm64/boot/dts/rockchip/ | grep rk3568如果能看到一堆rk3568-*.dts文件說明你拉到的源碼包含RK3568平臺(tái)支持接下來可以開始定制。3.3 定制一個(gè)最小調(diào)試設(shè)備樹假設(shè)我拿到一塊RK3568核心板底板上有一顆LED接在GPIO0_C3上這顆LED就是我最主要的調(diào)試指示燈。我要在dts中增加一個(gè)gpio-leds節(jié)點(diǎn)/ { leds { compatible gpio-leds; status okay; debug_led: led-0 { gpios gpio0 RK_PC3 GPIO_ACTIVE_HIGH; linux,default-trigger heartbeat; function LED_FUNCTION_HEARTBEAT; color LED_COLOR_ID_GREEN; label debug:green:heartbeat; }; }; };關(guān)于GPIO號(hào)的計(jì)算這里說明一下。RK3568的GPIO分4組GPIO0到GPIO3每組32個(gè)引腳編號(hào)從0到31。RK_PC3表示GPIO0組的C組第3腳計(jì)算方式為group_base bank * 32 其中 bank0, C組起始偏移16, 引腳在C組內(nèi)序號(hào)3 所以 RK_PC3 0*32 16 3 19如果你用gpios gpio0 19 GPIO_ACTIVE_HIGH也是一樣的效果只是可讀性差一點(diǎn)。加入這段dts后重新編譯內(nèi)核燒錄進(jìn)去上電后這顆LED會(huì)以心跳頻率閃爍。一旦你看到心跳燈在閃說明內(nèi)核活到了能夠運(yùn)行g(shù)pio-led驅(qū)動(dòng)的階段這就是最底層邊界定位。如果系統(tǒng)卡在更早的U-Boot這顆燈不會(huì)亮如果內(nèi)核啟動(dòng)了但drivers沒起來這顆燈也不會(huì)亮。一個(gè)點(diǎn)就分隔開了三個(gè)排查區(qū)間。3.4 串口日志的接入技巧RK3568的標(biāo)準(zhǔn)調(diào)試串口是UART2默認(rèn)引腳是GPIO0_D6和GPIO0_D7。在底板設(shè)計(jì)上通常以4針或6針排針引出標(biāo)記為TX、RX、GND、VCC。接線時(shí)要特別注意交叉連接開發(fā)板的TX接USB轉(zhuǎn)串口模塊的RX開發(fā)板的RX接模塊的TXGND共地。VCC一般不用接一旦接錯(cuò)5V有可能直接燒掉核心板上的LDO。打開串口終端工具有兩種方式傳統(tǒng)方式screen /dev/ttyUSB0 1500000OpenHarmony默認(rèn)控制臺(tái)波特率是15000001.5M不是常見的115200這個(gè)一定要記住。推薦方式使用MobaXterm、PuTTY或minicom把波特率、數(shù)據(jù)位、停止位、校驗(yàn)位配置好保存為一個(gè)session下次直接雙擊連接。接入串口后當(dāng)系統(tǒng)啟動(dòng)時(shí)會(huì)看到完整的啟動(dòng)日志尾部包含init: Starting service...之類的內(nèi)容就說明用戶態(tài)服務(wù)在啟動(dòng)了。我在這個(gè)環(huán)節(jié)踩過一個(gè)坑OpenHarmony的串口輸出有時(shí)會(huì)在某個(gè)時(shí)間點(diǎn)停止但屏幕顯示系統(tǒng)還在運(yùn)行。后來發(fā)現(xiàn)是因?yàn)闆]有使用-D模式比如minicom要加-D /dev/ttyUSB0才能持續(xù)占用設(shè)備。這類小細(xì)節(jié)在高負(fù)載下會(huì)被放大盡早規(guī)避最好。3.5 用邏輯分析儀抓I2C時(shí)序接下來我以調(diào)試一個(gè)I2C觸摸屏為例展示邏輯分析儀的用法。觸摸屏芯片型號(hào)是GT911掛在I2C3上地址是0x5D或0x14。當(dāng)系統(tǒng)啟動(dòng)后觸摸屏沒有反應(yīng)先從串口日志找關(guān)鍵信息gt911_init: failed to get irq gpio 或 i2c i2c-3: sendbytes: NAK bailout.看到“NAK bailout”基本能確定I2C通路上有問題。這時(shí)候拿出邏輯分析儀接上I2C3的SCL和SDA線抓一次上電時(shí)序。抓到的波形我一般直接看三個(gè)點(diǎn)起始條件、地址讀寫位、ACK位。正常情況下SDA線上應(yīng)該出現(xiàn)01011100這樣7位地址1位讀寫位然后第9個(gè)時(shí)鐘周期檢測到ACK低電平。如果那個(gè)ACK位是高說明芯片沒有響應(yīng)可能是地址錯(cuò)了、芯片沒上電、或者引腳復(fù)用不對。我通過邏輯分析儀抓過一例發(fā)現(xiàn)I2C總線上完全沒有時(shí)鐘信號(hào)。順著引腳查原理圖發(fā)現(xiàn)SCL被另一個(gè)外設(shè)的默認(rèn)dts給復(fù)用掉了把dts里那個(gè)外設(shè)的status改成disabled后時(shí)鐘就出來了觸摸屏也正常識(shí)別。這個(gè)例子充分說明邏輯分析儀在硬件調(diào)試中的地位不可替代它能直接顯示物理總線上的電平波動(dòng)信息量比軟件I2C探測工具大得多。4. 常見問題排查與避坑技巧4.1 串口沒輸出別急著懷疑USB轉(zhuǎn)串口碰到串口完全無輸出的情況新手第一反應(yīng)是“線壞了”“模塊壞了”其實(shí)多數(shù)情況下不是。我建議按以下順序排查用萬用表量TX引腳電壓。正常待機(jī)狀態(tài)TX引腳應(yīng)該有電平通常是1.8V或3.3V如果量為0V可能板子沒上電也可能引腳被軟件配置成了輸入。確認(rèn)串口模塊的驅(qū)動(dòng)是否安裝。Linux下ls /dev/ttyUSB*Windows下看設(shè)備管理器端口項(xiàng)如果壓根沒有設(shè)備節(jié)點(diǎn)大概率是驅(qū)動(dòng)問題或模塊損壞。核對波特率。前面強(qiáng)調(diào)過1.5M如果你習(xí)慣性用了115200會(huì)打印亂碼。這算初學(xué)者最常踩的坑。檢查GND是否連接。兩個(gè)設(shè)備之間的GND必須共地否則信號(hào)參考電位不一致導(dǎo)致接收亂碼甚至無輸出。4.2 系統(tǒng)奔潰后沒有日志的解決方法OpenHarmony在用戶態(tài)進(jìn)程崩潰時(shí)默認(rèn)會(huì)生成一個(gè)cppcrash文件存放在/data/log/faultlog/faultlogger/路徑下。但在調(diào)試階段很多情況下系統(tǒng)是直接死機(jī)日志緩沖區(qū)根本沒來得及刷到存儲(chǔ)。這類問題我的建議是“提前埋點(diǎn)”在關(guān)鍵驅(qū)動(dòng)函數(shù)入口處加上打印日志配合dmesg查看。同時(shí)開啟內(nèi)核的pstore功能在死機(jī)后重啟時(shí)上一次崩潰的寄存器現(xiàn)場會(huì)保留在/sys/fs/pstore/目錄下這是我們分析內(nèi)核panic的唯一線索。如果發(fā)現(xiàn)pstore目錄是空的請檢查dts中ramoops節(jié)點(diǎn)是否配置正確reserved-memory { ramoops: ramoops110000 { compatible ramoops; reg 0x0 0x110000 0x0 0xf0000; record-size 0x20000; console-size 0x80000; ftrace-size 0x0; pmsg-size 0x0; }; };這里面reg設(shè)置在內(nèi)存中的保留地址不要和內(nèi)核其他區(qū)域沖突否則module加載時(shí)會(huì)報(bào)錯(cuò)。4.3 電腦版x86 OpenHarmony能用來調(diào)試嗎社區(qū)里越來越多人在問“電腦上能不能跑OpenHarmony”這里要區(qū)分兩個(gè)概念一個(gè)是PC當(dāng)作開發(fā)機(jī)用來編譯源碼這個(gè)我們一直在用另一個(gè)是把OpenHarmony整個(gè)系統(tǒng)跑在x86架構(gòu)的電腦上作為日常體驗(yàn)或開發(fā)調(diào)試環(huán)境。x86版OpenHarmony目前已經(jīng)可以在部分Intel/AMD平臺(tái)的電腦上啟動(dòng)到桌面主要用于應(yīng)用開發(fā)驗(yàn)證比如跑ArkTS應(yīng)用、調(diào)試分布式能力。它對內(nèi)核硬件兼容性的要求比ARM版高很多因?yàn)閤86平臺(tái)的驅(qū)動(dòng)適配還處于早期階段聲卡、有線網(wǎng)卡、WiFi這些不一定都能工作。對于做硬件調(diào)試的開發(fā)者來說我的建議是x86版適合跑**“只需要軟件?！钡膱鼍?*比如驗(yàn)證Ability生命周期、測試元服務(wù)的跨端流轉(zhuǎn)邏輯。凡是涉及到GPIO、I2C、SPI這些底層操作的還是老老實(shí)實(shí)用RK3568開發(fā)板因?yàn)閤86版這類板級驅(qū)動(dòng)支持幾乎為零你沒法在電腦上模擬GPIO高低電平自然也沒法實(shí)踐這篇文章里講的三板斧。不過x86版有一點(diǎn)對調(diào)試特別有幫助它支持在虛擬機(jī)里跑比如使用QEMU或VirtualBox安裝系統(tǒng)鏡像方便做快照回滾想怎么蹂躪系統(tǒng)都行壞了就恢復(fù)快照不心疼硬件。我的日常開發(fā)流程是x86虛擬機(jī)做應(yīng)用層的快速驗(yàn)證ARM開發(fā)板做硬件相關(guān)的真機(jī)調(diào)試兩者聯(lián)動(dòng)效率最高。4.4 調(diào)試信息拿不到的應(yīng)急手段有時(shí)候手邊沒有邏輯分析儀串口日志也看不到輸出但這不代表一籌莫展。我總結(jié)了一個(gè)“無儀表應(yīng)急三板斧”的變體通過LED序列輸出運(yùn)行狀態(tài)碼。我在驅(qū)動(dòng)里定義一個(gè)debug_led_group把四個(gè)LED配置成二進(jìn)制狀態(tài)顯示比如狀態(tài)1亮第一個(gè)燈狀態(tài)2亮第二個(gè)燈狀態(tài)3前兩個(gè)都亮。這樣系統(tǒng)卡在哪個(gè)階段肉眼就能判斷。利用HDMI幀信號(hào)判斷顯示初始化是否成功。HDMI輸出如果有信號(hào)代表顯示鏈路至少延伸到橋接芯片如果無信號(hào)問題大概率在dts的display節(jié)點(diǎn)上。觸摸屏上的ID引腳判斷主板供電狀態(tài)。很多觸摸屏有ID電阻用來區(qū)分不同接口量一下ID引腳電壓能判斷外設(shè)是否被主控正常識(shí)別。這些技巧雖然原始粗暴但在無儀表環(huán)境下往往是救命稻草。4.5 讓人頭大的“編譯通過但啟動(dòng)黑屏”問題這應(yīng)該是OpenHarmony開發(fā)里最常見的求助帖標(biāo)題了。我的經(jīng)驗(yàn)是按以下順序逐層篩查檢查項(xiàng)操作結(jié)果判定內(nèi)核日志串口搜boot關(guān)鍵字是否有內(nèi)核啟動(dòng)日志還是完全空白u(yù)boot日志串口搜U-Boot標(biāo)題U-Boot階段是否正常是否卡在DDR初始化電源指示燈目測關(guān)鍵電壓測試點(diǎn)5V/3.3V/VDD_CPU是否有正常紋波屏幕信號(hào)邏輯分析儀抓LVDS/MIPI DSI信號(hào)信號(hào)是否有周期性波動(dòng)HDMI檢測接HDMI顯示器看是否能點(diǎn)亮區(qū)分是顯示通道問題還是系統(tǒng)沒起來如果U-Boot完全沒有任何輸出優(yōu)先懷疑DDR初始化問題檢查顆粒型號(hào)與dts中DDR配置是否一致如果U-Boot有輸出但內(nèi)核沒有任何日志優(yōu)先懷疑boot.img內(nèi)核鏡像沒有正確燒錄或者bootargs里的console參數(shù)設(shè)錯(cuò)了串口號(hào)。經(jīng)常有人拿著“黑屏”問題來問最后發(fā)現(xiàn)只是HDMI線接觸不良或者顯示器分辨率不被支持這類小細(xì)節(jié)別忽視了。5. 場景延伸設(shè)備樹進(jìn)階與Ubuntu聯(lián)動(dòng)調(diào)試硬件調(diào)試三板斧真正好用在于它不僅適用于OpenHarmony原生開發(fā)放在其他系統(tǒng)里同樣順手。我在RK3568平臺(tái)上做設(shè)備樹驗(yàn)證和Ubuntu系統(tǒng)聯(lián)調(diào)時(shí)也經(jīng)常復(fù)用這套方法。5.1 借助Ubuntu系統(tǒng)快速驗(yàn)證dts改動(dòng)有一種經(jīng)典騷操作在RK3568開發(fā)板上先刷一個(gè)Ubuntu鏡像然后修改內(nèi)核dts重新編譯驗(yàn)證硬件配置正確后再切回OpenHarmony。這樣做的好處是Ubuntu的啟動(dòng)日志更完整驅(qū)動(dòng)報(bào)錯(cuò)信息更友好很多硬件配置問題能更快暴露出來。我就用這招解決過一個(gè)WiFi模組的電源控制問題。在OpenHarmony下WiFi遲遲不被內(nèi)核識(shí)別串口日志又沒有明確報(bào)錯(cuò)我切到Ubuntu鏡像運(yùn)行dmesg | grep wifi一下子就看到regulator: failed to enable vin-3v3-wifi的信息。順著這個(gè)提示去dts里檢查WiFi節(jié)點(diǎn)的vdd-supply配置發(fā)現(xiàn)引用的regulator節(jié)點(diǎn)名寫錯(cuò)了修正后WiFi在OpenHarmony下也正常工作了。這說明一個(gè)問題硬件層的問題往往不會(huì)因?yàn)槟銚Q了操作系統(tǒng)就消失而是會(huì)以不同的“馬甲”出現(xiàn)。手里有多個(gè)系統(tǒng)的鏡像等于多了一個(gè)對照實(shí)驗(yàn)環(huán)境。5.2 用openocd做片上調(diào)試的補(bǔ)充如果LED、串口、邏輯分析儀三板斧都查不出問題那就需要上更高級的手段了——片上調(diào)試器比如JTAG/SWD。RK3568支持JTAG調(diào)試接口通過USB-JTAG調(diào)試器可以連接GDB直接查看CPU寄存器、暫停/單步/斷點(diǎn)執(zhí)行。OpenHarmony使用openocd調(diào)試RK3568的方式大致如下openocd -f interface/ftdi/jtag-lock-pick_tiny.cfg \ -f board/rockchip/rk3568.cfg然后另開一個(gè)終端用gdb連接gdb-multiarch kernel/linux/linux-5.10/vmlinux (gdb) target remote :3333 (gdb) hbreak start_kernel (gdb) continue這樣就能在內(nèi)核入口處打斷點(diǎn)觀察系統(tǒng)是否進(jìn)入了start_kernel。如果斷點(diǎn)命中說明U-Boot到內(nèi)核的跳轉(zhuǎn)沒問題如果一直沒有命中那問題就在U-Boot階段。不過openocd對于RK3568的支持還在不斷完善中不同調(diào)試器芯片和配置文件的兼容性需要試。我的建議是先把三板斧玩熟90%的問題都能解決在它仨的范圍內(nèi)遇到疑難雜癥再上JTAG這樣效率最高。5.3 把調(diào)試三板斧固化成團(tuán)隊(duì)SOP最后說點(diǎn)偏管理的東西。如果你帶一個(gè)小團(tuán)隊(duì)做OpenHarmony硬件適配我建議把“三板斧”固化成一套標(biāo)準(zhǔn)操作流程要求每個(gè)成員在提問題之前必須完成三分定位“燈態(tài)”是什么哪個(gè)LED亮著哪個(gè)應(yīng)該亮卻沒亮哪個(gè)在閃爍頻率如何。“日志”里的最后一條是什么報(bào)錯(cuò)模塊名、打印的函數(shù)名、時(shí)間戳完整不完整。“波形”有沒有關(guān)鍵總線信號(hào)是否正常有沒有總線上設(shè)備的ACK以低電平回應(yīng)。我在實(shí)際項(xiàng)目推進(jìn)中發(fā)現(xiàn)這樣做能節(jié)省大量溝通成本。以前一個(gè)驅(qū)動(dòng)異常要反復(fù)遠(yuǎn)程調(diào)試、截圖、傳日志現(xiàn)在直接按SOP走一遍“燈態(tài)-日志-波形”三張圖一發(fā)問題八九不離十就定位了。而且對新人來說這套SOP降低了入門門檻不用一開始就啃冗長的datasheet也能參與板級調(diào)試工作。6. 實(shí)操心得讓三板斧真正融入你的開發(fā)節(jié)奏說了這么多最后我再掏幾句真實(shí)心得。第一句不要等到出了問題才想到插串口線。很多開發(fā)板的串口排針在底板上如果底板裝進(jìn)了外殼出問題后再接線非常痛苦。我現(xiàn)在的做法是拿到新板子第一時(shí)間就把串口、邏輯分析儀的線接好固定在調(diào)試臺(tái)一角平時(shí)正常跑業(yè)務(wù)不打擾一旦需要調(diào)試馬上就能接入。省下來的不光是接線時(shí)間還有你排查問題時(shí)焦躁的心態(tài)。第二句學(xué)會(huì)給“壞現(xiàn)象”做分類。我習(xí)慣在處理故障之前先在筆記里寫兩行字這個(gè)現(xiàn)象是“完全無反應(yīng)”還是“部分異?！比绻菬o反應(yīng)優(yōu)先排查電源和時(shí)鐘如果是部分異常比如顯示偏移、觸摸個(gè)別區(qū)域失效優(yōu)先懷疑初始化參數(shù)和配置表。分類越清晰排查路徑就越短。第三句三板斧也講究版本管理。設(shè)備樹文件、串口波特率配置、邏輯分析儀解碼模板這些都應(yīng)該跟著代碼倉庫走。每次調(diào)試完把能復(fù)用的配置保存到項(xiàng)目里用git記錄版本。時(shí)間久了你就會(huì)擁有一份專屬的調(diào)試配置庫換項(xiàng)目、換板子時(shí)直接拉出來適配效率提升非常明顯。最后再分享一個(gè)我自己常用的小技巧在dts里給不同外設(shè)的status節(jié)點(diǎn)加上注釋說明標(biāo)明這個(gè)外設(shè)的已知問題和驗(yàn)證狀態(tài)。比如i2c3 { status okay; /* 2025-05-10: GT911觸摸屏已驗(yàn)證 地址0x5D, 中斷引腳GPIO3_A2, 注意上電時(shí)序要求先給VDD后給IOVDD */ };一段注釋對于后續(xù)接手的人包括幾個(gè)月后的你自己來說比任何文檔都管用。這種習(xí)慣配合三板斧的調(diào)試流程會(huì)讓整個(gè)開發(fā)過程在不知不覺中變得更順滑。硬件調(diào)試這條路沒有捷徑但好的方法和工具確實(shí)能幫你少走很多彎路。