企业官网建设流程全解析

做OpenHarmony硬件开发，最难的不是写应用，也不是编译烧录，而是“板子不听话”。我见过不少入手RK3568的朋友，烧录成功、系统起来了、HDMI出画面了，结果外设一接就抓瞎——触摸没响应、网口不通、I2C读不到数据，这时候才发现自己手上连一套系统的排查思路都没有。所以这期想认真聊聊“硬件调试三板斧”，也就是串口、HiLog、hdc这三个工具的组合打法，以及它们背后对应OpenHarmony系统不同运行阶段的工作原理。这套内容适合刚做完Hello World、准备开始碰真实硬件的开发者，也适合从Linux/Android转过来、还没理清OpenHarmony调试体系的老手。看完之后，你会对“板子不听话”这件事不再恐惧，因为大部分问题都能按套路定位到具体某一行。

建议你已经有一块RK3568/RK3566开发板，并且能正常烧录开机。如果没有也没关系，思路是通用的，只是演示命令会以这块板子为基准。

1. 为什么调试OpenHarmony需要“三板斧”而不是一把斧

先说一个很多人误解的地方：OpenHarmony不是一个“安卓换皮”系统，也不是一个单纯的RTOS。它是一个从内核态到用户态、从分布式软总线到应用框架都重新设计的操作系统。这意味着你在排查问题时，会同时面对内核驱动、HDF驱动、系统服务、应用层代码多个层次，单靠一种工具根本覆盖不过来。

这里说的“三板斧”，对应的是系统生命周期里三个阶段各自最可靠的工具：

• 系统还没起来时，唯一能看到的输出通道是串口，这一斧负责“看见启动过程”。
• 系统起来之后，用户态和驱动态的运行日志、错误堆栈都在HiLog体系里，这一斧负责“看清运行中的细节”。
• 需要跟板子做文件传输、应用安装、进程查看、参数设置时，hdc是统一入口，这一斧负责“操作正在跑的系统”。

串口管“早期”，HiLog管“运行期”，hdc管“交互期”。三板斧不是让你每次都全部用上，而是让你在遇到问题时，先想清楚问题发生在哪个阶段，再决定动哪一把。

1.1 从软件调试思维到硬件调试思维的转变

做纯软件出身的朋友，很容易犯一个毛病：拿到一块板子，系统起不来，第一反应是“去看logcat”。但在OpenHarmony里，系统还没完全启动的时候，logcat这类东西根本不存在，应用层日志系统还没初始化，内核也尚未挂载完文件系统，那时候唯一的输出就是串口，甚至可能只有电源灯和核心板上的LED。

我见过最典型的例子：新手在u-boot阶段发现没有输出，就开始怀疑“是不是内核没编好”“是不是分区烧错”。其实u-boot起不来，大概率是串口接错、波特率不对、或者是DDR初始化失败。这种问题，你去看任何系统日志都白搭，只有回到串口，从最底层逐段确认。

所以我的经验是，先培养“分层排查”的意识，而不是“看日志”的单一习惯。每一层都对应着不同的输出通道和工具，三板斧本质上是帮你把“分层排查”落地的三个抓手。

1.2 串口、HiLog、hdc各自负责的系统层次

先拿一张表格把各自分工拆开，后面逐个细讲时会更容易对上号。

要注意的是，串口和HiLog之间还有一块“灰色地带”：内核日志dmesg。OpenHarmony的内核日志和用户态HiLog是两套体系，排查HDF驱动问题时，大概率两边都要看。这个问题后面实战章节会结合案例展开。

1.3 一句话概括三板斧的用法

如果非要用一句话总结排查思路，我的习惯是：先用串口确认系统有没有活着，再用hdc进入系统看现状，最后用HiLog盯住具体模块的运行细节。

