OpenHarmony硬件调试三板斧：串口日志、ADB与设备树实战指南-平芜编程栈

1. 先讲明白：为什么OpenHarmony调试绕不开“三板斧”

OpenHarmony这两年热度一直没降过，尤其是开源鸿蒙系统搭建相关的讨论，从开发板一路蔓延到了PC和x86设备上。我身边不少朋友是从嵌入式Linux转过来的，也有做Android BSP的老手，大家上手OpenHarmony时第一个共同感受就是：生态确实是新的，文档也是真的少。好多问题网上搜不到现成答案，只能靠日志、靠工具、靠对着源码硬啃。

这里就引出了硬件调试的“三板斧”——串口日志、ADB调试、设备树（DTS）排查。很多人觉得这仨是老生常谈，没什么可讲的。但我带过好几个项目团队，看到新人最容易卡住的点恰恰就在这三样基本功上。比如RK3568开发板上一堆设备树文件到底该选哪个，这个问题在社区里几乎每周都有人问；还有板子起不来、Kernel log一片空白、ADB死活连不上，最后排查半天发现是串口工具配置错了，或者驱动没装对。

这篇文章就是要把这三板斧从头到尾捋清楚。我不打算讲太多玄乎的理论，重点是你拿到一块OpenHarmony开发板之后，从头到尾应该怎么一步步做硬件调试，遇到常见问题怎么定位，设备树选型的坑怎么避。不管你是学生、嵌入式工程师、还是想转行做系统开发的新人，这套流程你都用得上。

顺便提一句，现在OpenHarmony已经有不少x86版本的镜像在社区里流传，有人在普通PC上跑，也有人在搞openharmony pc版官网下载的镜像自己折腾。这意味着硬件调试的场景从开发板扩展到了普通电脑，调试三板斧依然适用，只是细节上有些变化，这些我也会在后面提到。

2. 三板斧的开胃菜：先把开发环境和硬件连接搞清楚

2.1 工欲善其事：基础工具准备清单

很多人拿到开发板第一步就是插电、连串口、开烧录工具，一顿操作猛如虎，一看启动日志全乱码。问题大多出在基础工具没配好。我建议先花半小时把下面这些东西准备好，后面能省好几个小时。

先说硬件层面的工具：

开发板一块，最常见的RK3566/RK3568系列，比如润和、DAYU200、鸿湖等等；
USB转串口模块一个，推荐CP2102或者CH340芯片的，驱动支持好，不容易出幺蛾子；
USB Type-C数据线至少两根，一根用于供电，一根用于ADB调试或者烧录，注意有些开发板的Type-C口并不支持OTG，要提前看原理图或说明书；
12V电源适配器（有些板子需要）、网线一根（用于NFS挂载或者远程登录）、HDMI线（如果板子有显示输出）。

软件层面：

Ubuntu 20.04或22.04的编译环境，或者Windows下用虚拟机也行，不过性能差点；
HiLog和hdc工具，这是OpenHarmony自带的日志和调试工具，对应Android的logcat和adb；
串口终端工具，MobaXterm、SecureCRT、minicom都行，我个人习惯用MobaXterm，串口和SSH都能管；
RKDevTool或hiTools烧录工具，取决于你板子的SoC；
ohos SDK和对应的镜像文件，这个从官方Gitee仓库或者你板子厂商提供的发布包里面拿。

这些搞齐了，才有资格谈后面的调试。

2.2 连线与串口终端配置的细节

连接顺序上，我个人的经验是：先接线，后上电，最后开终端。具体来说：

把USB转串口的TXD接到开发板的RXD，RXD接到开发板的TXD，GND接GND。这里别接反了，接反了大概率没输出；
用Type-C线把开发板的ADB口连到电脑，这个口一般会在丝印上标明“ADB”或“OTG”；
插上电源适配器，先不要急着上电；
电脑上打开设备管理器，确认串口编号（COM口）和设备是否被正确识别；
打开MobaXterm，新建串口会话，波特率设成115200，数据位8，停止位1，无校验，无流控；
上电，这时候串口终端里应该能看到uboot阶段的启动日志了。

一个需要注意的细节是，波特率必须是115200，有些板卡在uboot阶段和kernel阶段使用不同波特率，但OpenHarmony主流平台基本都统一用115200，如果你发现日志突然变成乱码或者消失了，先检查是不是波特率被改了，尤其是你之前用这块板子调过其他系统的话。

