1. 为什么Rockchip平台的调试总让人又爱又恨搞嵌入式的人大多有个共识瑞芯微Rockchip的芯片性价比确实能打从早期的RK3288、RK3399到近几年的RK3568、RK3588在平板、盒子、工控板、边缘计算设备里到处都能见到它的身影。但真正上手调试的时候很多人第一反应是资料怎么这么散。官方文档有但往往藏在SDK压缩包的某个角落工具链有但版本对不上就各种报错日志能看但关键信息淹没在几千行输出里。这篇内容就是把我这些年折腾Rockchip平台积累下来的调试手段做一次系统梳理。所谓调试手段不只是看log这么简单它涵盖了从串口交互、内核日志分级、设备树排查、寄存器读写、性能剖析到固件烧录验证的一整套方法论。适合正在用RK系列芯片做产品开发的嵌入式工程师、驱动开发者也适合刚接触这个平台、被各种工具搞得有点懵的新手。我不会只告诉你用这个命令而是尽量把每个手段背后的逻辑、适用场景、以及我踩过的坑都讲清楚让你在遇到问题时能自己判断该掏出哪把螺丝刀。Rockchip的调试体系其实分了好几层最底层是BootROM和Loader阶段的串口输出往上是U-Boot和Kernel的日志系统再往上是用户空间的调试接口最外层还有PC端的烧录和抓取工具。很多人调试效率低根本原因是没有建立这个分层概念遇到问题就一通乱试。下面我按这个层次逐层拆解把每一层最实用的手段和参数配置讲透。2. 调试体系的分层认知与整体思路2.1 从BootROM到用户空间的分层模型Rockchip芯片上电后的启动链路大致是这样的BootROM芯片内部固化代码→ LoaderMiniLoader负责DRAM初始化和搬运→ U-Boot或LK→ Kernel → Rootfs。每一层都有独立的日志输出通道但默认情况下它们共用同一个调试串口。理解这个链路非常关键因为当设备起不来的时候你需要判断它卡在哪一层才能对症下药。我习惯把调试手段按可见性分成三类。第一类是被动观测比如串口日志、dmesg、proc/sys节点这些是系统主动吐给你的信息。第二类是主动探测比如用io命令读写寄存器、用devmem查看内存映射、用示波器量时序。第三类是侵入式调试比如加printk、用ftrace打点、挂kgdb。三类手段的侵入性递增对系统实时性的影响也递增所以排查顺序应该是先被动、再主动、最后才侵入。2.2 工具选型背后的取舍逻辑为什么Rockchip生态里串口调试始终是主力因为它的调试串口通常是UART2在BootROM阶段就已经初始化好了哪怕DRAM都没起来你也能看到最原始的输出。这一点比很多只依赖USB调试的方案要可靠得多。相比之下ADB和网络调试虽然方便但前提是系统已经跑到用户空间并且网络/USB子系统正常一旦系统起不来就完全失效。烧录工具方面官方提供的是基于USB的升级工具Windows端和Linux端都有底层走的是Rockchip私有的USB协议。Linux下常用的命令行工具能完成固件下载、分区读写、设备信息查询等操作。这里有个经验永远保留一份能正常启动的固件作为救砖底包因为一旦Loader被写坏就只能靠MaskROM模式强制进入下载状态来恢复而MaskROM模式对USB时序和工具版本比较敏感。2.3 建立自己的调试检查清单调试最怕的是没有章法。我自己的习惯是维护一份检查清单按启动阶段排列上电后串口有没有任何输出如果有输出卡在哪一行Loader阶段DRAM容量识别对不对U-Boot能不能读到正确的分区表Kernel有没有解压成功根文件系统挂载点对不对init进程有没有起来这份清单能帮你在几分钟内定位问题区间而不是盲目地重烧固件。3. 串口与日志系统最基础也最容易被低估的手段3.1 串口连接与参数配置的实操细节串口调试看似简单但细节没搞对就是一堆乱码。Rockchip平台的调试串口默认参数通常是波特率1500000、8位数据位、无校验、1位停止位。注意这个1500000不是常见的115200很多USB转串口模块默认不支持这么高的波特率需要选支持高速率的芯片比如FT232H、CP2102N这类。如果模块不支持你看到的全是乱码还以为是板子的问题。接线方面只需要接三根线TX、RX、GND。TX和RX要交叉连接即模块的TX接板子的RX模块的RX接板子的TX。GND必须共地否则电平参考不一致通信会不稳定。我见过有人只接TX和RX不接GND结果时好时坏查了半天才发现是地线没接。Linux下用minicom或picocom都行我个人更推荐picocom轻量且退出方便。配置命令大致是picocom -b 1500000 -d 8 -p n -s 1 /dev/ttyUSB0如果波特率太高导致丢字符可以在U-Boot阶段临时把波特率降下来但要注意改了之后Kernel的console参数也要同步改否则后半段日志又会乱码。3.2 内核日志分级与动态调整Kernel的日志系统用printk实现每条日志有个级别0到7数字越小越紧急。默认情况下console的日志级别由console_loglevel控制只有级别低于这个值的日志才会打印到串口。调试时经常需要临时提高日志详细程度有两种方式第一种是在Kernel命令行加loglevel8这样所有级别的日志都会输出。第二种是系统起来后动态调整echo 8 /proc/sys/kernel/printk这个命令会把console_loglevel设为8效果立竿见影。但要注意日志级别调太高会严重拖慢系统启动速度因为串口输出本身很慢大量printk会阻塞内核。所以定位完问题后记得调回去或者用dmesg -n 1恢复。另外dmesg命令可以查看内核环形缓冲区里的所有日志即使没打印到串口也能看到。配合dmesg -w可以实时跟踪dmesg | grep -i error可以快速过滤错误信息。这些组合拳在排查驱动加载失败时特别好用。3.3 用earlycon和earlyprintk抓启动早期日志有时候问题出在Kernel刚解压、正式console还没注册的那段时间这时候普通串口日志是看不到的。解决办法是在Kernel命令行加earlycon参数让内核在极早期就初始化一个简易的串口输出。Rockchip平台常见的写法是earlyconuart8250,mmio32,0xff1a0000这里的地址是UART控制器的寄存器基地址不同芯片型号不一样需要查对应的TRM技术参考手册。加了earlycon之后你能看到从解压到console注册之间的所有输出这段日志对于排查Kernel卡死但没有任何输出的问题至关重要。注意earlycon的地址填错不会报错只是没有任何输出容易让人误以为参数没生效。建议先用已知能工作的地址验证再逐步替换。4. 设备树与驱动层的排查手段4.1 设备树的反编译与运行时查看Rockchip平台大量使用设备树Device Tree来描述硬件很多驱动加载了但设备不工作的问题根源都在设备树配置。排查设备树有两个层面静态查看和运行时查看。静态查看是把编译好的dtb反编译回dtsdtc -I dtb -O dts -o output.dts input.dtb这样能看到实际生效的设备树内容而不是源码里那份可能没被编译进去的。我遇到过好几次源码改了但没重新编译dtb导致配置不生效的情况反编译一下立刻就能确认。运行时查看则是通过/proc/device-tree/目录这个目录是内核把设备树展开后的视图。比如想看某个I2C控制器下挂了哪些设备ls /proc/device-tree/i2cff1c0000/每个子目录对应一个设备节点里面的status文件能看出设备是okay还是disabled。这个方法的好处是不需要重新编译直接看当前系统实际认到了什么。4.2 用sysfs和debugfs观察驱动状态sysfs挂载在/sys和debugfs挂载在/sys/kernel/debug是驱动暴露给用户空间的窗口。以GPIO为例想看某个引脚当前的方向和电平cat /sys/kernel/debug/gpio这个命令会列出所有GPIO控制器的引脚状态包括哪些被申请了、方向是什么、当前电平高低。调试GPIO不工作时第一步就是看这个引脚有没有被正确申请如果显示requested但你没在驱动里申请那说明设备树里配了但驱动没接管。对于时钟和电源域Rockchip提供了/sys/kernel/debug/clk/clk_summary能看到每个时钟的使能状态和频率。很多外设不工作是因为时钟没开或者频率不对这个文件一眼就能看出来。电源域则看/sys/kernel/debug/pm_genpd/pm_genpd_summary能确认某个电源域是否上电。4.3 寄存器读写io命令与devmem的实战用法当软件层面查不出问题时就得直接看寄存器了。Rockchip的U-Boot里有个io命令可以读写物理地址io read 0xff1a0000 4 io write 0xff1a0000 0x12345678 4这个命令在U-Boot阶段特别有用比如怀疑某个外设的时钟门控没打开可以直接读CRU时钟复位单元的寄存器确认。Linux下则用devmem需要busybox支持或自己编译devmem 0xff1a0000 32读出来的是32位值。写的话加个值参数即可。但要注意直接读写寄存器有风险尤其是写操作可能把正在工作的外设搞挂。我的原则是读操作随便做写操作一定先确认寄存器含义并且做好系统会崩的心理准备。提示Rockchip的TRM里寄存器地址都是物理地址devmem用的也是物理地址不需要做虚实转换。但有些地址在安全域里普通权限访问会触发异常这时候需要确认是否在TrustZone的保护范围内。5. 性能与内存问题的剖析方法5.1 CPU占用与调度延迟的定位系统卡顿、响应慢首先要区分是CPU跑满还是IO阻塞。top和htop能看整体占用但要看具体哪个线程在跑得用top -H -p pid。Rockchip的多核芯片比如RK3588是4大核4小核还要注意任务被调度到哪个核上taskset可以查看和设置CPU亲和性。调度延迟方面/proc/pid/schedstat能看到任务在运行队列里等待的时间。如果等待时间很长但CPU占用不高可能是被高优先级任务抢占了或者有锁竞争。这时候可以用perf sched做更细的分析但perf在嵌入式环境里不一定有需要自己交叉编译。5.2 内存泄漏与碎片化的排查内存问题分两种泄漏和碎片化。泄漏用free和/proc/meminfo持续观察如果available内存持续下降且不回升基本就是泄漏。定位泄漏点可以用kmemleak内核配置里打开CONFIG_DEBUG_KMEMLEAK它会记录每次内存分配的调用栈一段时间后把没释放的打印出来。碎片化则表现为总空闲内存不少但申请大块连续内存比如给VPU、ISP用的CMA区域总是失败。看/proc/buddyinfo能了解各阶空闲页的分布如果高阶页很少说明碎片严重。Rockchip平台很多多媒体模块依赖CMA连续内存分配器CMA区域大小在设备树里配配小了就会各种申请失败。调整方法是改设备树里的size属性但要注意CMA是从总内存里预留的配太大会影响系统可用内存。5.3 用ftrace追踪内核函数调用ftrace是内核自带的追踪框架不需要额外工具在/sys/kernel/debug/tracing/下操作。最常用的功能是function tracer能记录所有内核函数的调用echo function /sys/kernel/debug/tracing/current_tracer echo 1 /sys/kernel/debug/tracing/tracing_on # 运行你的测试 echo 0 /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace输出会非常大所以通常配合set_ftrace_filter只追踪特定函数。比如怀疑某个I2C传输有问题就只追踪I2C相关的函数。ftrace的开销比printk小得多适合分析时序敏感的问题。6. 烧录、升级与救砖的实战经验6.1 固件烧录的几种模式与选择Rockchip平台烧录分三种模式Normal模式系统正常运行时通过USB或网络升级、Loader模式U-Boot阶段进入可以烧录除Loader外的分区、MaskROM模式芯片内部BootROM阶段可以烧录所有分区包括Loader。三种模式的权限递增Normal最方便但受限MaskROM最底层但操作最麻烦。进入Loader模式通常是在U-Boot里敲命令或者按住恢复键上电。MaskROM模式则需要短接Flash的特定引脚或者按住MaskROM键上电具体方法因板子而异。我的经验是平时升级用Normal或Loader就够了只有Loader被写坏导致完全起不来时才需要MaskROM。而MaskROM模式对USB线质量很敏感劣质线会导致识别不稳定建议用带屏蔽的短线。6.2 分区表与镜像布局的理解Rockchip的固件通常是一个打包好的update.img里面包含分区表和各个分区的镜像。用工具可以解包查看# 解包update.img unpack.sh update.img解包后会得到parameter.txt分区表和各个分区的img文件。parameter.txt里定义了每个分区的名字、起始扇区和大小格式类似0x000020000x00004000(uboot),0x000020000x00006000(trust),...前面是大小后面是起始扇区。理解这个格式很重要因为手动烧录单个分区时需要指定偏移。比如只想更新kernel就烧到kernel分区对应的起始扇区。6.3 救砖流程与常见失败原因救砖的核心是让芯片进入MaskROM模式然后用工具强制下载一个完整的Loader。流程大致是断开电源→短接MaskROM点或按住按键→上电→工具识别到MaskROM设备→松开→下载Loader→设备自动切换到Loader模式→下载完整固件。常见失败原因有几个一是USB驱动没装好Windows下需要装Rockchip的USB驱动Linux下一般免驱但要确认lsusb能看到设备二是短接时机不对要在上电前就短接好三是固件和芯片型号不匹配比如把RK3568的固件烧到RK3566上虽然引脚兼容但内部配置不同可能起不来。救砖时建议用官方提供的对应型号的完整固件不要用自己裁剪过的。7. 常见问题速查与避坑清单7.1 启动类问题速查表现象可能原因排查手段串口无任何输出串口线接错、波特率不对、板子没供电检查TX/RX交叉、确认1500000波特率、量电压卡在LoaderDRAM初始化失败、Loader损坏看Loader日志、换已知good的LoaderKernel解压后无输出console参数错、earlycon地址错检查bootargs、确认UART基地址根文件系统挂载失败分区表错、文件系统损坏检查parameter.txt、fsck修复init起不来根文件系统缺关键文件、权限错挂载后检查/sbin/init是否存在7.2 驱动类问题排查思路驱动问题的通用排查顺序是设备树有没有配→驱动有没有编译进内核→probe函数有没有被调用→probe返回值是什么→硬件时序对不对。前四步都能通过日志和sysfs确认最后一步才需要上示波器。我见过太多人一上来就怀疑硬件结果查了半天发现是设备树里status写成disabled了。具体到Rockchip平台有几个高频坑一是pinctrl配置引脚复用没配对导致信号出不来二是时钟没使能驱动probe时读寄存器全是0三是电源域没上电外设根本没工作。这三个都能通过前面讲的debugfs节点快速确认。7.3 我踩过的几个典型坑第一个坑是波特率不匹配导致的假死。有次调试一块新板子串口一直没输出我以为板子坏了换了三块都一样。后来才发现新板子的Loader把调试串口波特率改成了115200而我一直用1500000自然全是乱码。教训是拿到新板子先确认串口参数别想当然。第二个坑是devmem写寄存器把系统写挂。有次想改一个时钟分频直接devmem写了个值结果系统立刻死机。后来查TRM才发现那个寄存器有写保护需要先解锁。教训是写寄存器前一定查清楚有没有保护机制以及写入的值是否合法。第三个坑是CMA配太小导致视频编码失败。RK3588做4K编码时CMA区域至少要几百MB我一开始按默认配的结果编码器初始化总是失败日志里只报alloc failed查了半天才发现是CMA不够。教训是多媒体相关的内存需求要提前算好别等出问题才调。7.4 提升调试效率的几个习惯最后分享几个我养成的习惯。第一每次调试前先备份当前能工作的固件出问题能快速回滚。第二串口日志重定向到文件用picocom的日志功能或者tee方便事后搜索关键字。第三维护一份自己的寄存器笔记把常用外设的关键寄存器地址和含义记下来比每次翻TRM快得多。第四善用grep和awk过滤日志几千行日志里找关键信息靠眼睛是不行的。这些手段单独看都不复杂但组合起来用能覆盖从启动到应用层的绝大多数问题。Rockchip平台的调试资料确实分散但只要建立起分层认知知道每个问题该去哪一层找答案效率会有质的提升。 
长河君 · 2026/10/15 16:08:46 · 阅读 1.2k Rockchip嵌入式调试全攻略：从串口日志到寄存器读写
1. 为什么Rockchip平台的调试总让人又爱又恨搞嵌入式的人大多有个共识瑞芯微Rockchip的芯片性价比确实能打从早期的RK3288、RK3399到近几年的RK3568、RK3588在平板、盒子、工控板、边缘计算设备里到处都能见到它的身影。但真正上手调试的时候很多人第一反应是资料怎么这么散。官方文档有但往往藏在SDK压缩包的某个角落工具链有但版本对不上就各种报错日志能看但关键信息淹没在几千行输出里。这篇内容就是把我这些年折腾Rockchip平台积累下来的调试手段做一次系统梳理。所谓调试手段不只是看log这么简单它涵盖了从串口交互、内核日志分级、设备树排查、寄存器读写、性能剖析到固件烧录验证的一整套方法论。适合正在用RK系列芯片做产品开发的嵌入式工程师、驱动开发者也适合刚接触这个平台、被各种工具搞得有点懵的新手。我不会只告诉你用这个命令而是尽量把每个手段背后的逻辑、适用场景、以及我踩过的坑都讲清楚让你在遇到问题时能自己判断该掏出哪把螺丝刀。Rockchip的调试体系其实分了好几层最底层是BootROM和Loader阶段的串口输出往上是U-Boot和Kernel的日志系统再往上是用户空间的调试接口最外层还有PC端的烧录和抓取工具。很多人调试效率低根本原因是没有建立这个分层概念遇到问题就一通乱试。下面我按这个层次逐层拆解把每一层最实用的手段和参数配置讲透。2. 调试体系的分层认知与整体思路2.1 从BootROM到用户空间的分层模型Rockchip芯片上电后的启动链路大致是这样的BootROM芯片内部固化代码→ LoaderMiniLoader负责DRAM初始化和搬运→ U-Boot或LK→ Kernel → Rootfs。每一层都有独立的日志输出通道但默认情况下它们共用同一个调试串口。理解这个链路非常关键因为当设备起不来的时候你需要判断它卡在哪一层才能对症下药。我习惯把调试手段按可见性分成三类。第一类是被动观测比如串口日志、dmesg、proc/sys节点这些是系统主动吐给你的信息。第二类是主动探测比如用io命令读写寄存器、用devmem查看内存映射、用示波器量时序。第三类是侵入式调试比如加printk、用ftrace打点、挂kgdb。三类手段的侵入性递增对系统实时性的影响也递增所以排查顺序应该是先被动、再主动、最后才侵入。2.2 工具选型背后的取舍逻辑为什么Rockchip生态里串口调试始终是主力因为它的调试串口通常是UART2在BootROM阶段就已经初始化好了哪怕DRAM都没起来你也能看到最原始的输出。这一点比很多只依赖USB调试的方案要可靠得多。相比之下ADB和网络调试虽然方便但前提是系统已经跑到用户空间并且网络/USB子系统正常一旦系统起不来就完全失效。烧录工具方面官方提供的是基于USB的升级工具Windows端和Linux端都有底层走的是Rockchip私有的USB协议。Linux下常用的命令行工具能完成固件下载、分区读写、设备信息查询等操作。这里有个经验永远保留一份能正常启动的固件作为救砖底包因为一旦Loader被写坏就只能靠MaskROM模式强制进入下载状态来恢复而MaskROM模式对USB时序和工具版本比较敏感。2.3 建立自己的调试检查清单调试最怕的是没有章法。我自己的习惯是维护一份检查清单按启动阶段排列上电后串口有没有任何输出如果有输出卡在哪一行Loader阶段DRAM容量识别对不对U-Boot能不能读到正确的分区表Kernel有没有解压成功根文件系统挂载点对不对init进程有没有起来这份清单能帮你在几分钟内定位问题区间而不是盲目地重烧固件。3. 串口与日志系统最基础也最容易被低估的手段3.1 串口连接与参数配置的实操细节串口调试看似简单但细节没搞对就是一堆乱码。Rockchip平台的调试串口默认参数通常是波特率1500000、8位数据位、无校验、1位停止位。注意这个1500000不是常见的115200很多USB转串口模块默认不支持这么高的波特率需要选支持高速率的芯片比如FT232H、CP2102N这类。如果模块不支持你看到的全是乱码还以为是板子的问题。接线方面只需要接三根线TX、RX、GND。TX和RX要交叉连接即模块的TX接板子的RX模块的RX接板子的TX。GND必须共地否则电平参考不一致通信会不稳定。我见过有人只接TX和RX不接GND结果时好时坏查了半天才发现是地线没接。Linux下用minicom或picocom都行我个人更推荐picocom轻量且退出方便。配置命令大致是picocom -b 1500000 -d 8 -p n -s 1 /dev/ttyUSB0如果波特率太高导致丢字符可以在U-Boot阶段临时把波特率降下来但要注意改了之后Kernel的console参数也要同步改否则后半段日志又会乱码。3.2 内核日志分级与动态调整Kernel的日志系统用printk实现每条日志有个级别0到7数字越小越紧急。默认情况下console的日志级别由console_loglevel控制只有级别低于这个值的日志才会打印到串口。调试时经常需要临时提高日志详细程度有两种方式第一种是在Kernel命令行加loglevel8这样所有级别的日志都会输出。第二种是系统起来后动态调整echo 8 /proc/sys/kernel/printk这个命令会把console_loglevel设为8效果立竿见影。但要注意日志级别调太高会严重拖慢系统启动速度因为串口输出本身很慢大量printk会阻塞内核。所以定位完问题后记得调回去或者用dmesg -n 1恢复。另外dmesg命令可以查看内核环形缓冲区里的所有日志即使没打印到串口也能看到。配合dmesg -w可以实时跟踪dmesg | grep -i error可以快速过滤错误信息。这些组合拳在排查驱动加载失败时特别好用。3.3 用earlycon和earlyprintk抓启动早期日志有时候问题出在Kernel刚解压、正式console还没注册的那段时间这时候普通串口日志是看不到的。解决办法是在Kernel命令行加earlycon参数让内核在极早期就初始化一个简易的串口输出。Rockchip平台常见的写法是earlyconuart8250,mmio32,0xff1a0000这里的地址是UART控制器的寄存器基地址不同芯片型号不一样需要查对应的TRM技术参考手册。加了earlycon之后你能看到从解压到console注册之间的所有输出这段日志对于排查Kernel卡死但没有任何输出的问题至关重要。注意earlycon的地址填错不会报错只是没有任何输出容易让人误以为参数没生效。建议先用已知能工作的地址验证再逐步替换。4. 设备树与驱动层的排查手段4.1 设备树的反编译与运行时查看Rockchip平台大量使用设备树Device Tree来描述硬件很多驱动加载了但设备不工作的问题根源都在设备树配置。排查设备树有两个层面静态查看和运行时查看。静态查看是把编译好的dtb反编译回dtsdtc -I dtb -O dts -o output.dts input.dtb这样能看到实际生效的设备树内容而不是源码里那份可能没被编译进去的。我遇到过好几次源码改了但没重新编译dtb导致配置不生效的情况反编译一下立刻就能确认。运行时查看则是通过/proc/device-tree/目录这个目录是内核把设备树展开后的视图。比如想看某个I2C控制器下挂了哪些设备ls /proc/device-tree/i2cff1c0000/每个子目录对应一个设备节点里面的status文件能看出设备是okay还是disabled。这个方法的好处是不需要重新编译直接看当前系统实际认到了什么。4.2 用sysfs和debugfs观察驱动状态sysfs挂载在/sys和debugfs挂载在/sys/kernel/debug是驱动暴露给用户空间的窗口。以GPIO为例想看某个引脚当前的方向和电平cat /sys/kernel/debug/gpio这个命令会列出所有GPIO控制器的引脚状态包括哪些被申请了、方向是什么、当前电平高低。调试GPIO不工作时第一步就是看这个引脚有没有被正确申请如果显示requested但你没在驱动里申请那说明设备树里配了但驱动没接管。对于时钟和电源域Rockchip提供了/sys/kernel/debug/clk/clk_summary能看到每个时钟的使能状态和频率。很多外设不工作是因为时钟没开或者频率不对这个文件一眼就能看出来。电源域则看/sys/kernel/debug/pm_genpd/pm_genpd_summary能确认某个电源域是否上电。4.3 寄存器读写io命令与devmem的实战用法当软件层面查不出问题时就得直接看寄存器了。Rockchip的U-Boot里有个io命令可以读写物理地址io read 0xff1a0000 4 io write 0xff1a0000 0x12345678 4这个命令在U-Boot阶段特别有用比如怀疑某个外设的时钟门控没打开可以直接读CRU时钟复位单元的寄存器确认。Linux下则用devmem需要busybox支持或自己编译devmem 0xff1a0000 32读出来的是32位值。写的话加个值参数即可。但要注意直接读写寄存器有风险尤其是写操作可能把正在工作的外设搞挂。我的原则是读操作随便做写操作一定先确认寄存器含义并且做好系统会崩的心理准备。提示Rockchip的TRM里寄存器地址都是物理地址devmem用的也是物理地址不需要做虚实转换。但有些地址在安全域里普通权限访问会触发异常这时候需要确认是否在TrustZone的保护范围内。5. 性能与内存问题的剖析方法5.1 CPU占用与调度延迟的定位系统卡顿、响应慢首先要区分是CPU跑满还是IO阻塞。top和htop能看整体占用但要看具体哪个线程在跑得用top -H -p pid。Rockchip的多核芯片比如RK3588是4大核4小核还要注意任务被调度到哪个核上taskset可以查看和设置CPU亲和性。调度延迟方面/proc/pid/schedstat能看到任务在运行队列里等待的时间。如果等待时间很长但CPU占用不高可能是被高优先级任务抢占了或者有锁竞争。这时候可以用perf sched做更细的分析但perf在嵌入式环境里不一定有需要自己交叉编译。5.2 内存泄漏与碎片化的排查内存问题分两种泄漏和碎片化。泄漏用free和/proc/meminfo持续观察如果available内存持续下降且不回升基本就是泄漏。定位泄漏点可以用kmemleak内核配置里打开CONFIG_DEBUG_KMEMLEAK它会记录每次内存分配的调用栈一段时间后把没释放的打印出来。碎片化则表现为总空闲内存不少但申请大块连续内存比如给VPU、ISP用的CMA区域总是失败。看/proc/buddyinfo能了解各阶空闲页的分布如果高阶页很少说明碎片严重。Rockchip平台很多多媒体模块依赖CMA连续内存分配器CMA区域大小在设备树里配配小了就会各种申请失败。调整方法是改设备树里的size属性但要注意CMA是从总内存里预留的配太大会影响系统可用内存。5.3 用ftrace追踪内核函数调用ftrace是内核自带的追踪框架不需要额外工具在/sys/kernel/debug/tracing/下操作。最常用的功能是function tracer能记录所有内核函数的调用echo function /sys/kernel/debug/tracing/current_tracer echo 1 /sys/kernel/debug/tracing/tracing_on # 运行你的测试 echo 0 /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace输出会非常大所以通常配合set_ftrace_filter只追踪特定函数。比如怀疑某个I2C传输有问题就只追踪I2C相关的函数。ftrace的开销比printk小得多适合分析时序敏感的问题。6. 烧录、升级与救砖的实战经验6.1 固件烧录的几种模式与选择Rockchip平台烧录分三种模式Normal模式系统正常运行时通过USB或网络升级、Loader模式U-Boot阶段进入可以烧录除Loader外的分区、MaskROM模式芯片内部BootROM阶段可以烧录所有分区包括Loader。三种模式的权限递增Normal最方便但受限MaskROM最底层但操作最麻烦。进入Loader模式通常是在U-Boot里敲命令或者按住恢复键上电。MaskROM模式则需要短接Flash的特定引脚或者按住MaskROM键上电具体方法因板子而异。我的经验是平时升级用Normal或Loader就够了只有Loader被写坏导致完全起不来时才需要MaskROM。而MaskROM模式对USB线质量很敏感劣质线会导致识别不稳定建议用带屏蔽的短线。6.2 分区表与镜像布局的理解Rockchip的固件通常是一个打包好的update.img里面包含分区表和各个分区的镜像。用工具可以解包查看# 解包update.img unpack.sh update.img解包后会得到parameter.txt分区表和各个分区的img文件。parameter.txt里定义了每个分区的名字、起始扇区和大小格式类似0x000020000x00004000(uboot),0x000020000x00006000(trust),...前面是大小后面是起始扇区。理解这个格式很重要因为手动烧录单个分区时需要指定偏移。比如只想更新kernel就烧到kernel分区对应的起始扇区。6.3 救砖流程与常见失败原因救砖的核心是让芯片进入MaskROM模式然后用工具强制下载一个完整的Loader。流程大致是断开电源→短接MaskROM点或按住按键→上电→工具识别到MaskROM设备→松开→下载Loader→设备自动切换到Loader模式→下载完整固件。常见失败原因有几个一是USB驱动没装好Windows下需要装Rockchip的USB驱动Linux下一般免驱但要确认lsusb能看到设备二是短接时机不对要在上电前就短接好三是固件和芯片型号不匹配比如把RK3568的固件烧到RK3566上虽然引脚兼容但内部配置不同可能起不来。救砖时建议用官方提供的对应型号的完整固件不要用自己裁剪过的。7. 常见问题速查与避坑清单7.1 启动类问题速查表现象可能原因排查手段串口无任何输出串口线接错、波特率不对、板子没供电检查TX/RX交叉、确认1500000波特率、量电压卡在LoaderDRAM初始化失败、Loader损坏看Loader日志、换已知good的LoaderKernel解压后无输出console参数错、earlycon地址错检查bootargs、确认UART基地址根文件系统挂载失败分区表错、文件系统损坏检查parameter.txt、fsck修复init起不来根文件系统缺关键文件、权限错挂载后检查/sbin/init是否存在7.2 驱动类问题排查思路驱动问题的通用排查顺序是设备树有没有配→驱动有没有编译进内核→probe函数有没有被调用→probe返回值是什么→硬件时序对不对。前四步都能通过日志和sysfs确认最后一步才需要上示波器。我见过太多人一上来就怀疑硬件结果查了半天发现是设备树里status写成disabled了。具体到Rockchip平台有几个高频坑一是pinctrl配置引脚复用没配对导致信号出不来二是时钟没使能驱动probe时读寄存器全是0三是电源域没上电外设根本没工作。这三个都能通过前面讲的debugfs节点快速确认。7.3 我踩过的几个典型坑第一个坑是波特率不匹配导致的假死。有次调试一块新板子串口一直没输出我以为板子坏了换了三块都一样。后来才发现新板子的Loader把调试串口波特率改成了115200而我一直用1500000自然全是乱码。教训是拿到新板子先确认串口参数别想当然。第二个坑是devmem写寄存器把系统写挂。有次想改一个时钟分频直接devmem写了个值结果系统立刻死机。后来查TRM才发现那个寄存器有写保护需要先解锁。教训是写寄存器前一定查清楚有没有保护机制以及写入的值是否合法。第三个坑是CMA配太小导致视频编码失败。RK3588做4K编码时CMA区域至少要几百MB我一开始按默认配的结果编码器初始化总是失败日志里只报alloc failed查了半天才发现是CMA不够。教训是多媒体相关的内存需求要提前算好别等出问题才调。7.4 提升调试效率的几个习惯最后分享几个我养成的习惯。第一每次调试前先备份当前能工作的固件出问题能快速回滚。第二串口日志重定向到文件用picocom的日志功能或者tee方便事后搜索关键字。第三维护一份自己的寄存器笔记把常用外设的关键寄存器地址和含义记下来比每次翻TRM快得多。第四善用grep和awk过滤日志几千行日志里找关键信息靠眼睛是不行的。这些手段单独看都不复杂但组合起来用能覆盖从启动到应用层的绝大多数问题。Rockchip平台的调试资料确实分散但只要建立起分层认知知道每个问题该去哪一层找答案效率会有质的提升。