顺序很重要。很多人一上来就开HiLog过滤，结果发现日志缓冲区里全是无关信息，浪费大量时间。正确的做法是先串口看一眼启动流程有没有完成，然后用hdc确认相关进程是否存在、设备节点是否生成，最后才让HiLog输出详细日志。有了这个大框架，后面不管碰到什么诡异问题，都不容易慌。

2. 开工之前：开发板、固件与设备树选择的几个大坑

在真正进入三板斧之前，有一个前置问题必须解决：你手上这块板子的软件基础对不对。尤其是RK3568/RK3566这类Linux内核底座的芯片，OpenHarmony代码树里往往存在好几个设备树文件，选错一个，后面所有调试都会被带偏。

2.1 为什么RK3568/RK3566是当前OpenHarmony开发的主流选择

这几年玩OpenHarmony，绕不开瑞芯微RK3568和RK3566。原因很直白：官方社区和很多开发板厂商长期维护这套平台，文档相对齐全，编译流程跑得通，外设资源也多。相比Hi3861这种只能做设备端的小模组，RK3568属于“富设备”，能跑完整系统，适合做带屏幕、带触摸、带网络的产品原型。

另一个原因是芯片本身的调试友好度。RK3568原生支持从USB烧录，串口调试也方便，不像某些平台需要专门的仿真器和授权。这意味着你只需要一根USB转串口线、一根USB数据线，就能完成从烧录到调试的全过程，学习成本低很多。

2.2 烧录固件：从编译产物到开发板的完整闭环

既然要调试，先得有能跑的固件。OpenHarmony的编译产物通常会在源码目录的out/xxx/packages/phone/images/下，里面有uboot、boot_linux、system、vendor、userdata等一堆镜像文件。烧录RK3568的常见方式有两种：

• Windows下用RKDevTool，把开发板切到Loader模式（一般是按住板上的MaskROM按键或Recovery键再上电），然后按分区表烧写。
• Linux下用upgrade_tool命令行工具，操作逻辑类似。

这里有一个很容易踩的坑：烧录时选的烧录分区必须和parameter分区表一致。很多“烧完起不来”的问题，其实不是固件坏了，而是你把system镜像烧到了vendor分区，或者漏烧了resource分区。RK3568的平台里，resource分区和boot_linux分区里有设备树和内核，漏掉哪一个都会导致启动异常。

烧录成功后，第一次开机建议不要直接拔掉串口线。OpenHarmony启动过程会输出大量信息，这些信息是不是按预期走完，是判断固件正确性的第一依据。

2.3 RK3568那么多设备树，到底怎么选

这个问题的搜索热度一直很高，也确实是新手最容易卡住的地方。我先说原理：同一颗RK3568芯片，可以被不同开发板使用，而每块开发板的引脚复用、电源时序、外设型号、屏幕接口都不一样。内核为了兼容这些板子，就在一个内核二进制里塞进多个设备树二进制（DTB），启动时由bootloader根据板子型号加载对应的那一个。

在OpenHarmony的源码里，不同的开发板设备树分布在kernel/linux/.../arch/arm64/boot/dts/rockchip/这一类的路径下。你会看到类似rk3568-evb.dts、rk3568-xxx-firmware.dts、厂商定制的rk3568开发板dts等一大堆文件。选错设备树之后，系统通常也能启动，但会出现某个外设不工作、GPIO行为怪异、触摸屏坐标错乱这类“灵异问题”。

选型的经验可以归纳成三步：

1. 确认你的开发板品牌和型号，比如是官方EVB还是第三方核心板，这个信息通常印在PCB上。
2. 去对应厂商提供的OpenHarmony适配仓库，找到和自己板子名称匹配的dts文件，而不是直接拿默认的evb配置。
3. 如果厂商没有现成配置，就以最接近的evb dts为模板，按原理图自行修改引脚、I2C地址、中断号和电源节点。

还有一个快速验证的办法：系统启动后，通过串口或hdc查看/proc/device-tree/model文件（部分版本路径是/sys/firmware/devicetree/base/model），里面会写明当前加载的是哪块板子。如果显示的名称和你的开发板型号对不上，那就是设备树选错了，趁早回头改，不要在外设调不通时白白浪费时间。