注意：串口终端没日志输出时，90%的情况是接线错误、COM口选错、板子没上电，这三条排查完基本就能解决。不要一上来就怀疑镜像有问题。

3. 第一板斧：串口日志——硬件调试的“眼睛”和“耳朵”

3.1 为什么串口日志是核心中的核心

做OpenHarmony开发，串口日志的重要性怎么强调都不过分。OpenHarmony的运行分为几个阶段：Uboot引导、Kernel启动、Init进程启动、Foundation和系统服务启动、最后到应用层。这一整个过程中，任何一环出了问题，最直接的反馈就是串口日志。

我打个比方：串口日志就像飞机上的黑匣子，虽然它本身不参与飞行控制，但一旦出了事故，它记录的信息是你还原事故现场的唯一依据。OpenHarmony的日志系统从内核态到用户态都有对应的输出渠道，只要你能完整拿到一段启动过程的日志，基本就能判断当前卡在哪个阶段。

对于Uboot阶段，日志能告诉你内存初始化是否成功、有没有找到启动介质、设备树有没有加载；进入Kernel阶段后，日志会输出设备驱动的注册过程、文件系统的挂载、系统的初始化服务启动情况；到了用户态，OpenHarmony的hilog会接管日志输出，包括各个系统服务和应用的运行状态。

3.2 OpenHarmony日志系统的基本原理

OpenHarmony的日志体系比传统嵌入式Linux要复杂一些，它分了好几层：

Kernel日志：通过dmesg查看，主要对应内核驱动的输出；
hilog日志：系统服务和应用层的日志，类似于Android的logcat，是日常开发中最常看的；
崩溃日志：进程崩溃时的栈信息，一般在/data/log/faultlog/temp/目录下；
事件日志：一些系统关键事件（开机、关机、OTA升级等）的记录。

实际调试中，我一般先用串口终端观察启动阶段的输出，等系统起来之后再用hdc shell进入设备，用hilog命令继续抓用户态日志。

hilog的基本用法其实很简单：

# 查看所有日志 hilog # 按关键字过滤 hilog | grep -i "error" # 只输出某个标签的日志 hilog -T 标签名 # 带时间戳输出 hilog -t

有一个经验要分享给大家：OpenHarmony的hilog缓冲区默认不算大，如果系统跑了一段时间再去看，早期的日志可能已经被冲掉了。所以如果你的问题是偶现的，最好提前用hilog -r把日志重定向到文件里持续记录，否则等你想起来去查的时候可能已经晚了。

3.3 串口日志的实际排查思路：一个启动卡死的案例

举一个我实际遇到过的例子。有次调试RK3568平台的OpenHarmony，板子上电后串口输出到[ERROR:DRM] failed to get display pipeline然后就卡死了，系统一直起不来。第一眼看到错误以为是显示驱动的问题，后来仔细翻完整日志才发现，问题根本不在显示，而是某个电源域没有正确初始化。

这就是串口日志调试的一个核心方法论：不要只看报错那一行，要把前面几十行甚至几百行都看一遍。因为很多报错只是“果”，“因”在日志的更早位置。我当时是把完整日志保存下来，从开头的硬件初始化开始逐行看，发现[ERR] failed to enable power domain这个关键信息，然后顺着去查设备树中电源节点的配置，最后锁定是一个GPIO的regulator配置错了，修正之后就正常启动了。

所以，遇到启动异常，第一件事永远是保存完整的串口日志，而不是急着改代码。

4. 第二板斧：ADB与HDC工具链——进了系统之后的调试利器

4.1 HDC和ADB到底什么关系

如果你做过Android开发，对ADB肯定很熟悉。OpenHarmony对应的调试工具不叫ADB，而是叫HDC（HarmonyOS Device Connector）。两者功能类似，但实现和命令语法上有些差异。

对应关系大致如下：

功能	ADB命令	HDC命令
设备连接列表	adb devices	hdc list targets
进入shell	adb shell	hdc shell
推送文件	adb push	hdc file send
拉取文件	adb pull	hdc file recv
安装应用	adb install	hdc install
抓取日志	adb logcat	hilog

新手最容易犯的错，就是把hdc命令和adb命令混用。实际上OpenHarmony会自带hdc工具，一般在SDK的toolchains目录下，建议把路径加到系统环境变量里，用起来方便。