2.4 顺带回应“x86版本”：硬件调试还是得回到真实板子

很多朋友搜索过“OpenHarmony x86”或者“开源鸿蒙PC版”，想直接在电脑上装个系统来体验。这个思路本身没问题，官方其实也有x86镜像，可以拿来启动到虚拟机或实体机里，体验桌面环境、跑跑HAP应用都行。

但我要泼一盆冷水：如果你是用它来学习硬件调试，那走错方向了。x86版面向的是应用开发和系统体验，它没有也没有办法完全模拟出RK3568上的那些GPIO、I2C控制器、传感器、屏幕背光、触摸中断这些东西。你在一台x86电脑上永远学不会设备树选型，也体验不到串口看内核崩溃的紧张感。

我的建议是，x86版本可以装一个当玩具，但主战场必须放在真实开发板上。硬件调试三板斧，每一斧都要求你在真实硬件上操作，这个没有捷径。

3. 第一板斧：串口终端——万物调不通时的第一根救命稻草

串口为什么排第一？因为它是整个系统生命周期里第一个有输出的地方，也是唯一能贯穿u-boot、内核、init、系统服务全程的通道。你可以在任何阶段打断它、干预它，但它不依赖于任何上层软件，这是它被称为“第一救命稻草”的原因。

3.1 串口接线与参数：最容易被忽略的前置问题

这个建议给所有刚入坑的朋友：先把串口线弄明白，再谈其他。RK3568开发板上的调试串口通常是UART2，标准TTL电平，一共接三根线，RX、TX、GND，不需要接VCC。

接线时记住一句话：TX接RX，RX接TX。也就是开发板的发送脚接USB转串口模块的接收脚，反过来同理。另外一定把GND共地，否则会出现乱码或者完全没输出。

模块选CH340或CP2102都行，驱动装好后在设备管理器里确认端口号。Linux下通常自动识别成/dev/ttyUSB0。串口参数一般固定为115200 8N1，即波特率115200，8个数据位，无校验，1个停止位。用minicom或picocom连接的时候，命令大致是这样：

sudo picocom -b 115200 /dev/ttyUSB0

Windows下用MobaXterm、SecureCRT、Xshell都行，会话类型选Serial，配置好COM口号和波特率即可。乱码的时候别急着怀疑板子，先检查波特率有没有选对、GND有没有接、TX/RX有没有接反，这三样占乱码原因的九成。

3.2 启动日志怎么读：从Bootloader到内核再到Init

系统启动时的串口输出是有固定节奏的，掌握了节奏，就能快速判断问题发生的位置。我把整个启动过程分成三段。

第一段是Bootloader阶段。RK3568上会看到DDR初始化、打印芯片型号、加载u-boot这些信息。这段结束后会出现一个提示，让你按任意键进入u-boot命令行。如果卡在这一段，通常说明硬件基础有问题，比如DDR颗粒型号不匹配、电源时序不对、时钟配置错误。

第二段是内核阶段。u-boot加载boot_linux分区里的内核和resource分区里的设备树后，内核就开始解压自身、初始化各个子系统、按设备树一个个probe驱动。这一段的输出非常多，会看到大量[ 2.123456] xxx这种带时间戳的行。卡在这一段，说明内核在某个驱动或某个子系统上出了问题，而且往往是设备树配置和硬件对不上。

第三段是init阶段。内核启动完后，OpenHarmony的init进程开始接管，拉起各种系统服务。能看到服务名、PID等信息，也会出现一些[Init] starting service xxx这类日志，如果某个服务反复重启或启动失败，串口这里通常会有线索。

强烈建议每次开机都顺手把串口输出保存下来。Linux下用picocom时可以直接加管道存文件：

sudo picocom -b 115200 /dev/ttyUSB0 | tee boot_$(date +%Y%m%d).log