4.2 HDC工具链的安装与配置

HDC工具的获取渠道有几个：官方OpenHarmony SDK里自带；板卡厂商的发布包里通常也有；如果你是自己从源码编译的，编译输出目录里也会有。

安装配置步骤：

解压SDK，找到toolchains目录下的hdc工具；
Linux下执行chmod +x hdc，然后移动到/usr/local/bin/；
Windows下直接把hdc.exe所在的目录加到Path环境变量；
使用hdc -v验证版本，能输出版本号就说明配置好了。

连接设备后，用hdc list targets查看是否识别到设备。如果列表是空的，可能原因有：

开发板的ADB/HDC调试开关没打开（有些板子在设置里需要手动开启开发者模式）；
USB线不支持数据传输；
驱动没安装好，Windows下尤其常见；
hdc server没启动，试试hdc kill再hdc start。

4.3 我用HDC做过的那些高频调试操作

日常开发中，我反复用到的HDC操作集中在下面几个场景：

场景一：从设备里拉取日志和崩溃文件

# 进入shell hdc shell # 查看崩溃日志目录 ls /data/log/faultlog/temp/ # 把崩溃日志拉到本地 hdc file recv /data/log/faultlog/temp/xxx.crdump ./crash_log/

场景二：给设备安装/卸载hap包

# 安装应用 hdc install entry.hap # 卸载应用 hdc uninstall com.example.myapp

场景三：修改设备文件权限

hdc shell mount -o remount,rw / chmod 777 /data/local/tmp/

有一个实用小技巧：用hdc shell进入设备后，很多底层调试操作都需要root权限。OpenHarmony默认有些用户态进程是受限的，你可以先执行hilog看日志，如果提示权限不足，再试su切换。部分开发板的root白名单是可以配置的，这块在标准版本里开放程度不同，需要根据你手上的具体版本灵活处理。

4.4 ADB连不上的问题排查清单

ADB/HDC连接问题在开发中最让人抓狂，因为原因实在太多了，而且往往不是代码问题。我总结了一张排查清单，按顺序检查，基本能覆盖90%的情况：

排查点	如何操作
驱动	Windows下查看设备管理器，有没有“HDC Device”或“Android Device”
USB接口	可能是接触不良或线材问题，换条线、换个口试试
开发者模式	设备端查看“关于本机”，连点版本号开启，打开USB调试
服务状态	`hdc kill`再`hdc start`，重启hdc服务
端口占用	检查是否有其他hdc实例，杀掉后重来
目标设备选择	`hdc list targets`，如果有多个设备，`hdc tconn ip:port`指定连接
网络连接	用`hdc tconn 192.168.x.x:5555`走Wi-Fi调试，注意设备和PC要在同一网段

我遇到过最离谱的一次，是开发板的USB口接触不良导致hdc时通时断。当时我一度以为是系统崩溃，折腾了半天，最后换了一根短一点的Type-C线就解决了。这类硬件问题往往比软件问题更难排查，所以建议手边常备几根质量可靠的数据线。

5. 第三板斧：设备树（DTS）排查——从“选哪个文件”到“怎么改节点”

5.1 RK3568开发板设备树文件为什么那么多，到底怎么选

这是OpenHarmony社区里出现频率极高的问题：我用的RK3568开发板，源码的kernel/arch/arm64/boot/dts/rockchip/目录下有一堆dts文件，选错了系统根本起不来，到底应该选哪一个？

先说结论：设备树文件的选择，取决于你开发板的具体型号。RK3568平台是一个SoC平台，但不同厂商做的开发板外设、内存、显示接口、电源方案都不一样，所以每个板子都会有一个独立的dts文件。

以常见的几个为例：

rk3568-evb1-v10.dts：瑞芯微官方的EVB评估板，适合参考但不一定能直接跑你的板子；
rk3568-dayu200.dts：DAYU200开发板，OpenHarmony官方适配的主力板卡之一；
rk3568-nanopc-t6.dts：友善之臂的NanoPC-T6，外设配置完全不同；
rk3568-rock-3a.dts：Radxa Rock 3A，用的也不是标准的EVB电路。

所以，如果你用的是某家厂商的板子，最靠谱的做法是直接问厂商要对应的dts和config。如果是自己画的板子，那就得基于官方EVB的dts改，把不匹配的外设和电源节点全部修正。

选择方法其实不复杂：编译内核时，Makefile会根据CONFIG_ROCKCHIP_RK3568和CONFIG_DEVICE_TREE里的配置自动选择dts。你可以在kernel的arch/arm64/boot/dts/rockchip/Makefile里看到一行：

dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-dayu200.dtb

如果你想让某一块板子的dtb被编译出来，就需要把对应文件名加进去，然后在编译脚本或烧录配置中指定这个dtb。这是最直接的选型逻辑，跟你在menuconfig里勾选什么没有太大关系，关键是编译产物里有没有你想要的dtb。

5.2 设备树基本结构：先看懂再动手改

很多新手拿到dts文件，看到里面几百行的节点直接懵了。其实设备树的结构并不复杂，就是一个描述硬件信息的树状结构。核心组成是三部分：

根节点：/，整个设备树的起点；
节点（node）：每一个硬件设备对应一个节点，用{}包含起来；
属性（property）：描述节点的各种参数，比如compatible、reg、status、clocks等。

举个例子，打开rk3568-evb.dtsi，你会看到类似这样的内容：

&i2c0 { status = "okay"; clock-frequency = <400000>; hym8563: hym8563@51 { compatible = "haoyu,hym8563"; reg = <0x51>; interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; #clock-cells = <0>; clock-frequency = <32768>; }; };

这里&i2c0是引用之前定义过的i2c0节点，后面的status = "okay"表示使能这个I2C控制器，hym8563@51是一个RTC芯片的子节点，它的I2C地址是0x51。

改设备树时最常做的操作就是：打开某个外设节点（status从"disabled"改成"okay"）、修改某个引脚配置（pinctrl）、调整内存大小、修改串口别名指向等等。

5.3 设备树调试中常用的三板斧技巧

设备树本身的调试方法，其实也有一套类似“三板斧”的路径：

第一招：确认dtb有没有被加载

在串口日志里搜索FDT或Device Tree相关的关键字，确认uboot传给kernel的dtb地址和大小是否符合预期。如果kernel启动后在OF: fdt:Machine model处打印的板型名称和你预想不一致，说明uboot加载了错误的dtb。

第二招：查看设备节点的状态

进入系统后，在shell里查看节点是否被正确解析：

# 查看某个设备节点是否存在 ls /proc/device-tree/ # 查看节点状态 cat /proc/device-tree/soc/i2c0/status cat /proc/device-tree/soc/i2c0/clock-frequency

如果节点存在但status不是okay，或者reg属性不对，那就是dts没改对或没用对。

第三招：根据错误日志反推节点

比如日志里出现i2c0: error，那就是i2c0节点或对应驱动出了问题。这时候去dts里检查i2c0的clock、pinctrl、status配置，再配合外围硬件测量，基本能定位。

5.4 设备树选错会出现的典型症状

选错设备树，最常见的表现是：

屏幕不亮但系统起来了（显示节点没配置或配置错误）；
串口没有输出（console串口引脚不对）；
网卡不工作（以太网PHY的reg或reset GPIO不对）；
触摸屏、Wi-Fi模组无法识别（外设通过SDIO/I2C/USB挂载，DTS描述不对时驱动probe失败）；
内存识别只有一半（内存通道配置错误）。

举个例子，如果同一块板子你烧了DAYU200的镜像，开机后屏幕没反应、触摸也不动，那么大概率就是设备树和外设都不匹配。这种情况下先确认你手上板子的型号，再看厂商有没有提供对应的适配镜像，不要拿别的板子的镜像硬烧。

6. 组合拳：一个真实的RK3568调试全过程复盘

6.1 问题现象与初步判断

前面把三板斧拆开讲了，这节我复盘一个完整的调试过程，看完你就知道这三样东西怎么组合着用了。

当时手上有一块RK3568的板子，新打样回来，第一次上电刷OpenHarmony标准系统。烧录过程很顺利，没有报错，但是复位后串口一片寂静，什么日志都没有。

这是最让人头疼的故障之一——无日志、无显示、无声无息，感觉整个板子像死了一样。我当时的排查路径是层层递进的。

6.2 第一步：检查供电与最小系统

没有日志不代表板子完全没工作。先用万用表量了核心电压，确认各路供电正常。然后查了时钟信号，用示波器看了24MHz晶振有没有起振。供电、时钟没问题后，基本能排除硬件最基础的故障。

接着重点查复位信号。RK3568的复位引脚是低有效，用示波器抓上电瞬间的波形，确认复位脚确实有释放动作，而且时间在规范范围内。

这一轮排查下来，硬件最小系统正常，于是把焦点转向软件和启动介质。

6.3 第二步：串口工具与启动介质排查

然后怀疑是不是串口配置不对。检查了MobaXterm的波特率设置，也重新看了接线，都正常。然后问题又回到了“板子到底有没有在跑”这个核心上。

用手摸了一下主控芯片，有轻微发热，说明芯片肯定在上电工作。又试了把HDMI接到显示器上，看看有没有画面输出，结果屏幕也是黑的。

这时候我觉得可能是启动介质的问题。RK3568可以从eMMC、SD卡、SPI NOR等多个介质启动。板子默认的启动顺序和烧录时选择的启动介质如果不匹配，就会导致uboot代码根本没被执行。

我查看了板子的拨码开关和启动配置电阻，确认默认是从eMMC启动，烧录时选的也是eMMC，这个环节没问题。

6.4 第三步：换用SD卡启动来交叉验证

为了确认是eMMC里的镜像问题，还是整个系统都没起来，我换了一种思路：制作了一张SD卡启动盘，把编译好的uboot和kernel放到SD卡里，然后改启动介质为SD卡优先。

结果上电后串口依然没有输出。这时候我意识到问题可能比想象的更底层，于是用RKDevTool尝试进入MaskRom模式，重新初始化并烧录。在MaskRom模式下，串口依然没反应，但工具能识别到设备，说明SoC本身工作正常。

后来想到一个可能性：很久之前这块板子被我刷过其他平台的固件，是不是uboot阶段的DDR初始化参数不匹配？这种问题很隐蔽，因为RK的DDR初始化是由uboot里的DDR bin完成的，如果DDR参数和板子实际的内存颗粒不匹配，就可能在最早期就死掉，连时钟都不跑。

6.5 第四步：烧录厂商提供的原厂固件验证

我翻出了厂商当时随板子给的一个基础固件，重新烧录。上电后，熟悉的串口日志终于出来了。虽然还是没进到Linux，但至少uboot跑起来了，这验证了DDR配置、硬件通路都没问题。

再烧回自编译的镜像，问题重现。于是怀疑是编译配置的问题，特别是设备树和config。

我重新梳理了编译流程，发现了一个非常隐蔽的错误：我在编译时，默认的dts被改成了某个非标准文件，生成的dtb和板子硬件完全不匹配。这在启动阶段往往表现为串口无输出，因为console串口本身也是由设备树来描述的，如果你的dts里把uart2的引脚改错了，内核自然找不到console。

我换回了与硬件匹配的dts，重新编译烧录，系统终于正常启动。

6.6 复盘总结：这个案例教会了我们什么

这个案例最有价值的地方在于，它展示了硬件调试三板斧不是孤立的三个工具，而是一个组合排查闭环：

串口日志帮助你判断系统到底跑到了哪一步；
ADB/HDC帮你进入系统内部做进一步确认；
设备树排查帮你定位硬件描述和硬件实际是否匹配。

如果你碰到的问题是无日志、无启动的情况，按照这个路径走：先确认硬件最小系统，再用MaskRom验证SoC，再换一个已知正常的固件做交叉验证，最后回头检查自己的编译配置和设备树选择。层层排除，总能找到问题所在。

7. 从开发板到PC：OpenHarmony x86调试有哪些不同

7.1 x86版OpenHarmony的调试现状

社区里现在有不少人在折腾OpenHarmony的x86版本，常见的关键词是开源鸿蒙x86iso下载、开源鸿蒙x86版本、电脑版x86 openharmony。OpenHarmony官方其实一直在推进对x86_64架构的支持，社区也涌现了一些可以直接在普通PC上运行的镜像。

如果你拿到了一个x86的OpenHarmony镜像，打算在物理机或虚拟机上调试，三板斧的适用性有所不同：

串口日志：普通PC通常没有现成的调试串口，更多是依赖GRUB启动菜单里的日志输出，或者journald记录的系统日志；
ADB/HDC：x86版本照样支持HDC，通常通过网口或USB连接调试；
设备树：x86平台基本不依赖设备树，使用的是ACPI和PCIe枚举的方式，这一点和ARM平台有本质区别。

所以，x86平台的调试，几板斧的用法要发生一些变化。

7.2 x86版本调试的基本操作

在x86平台上，早期启动阶段的日志不再通过UART输出，而是直接输出到显示器的GRUB界面或者串口（如果主板支持COM口）。多数情况下，你需要在GRUB启动菜单里按e编辑内核启动参数，把console=tty0改成console=ttyS0,115200，并且加上earlycon=uart,io,0x3f8之类的参数，才能把内核日志输出到COM口。

如果你没有串口条件，也可以等系统起来后直接开终端窗口，用dmesg查看内核日志，用systemctl status查看服务状态。这和ARM平台相比，反而不需要额外的串口线了。

HDC工具在x86上用法完全一样，只不过连接方式更多样。你可以在系统设置里找到“开发者选项”，打开USB调试，或者直接用hdc tconn 本机IP:端口连接本机，甚至可以通过网口连接局域网内的另一台x86设备。

7.3 x86版本调试的典型坑

我自己也折腾过x86版本的OpenHarmony，最大的坑有几个：

镜像引导方式：有些镜像只支持UEFI启动，有些只支持Legacy BIOS，搞反了会卡在GRUB界面或者直接黑屏；
驱动缺失：PC外设型号五花八门，集成的驱动不一定覆盖所有硬件。如果网卡、显卡无法识别，你甚至进不了图形界面，只能靠命令行摸索；
分区表格式：有些镜像对分区表格式有严格要求，GPT和MBR混用可能导致无法启动。

遇到了也不要慌，三板斧的思路可以直接平移过来——用启动日志判断引导是否正常，用HDC进入系统确认驱动加载情况，用ACPI表或者内核模块的方式补充缺失的设备描述。

8. 避坑清单：我把这些年踩过的坑一次性说给你

最后分享一些散装的实操心得，不一定成体系，但每一条都是真实踩过的坑换来的经验。

关于串口工具：

不要同时开两个串口工具连接同一个端口，会互相抢占导致无法收发；
Windows下CH340驱动装好后，一定要重新插拔USB线才能生效；
日志刷屏速度很快，建议一开始就勾选“保存日志到文件”的选项，别等出问题了再后悔没存；
串口日志里如果出现乱码，八成是波特率不对或电平不匹配，先查这两个，不要怀疑芯片坏了。

关于HDC/ADB：

hdc server偶尔会僵死，你敲任何命令都提示失败，这时候hdc kill再重来，能解决大多数问题；
如果设备列表里有多个目标，一定记得用hdc tconn ip:port指定要操作的设备，不然命令可能发到错误的机器上；
不要在设备电量过低时做烧录或系统级操作，极易造成分区数据损坏，看起来是软件问题，其实是硬件断电导致。

关于设备树：

改完dts后，如果系统没变化，优先怀疑dtb有没有被重新编译并烧进板子，而不是怀疑dts改错了；
看到status = "disabled"的节点不代表硬件不存在，只是说驱动不使能。排查外设问题时，要同时确认节点里的pinctrl引脚有没有被其他节点占用；
RK3568的pinctrl配置很容出错，一个引脚被多个功能复用的情况很常见，最好对照原理图逐个核对；
如果在设备树里改了reg属性，务必确认对应的reg和中断号没有超出SoC支持范围，否则会引发莫名其妙的外部中断。

关于通用调试心态：

硬件调试最忌讳的就是“差不多、应该没问题”这种心态，每一个变量都要有据可查；
每次只改一个参数、一个文件，改完立刻验证，出问题也好回溯，不要一次改五六个地方然后盲目试错；
强烈建议建立自己的调试笔记，哪怕是简单的几行记录：今天改了哪个dts、烧了哪个镜像、结果如何。三个月后你再回来翻，会发现这本笔记比任何文档都值钱。

我自己在实际操作中还有一个习惯：每块板子第一次拿到手，我会先烧一个官方固件，完整保存一份正常启动的串口日志，作为“黄金日志”留存下来。后续不管调试什么功能，第一件事就是拿当前日志和黄金日志对比，哪里开始分叉，哪里就是问题的切入点。这个习惯帮我节省了大量时间，也建议你试试。

OpenHarmony硬件调试三板斧：串口日志、ADB与设备树实战指南