Windows下MobaXterm本身就有日志保存功能。日志文件在排查问题时非常有用，因为你往前翻屏不方便，但搜索文件的效率就高多了。

3.3 内核崩溃与驱动加载失败：串口日志里的关键关键词

串口日志排查，本质是搜关键词。我总结了几类高频问题对应的关键词，看到就能直接往那个方向去查。

一个重要提醒：看到一行Failed to probe xxx不要立刻慌了。OpenHarmony内核在启动早期会尝试探测很多设备，有些设备因为设备树里本来就配置成disabled，属于正常现象。你要区分的是“跟你手上这个外设相关的probe失败”，而不是满屏日志里任何一个error都当成问题。

3.4 串口Shell：在系统还没完全起来时介入

除了看日志，串口还提供交互式shell。在u-boot阶段可以打断启动进入命令行，在内核起来之后，如果rootfs已经挂载成功，串口也会提供一个shell登录入口。这个shell在系统服务还没完全拉起时非常有用，比如你可以检查某个设备节点在不在、某个分区挂载没有、试着手动启动某个服务看输出。

实际排查中，我经常做的一步是启动到一半、卡在某处时，用串口shell执行ls /dev或cat /proc/interrupts来确认硬件层面有没有反应。这种操作在HiLog和hdc都还没就绪时，是唯一能“伸手进去摸”的方式。

串口这一斧，熟练之后你会慢慢建立起一个条件反射：只要板子行为异常，先打开串口，看信息走到哪一行卡住。这一步能直接筛掉一半以上的低级问题。

4. 第二板斧：HiLog——OpenHarmony系统级日志的正确打开方式

系统完全启动后，你再盯着串口看就没有太大意义了，因为用户态海量日志会淹没一切，而且串口打印本身也影响性能。这时候该切到HiLog体系。

HiLog是OpenHarmony统一的日志系统，负责收集用户态应用、系统服务、HDF驱动的日志。它最核心的组件有三个：日志条目里的domain（域名）、tag（标签）、level（级别）。domain用来区分模块，tag用来进一步缩小范围，level表示严重程度，从低到高通常是DEBUG、INFO、WARN、ERROR、FATAL。

4.1 HiLog、dmesg和printf的区别

很多从单片机或Linux裸机转过来的朋友，习惯在代码里加printf。在OpenHarmony上，这种做法不是不行，但会带来两个问题：一是printf会直接打到串口上，高频率打印会拖慢整个系统；二是串口输出没有分级和过滤能力，你想看的日志混在海量输出里，根本找不过来。

内核dmesg看的是内核日志，HiLog看的是用户态日志。HDF驱动是个特殊存在，它虽然跑在内核态，但日志可以通过HDF_LOGE这类宏输出到HiLog体系里。所以在排查HDF驱动问题时，HiLog比dmesg给的信息更贴近业务逻辑。两者配合使用的场景很常见：dmesg告诉你“这个驱动probe因为资源冲突失败了”，HiLog里则能告诉你“具体是哪组配置解析出问题”。

4.2 hilog命令的过滤玩法：按domain、级别、关键字缩小范围

在实际调试前，先跑两条命令确认日志系统状态：

hilog -h hilog -b # 查看日志缓冲区信息，比如是否溢出、条目总量

-b这个参数经常被忽略，但它很重要。HiLog底层是环形缓冲，如果日志量太大，老日志会被覆盖。当你想排查一个复现比较慢的bug时，缓冲区溢出是最让人崩溃的事。

过滤日志是日常用得最多的操作。我的常规组合是：

hilog | grep -i "你的关键字"

但要注意，hilog会持续往标准输出写内容，在hdc shell里执行时，如果日志量非常大，终端会滚屏甚至卡住。更推荐的做法是先按级别和模块过滤，再配合grep，比如：

hilog -e ERROR hilog | grep -i "your_tag"

-e是用来限定级别的参数，不同版本写法略有差异，以你当前板子里hilog -h的帮助信息为准。当你已经知道模块的domain和tag时，按模块过滤是最精准的。domain是一个十六进制数，OpenHarmony的系统组件有自己预留的domain范围，三方应用和厂商模块也有对应分配区间。在应用代码里打日志时，domain是自主定义的，但要保证合法性，一般文档里会有规定范围。

4.3 日志持久化与自动抓取：别等崩溃了才想起留证据

调试时最怕的一种情况是问题复现了，但日志已经滚动没了。处理办法很简单：尽早做持久化。

在hdc shell下，可以把日志写到文件里：

hilog -w /data/log/today.log

把这条命令放到后台跑，复现问题后再去看文件，效率和体验都会好很多。还有一种做法是直接用电脑端拉取：

hdc shell "hilog" > local_hilog.log

这种方式会持续把板子上的实时日志写到电脑的文件里，适合问题出现时间不确定的长时间盯梢。

再补充一个容易忽视的点：应用崩溃时，除了HiLog里的ERROR，很多关键堆栈会出现在/data/log/faultlog/faultlogger/这类目录下，hdc拉出来看非常方便。如果HiLog里找不到，就去faultlog目录翻一翻，你会有意外收获。

4.4 在代码里给日志埋好点

调试三板斧用到后期，你会发现真正让你效率翻倍的，不是工具用得多熟练，而是代码里的日志埋点质量。

应用层使用HiLog接口时，建议按模块声明domain和tag：

constexpr unsigned int LOG_DOMAIN = 0x000001; constexpr char LOG_TAG[] = "MySample"; HiLog::Info(LOG_DOMAIN, LOG_TAG, "init success, value=%{public}d", value);

HDF驱动里则对应HDF_LOGI、HDF_LOGE等宏。埋点时要遵循一个原则：正常路径打INFO，关键决策点打DEBUG，异常分支打ERROR，入口和出口必须各有一条日志。这套习惯能保证你在接到现场问题报告时，不需要让人重新复现一遍就能猜到大概卡在哪。

日志级别选择上，我的建议是生产环境默认跑INFO，联调环境开DEBUG。全部开DEBUG会带来很大的日志压力，尤其在高频中断、大量数据处理的路径上，甚至可能改变时序导致问题消失，这种“开了调试就正常、关了调试就复现”的诡异现场，多半就是日志打太狠给系统强行降频了。

5. 第三板斧：hdc——类似ADB的全能控制台

串口解决了“系统活着吗”，HiLog解决了“模块在干什么”，hdc解决的是“我想操作这个系统”。hdc的全称是OpenHarmony Device Connector，你可以把它理解成OpenHarmony世界的ADB，提供了文件传输、shell、安装应用、参数读写等一系列能力。

5.1 hdc连接不上时的排查思路

hdc连接是新手最常见的拦路虎。不少朋友反映，板子明明开着，串口也正常，但hdc list targets结果为空。这时候我一般按下面这个顺序排查：

1. 确认USB线插的是板子的USB HOST/OTG口（调试口），而不是旁边的Type-C供电口。插错口是最常见的低级错误。
2. 确认电脑上USB驱动已经安装。Windows下如果设备管理器里能看到一个带感叹号的未知设备，那就是驱动问题。
3. 确认板子系统已经启动完成。hdc服务是在用户态起来的，系统没完全启动时hdc连不上是正常的。
4. 检查不同版本hdc工具的兼容性。OpenHarmony不同版本的hdc协议可能有差异，建议用和固件相同版本或更新版本的hdc工具。

hdc连上后，第一件事永远是执行：

hdc list targets

看到设备序列号后，再做下一步。我见过太多人连设备都没确认就一顿操作，最后发现一直在往电脑本机执行命令。

5.2 hdc常用命令速查表

下面这些命令是我日常调试中使用频率最高的，整理成表方便检索。

其中hdc file recv我把它的优先级放到很高。调试中经常需要把板子上的崩溃日志、截图、数据库文件拉回电脑分析，手头没有hdc的话，等待你的将是漫长的串口复制粘贴。

5.3 三板斧组合出击：建立一套固定的排查顺序

工具都熟了之后，关键的进步在于把它们组合成自己的排查流程。我现在处理一个“系统起来了但某功能异常”的问题时，步骤固定如下：

1. 串口看内核日志里有没有相关驱动的probe失败，用dmesg或直接看串口输出。
2. hdc shell进入系统，检查对应进程是否在跑，比如ps -ef | grep xxx。
3. 检查设备节点是否生成，比如ls /dev/input/或cat /proc/bus/input/devices。
4. hdc shell后启动hilog过滤，盯住出问题模块的domain/tag。
5. 拉取相关日志文件，回到电脑端仔细分析。

这套顺序的好处是每一层都能快速给“是不是这一层的问题”一个答案，排除掉一层再往下一层走，不会东一榔头西一棒子。

5.4 hdc shell和串口shell的选择

有些朋友会问，hdc shell和串口shell看起来都能执行命令，到底有什么区别？

区别很大。串口shell是在内核和init层面提供的，它不依赖USB，也不依赖用户态服务，更底层。板子网络协议栈挂了、USB服务挂了、甚至桌面服务起不来时，串口还在。

hdc shell则是在系统用户态服务正常的前提下工作，它能调用的命令更完整，也能和应用框架正常交互。但hdc依赖USB或者网络，如果问题恰恰出在USB驱动或网络协议栈上，hdc就废了。

所以紧急恢复性操作、硬件级排查用串口；日常开发、日志拉取、应用调试用hdc。两者不能互相替代，这也是为什么我说它是“第三板斧”，而不是“替代前两板斧的银弹”。

6. 实战复盘：一次触摸屏驱动失灵的完整排查链路

理论讲再多，不如完整复盘一个真实问题。下面这个案例不是虚构，而是我这段时间在RK3568开发板上反复遇到的一个典型问题：系统正常开机，HDMI画面也正常，但触摸屏无论怎么点都没反应。

6.1 现象描述与初始判断

板子启动完全正常，进入桌面后鼠标可以用（USB鼠标），但触摸屏点按无反应。调换触摸屏接线、换屏幕排线，问题依旧。这时已经能排除触摸屏本身物理损坏，怀疑方向收窄到两个：触摸IC的I2C通信没建立，或者HDF驱动没有正确匹配到这个触摸芯片。

6.2 第一板斧：串口日志确认驱动探测状态

先在串口终端观察启动日志。触摸驱动在OpenHarmony中通常跟随I2C控制器初始化，所以我在内核日志里搜索了I2C相关信息：

[ 3.123456] rk3x-i2c ff3c0000.i2c: Initialized RK3xxx I2C bus [ 3.135678] 1-0038: probe with driver ft5x46 (acpi/ofi) with device ID [ 3.135990] 1-0038: probe failed, err -22

关键信息出来了：I2C总线上1号口，地址0x38，驱动ft5x46尝试探测，结果返回-22，也就是无效参数。这就说明I2C总线本身是通的，触摸IC地址也有响应，问题出在probe阶段。

很多人在这一步会直接去翻驱动源码，但我还不想这么快下结论。因为-22这个错误在I2C设备probe中经常和设备树里的参数配置有关，比如中断号、复位脚、坐标分辨率这些，任何一个字段不合法都会导致probe失败。我决定继续用另外两板斧交叉验证。

6.3 第二板斧：hdc进入系统核对设备节点

系统起来后，我用hdc进入系统，先确认内核态对这个触摸屏做了什么记录：

hdc shell cat /proc/bus/input/devices

发现没有任何输入类设备登记。再查一下设备树实际生效的内容：

cat /proc/device-tree/model

显示是RK3568 EVB的型号，和我手里的测试板一致。接着检查I2C设备目录下有没有对应节点：

ls /sys/bus/i2c/devices/

能看到1-0038目录，说明设备树里I2C节点是存在的，地址解析也正确。问题继续聚焦到“为什么probe失败”。

6.4 第三板斧：HiLog盯住HDF触摸驱动的报错

接下来切换到HiLog，按输入模块的关键字过滤日志：

hilog | grep -i touch hilog | grep -i ft5x46

日志里发现了一段HDF层的错误信息，大意是解析设备树中断号时发现配置的GPIO中断号超出了可接受范围。这下终于找到了坑：硬件上触摸屏的触摸中断引脚接到了某个GPIO，但设备树里写的GPIO编号和原理图不一致，甚至和芯片的GPIO bank编号规则对不上，导致驱动在解析阶段直接判定参数非法。

原因锁定后，修改设备树中触摸节点里的中断GPIO注解，重新编译resource分区，只烧录resource和boot_linux，再开机。触摸即刻生效，HiLog里也能看到驱动正常上报触摸事件的日志了。

6.5 这个案例带给我的三点启发

第一，没有第一板斧（串口）的内核日志，我会怀疑电源、屏线、芯片坏掉，走很远弯路。但日志直接把我按在I2C和驱动层。

第二，没有第二板斧（hdc）确认系统内设备节点，我不敢断定是不是hdc连不上导致的“假死”。但设备节点存在，让我确信I2C通信是通的。

第三，没有第三板斧（HiLog）里的HDF错误，我就不知道问题出在设备树的中断号配置上。串口只告诉我probe失败，但真正告诉你哪里失败的是HiLog。

三个工具在这个案例里的角色就像接力棒，各自跑一段，最后交叉定位到一行配置。这也正是“三板斧”的完整价值。

7. 三板斧之外的进阶补充：什么时候需要第四、第五把工具

绝大多数OpenHarmony硬件问题，三板斧足够解决八到九成。但剩下那一两成疑难杂症，确实还需要更专业的工具。

性能类问题建议上HiTrace和hyperf。HiTrace是分布式调用链跟踪，适合排查跨设备或跨服务调用耗时。hyperf是性能剖析工具，可以采样CPU热点、分析内存占用，比单靠top和hilog直观得多。

如果你需要直接操作寄存器看硬件状态，可以用devmem这一类工具直接读物理地址：

hdc shell devmem 0xff3c0000

这个操作可以在不写驱动的情况下确认某个寄存器当前的配置值，排查硬件相关问题时偶尔能救命。

再往后就是JTAG/SWD仿真器级别。当系统彻底崩溃、连串口都没有输出、或者需要单步跟踪内核代码时，仿真器是最强武器，但设备成本和上手门槛也高。作为普通开发者，我通常不建议一上来就上仿真器，因为效率未必比三板斧高。

还有一类容易被忽视的“工具”是构建脚本本身。比如当你修改了设备树，却没有实际编进烧录镜像，那往往会在调了好几小时后才发现问题在“你改的和跑的不是同一份代码”。建议每个修改动作都通过脚本固化，编译产物加上时间和commit号，避免“薛定谔的固件”。

8. 写在最后：三板斧真正练的是“不慌”的本事

玩OpenHarmony这段时间，我越来越觉得，硬件调试学的不是某一个工具，而是一整套“不慌”的排查习惯。串口、HiLog、hdc这三个东西单独拿出来都不复杂，但把它们按照“启动期、运行期、交互期”串成方法论，面对任何一块不熟悉的板子时，你都能踩着一条清晰的路把问题从模糊逼到具体，再从具体定位到一行代码或一根线。

最后分享一个土办法：拿到新板子后，最先做的事情不是跑demo，而是把串口、hdc、HiLog三样东西的连通性全部验证一遍，然后把串口号、hdc工具路径、常用命令抄在便利贴上贴到办公位。这套准备工作做一次，后面能省出几十个小时的排查时间——因为我踩过太多次“手里的板子连不上调试口”的坑了。