RK3568调试实战：用/proc/interrupts揪出MIPI摄像头黑屏真凶

前阵子调试RK3568上的ov5695摄像头，画面死活出不来。I2C读写都正常，sensor ID也能读到，供电、复位、上电时序也都对着原理图查过一遍，示波器点上MCLK也有波形。按理说驱动该跑起来的都跑起来了，但输出就是黑的。折腾两天后，让我破案的不是高深的调优工具，而是一句几乎被老一辈驱动工程师说烂了的话：去cat一下/proc/interrupts。那个MIPI CSI中断计数纹丝不动，我立刻把怀疑重点从sensor本身挪到了MIPI收发链路。就这么一个小小的观察，省下了至少半天抓波形的时间。

这类经验在RK3568平台开发里并不少见。proc文件系统看起来又老又土，但它在嵌入式Linux开发中依然是排查问题的第一站。这篇文章不打算从教科书角度复述proc目录有多少个文件，而是从RK3568实战场景出发，把cpuinfo、meminfo、interrupts、device-tree、net/dev这些高频节点逐个讲透，再结合设备树、ov5695摄像头调试、以太网PHY参考时钟、openbmc监控等实际案例，聊聊我踩过的坑和用出来的心得。无论你是刚接触瑞芯微平台的新手，还是已经写了几年驱动的老兵，应该都能从里面找到一点有用的东西。

1. 一次MIPI摄像头调试，把我拉回/proc的老路

1.1 现象和第一轮排查

这颗ov5695是500万像素的MIPI摄像头传感器，在RK3568平台上搭配MIPI CSI接口使用。一开始我并没有怀疑链路时序，因为驱动加载非常顺利：sensor的ID寄存器读出来是0x5695，I2C通信正常，VDD、VDDIO、AVDD的电压测量都对，复位脚时序也按照数据手册重新对过，甚至用示波器抓过MCLK主时钟，频率大概是24MHz，幅值也够。按照以往调试CSI摄像头的经验，这种情况初始化sensor本身已经算通过了。

可图像就是出不来。RK3568的ISP驱动那边log没有报错，v4l2框架的调用链也正常，s_stream(1)之后sensor应该有帧输出了，但应用层拿到的是全黑画面。第一轮排查几乎都在寄存器层面打转：反复读写sensor的曝光、增益、模式设置，怀疑是不是输出了测试图案模式，又把测试图案寄存器翻出来改改。搞了一下午，发现不管是sensor输出测试图案还是真实图像，应用层拿到的缓冲区全是零。这个现象其实已经能说明问题了——数据根本没到ISP。

1.2 /proc/interrupts的“一票否决”

真正让我把思路扭过来的，是同事随口说了一句“看看CSI中断有没有来”。我打开终端敲了cat /proc/interrupts，在输出里找到mipi csi相关的中断号，然后反复拉流、停流，再cat一次。结果非常扎眼：那个中断计数一丁点变化都没有。如果MIPI RX有数据进来，CSI控制器会产生帧起始、帧结束、line等中断，计数是肯定要跳的。中断计数纹丝不动，等于明确告诉我：线路上压根没有MIPI包进来。

这句话听起来很平常，但在当时的环境下，等于是在一堆可疑对象里做了一个“一票否决”。我不用再去怀疑sensor寄存器配置，不用反复确认ISP那边的输出格式，直接把箭头指向了MIPI物理层和时钟供给。后来沿着这条线索查下去，真的是PHY侧参考时钟配置有问题。

1.3 为什么会忽略proc

现在不少调试流程都被图形化工具和仿真器带偏了，遇到问题第一反应是上trace32、上DS5、上各种vendor的调试软件。proc文件系统因为在桌面Linux上存在感太弱，常被人当成“看系统信息”的角落。但在嵌入式Linux里，它其实是内核向用户态透出状态的最直接窗口，尤其对中断、DMA、设备树解析结果这类信息，proc的呈现效率比任何图形工具都高。这也是为什么我做RK3568平台开发时，遇到疑难问题反而先回来看proc。它不花哨，但从不骗人。

2. /proc不是普通文件：内核的“实时前台窗口”

2.1 虚拟文件系统的运作方式

proc是一个虚拟文件系统，它不占用任何磁盘空间。你在ls -l /proc/cpuinfo的时候看到的文件大小是0，但cat它却能吐出几百字节内容，原因在于这些内容都是在读文件的瞬间，由内核里的回调函数现场生成的。你每cat一次，看到的就是那一个时刻的真实系统状态。这就像前台窗口一样，窗口背后发生了什么，你透过玻璃看到什么就是什么，玻璃本身不保存任何东西。

这种“无状态”特性带来两个结果。第一，proc节点天然适合读取实时状态，比如中断计数、内存水位、CPU负载，每次读都是一次新鲜采样。第二，proc节点不适合保存需要跨多次读保持一致的数据，如果你在两次读取之间系统状态变了，得到的结果自然不一样。做监控脚本时要注意这一点，不要在短时间间隔内反复cat同一个节点，然后期望它返回一个完全平滑的曲线，它反映的是瞬时抖动。

2.2 与/sysfs、/dev的分工

很多人刚开始接触Linux设备驱动时，会被/dev、/proc、/sys三个目录搞晕。我简单做个区分：/dev是设备节点，是应用程序用来打开设备并调用read、write、ioctl的入口；/sysfs描述的是设备模型，把设备、驱动、总线、class之间的拓扑关系暴露出来；/proc则更像一个“内核运行状态报告中心”，它既有进程相关的目录，也有全局的内存、中断、时钟等状态。三者有部分重叠，但设计定位不同。

在RK3568平台上，比如你要看某个GPIO是否被占用，可以到/sys/kernel/debug/gpio里看debugfs，也可以在设备树相关节点里找pinctrl状态，但要看这个GPIO模拟的中断到底触发过多少次，还是得回到/proc/interrupts。它们之间的关系不是谁替代谁，而是各管一段。把这三者的分工理解了，遇到问题时才知道该翻哪个目录。

2.3 RK3568上确认proc挂载状态

正常情况下RK3568的根文件系统启动后，/proc都会被自动挂载。你可以用mount | grep proc确认一下，如果输出里有proc on /proc type proc说明挂载正常。如果某天你进入initramfs或裁剪过的文件系统，发现cat /proc/cpuinfo报No such file or directory，多半是proc没挂。手动执行一下mount -t proc proc /proc就好。这个基础操作看起来简单，但在定制RK3568系统的过程中真的会遇到，尤其是当你的rootfs是从buildroot手工裁剪出来的时候。

3. RK3568开发中不可不看的proc节点：从cpuinfo到interrupts

3.1 /proc/cpuinfo：确认CPU跑对了

在RK3568上执行cat /proc/cpuinfo，你会看到4个processor，从0到3，对应四核Cortex-A55。除了model name之外，更应该关注的是Features这一行，它列出了CPU支持的指令集扩展，比如asimd、fp、crc32等。如果某些功能特性没有出现在列表里，CPU可能没有正常运行在预期状态，或者内核配置里关闭了相关特性。

另一个值得注意的点是BogoMIPS，这是内核在启动早期算出来一个“约等于”CPU频率的数值，校准之后基本固定。如果4个核的BogoMIPS差异很大，可能是cpufreq没有正确统一调度，或者某个核进了低功耗状态没出来。我在RK3568上遇到过只启动2个核的鬼现象，同事怀疑是DDR训练不稳，结果就是cpuinfo里只有2个processor节点，顺着这个线索再查dmesg，发现是PSCI启动某个从核时返回了错误。

3.2 /proc/meminfo：内存水位与cma连续内存排查

cat /proc/meminfo是所有内存问题排查的起点。MemTotal是物理内存总量，MemAvailable是估算的可分配内存，比MemFree更贴近真实可用量，因为它还考虑了page cache和slab的可回收部分。在RK3568的多媒体场景里，摄像头、ISP、编解码器通常需要连续物理内存，这部分一般走CMA。如果系统跑着跑着突然出现分配连续内存失败，可以先看MemAvailable和CmaTotal、CmaFree。

我有个习惯，压测前先cat /proc/meminfo | grep Cma记录一下CmaFree，跑一段视频编解码后再看一眼。如果CmaFree直线下降且不回收，基本可以确定有驱动把CMA内存拿走后没释放。这种泄漏用valgrind根本查不到，用户态看不到，proc却一目了然。

3.3 /proc/interrupts：每个中断都是一条心电图

/proc/interrupts的每一行代表一个中断源，列分别是中断号、每个CPU上的触发次数、中断类型、中断名称。驱动调试时我几乎必看这个文件。关键技巧是：不要只看当前计数是多少，而是要看操作前后计数变没变。比如你按一下按键，如果gpio按键中断计数不动，要么中断没注册成功，要么中断被mask了，要么物理信号根本没到达中断控制器。

在RK3568平台上，MIPI CSI、ISP、GMAC、SDMMC等外设都有独立中断。你可以在/proc/interrupts里用grep过滤出关键词，比如cat /proc/interrupts | grep -i csi。如果确认驱动已经probe成功，但中断计数不涨，那么问题大概率出现在外设使能、时钟供给、或者硬件连接上。这条经验救了我很多次，ov5695那次就是典型。

3.4 /proc/cmdline：启动参数的最好“照妖镜”

cat /proc/cmdline能看到内核真正的启动参数，包括console配置、root分区位置、DMA内存大小、以及一些调试参数。很多时候你改了uboot环境变量，但不确定内核是否真的收到了，直接看/proc/cmdline是最快的验证方式。比如你想给内核传一个cma=128M参数，改完uboot后重启，先不要急着看代码，cat一下/proc/cmdline，如果里面有cma=128M，说明bootargs传参成功；如果没有，就要去查uboot的bootargs拼接逻辑或环境变量是否保存。

在RK3568开发中还常见一个问题：硬件上改了DDR容量，但内核还是识别成原来的大小。这时候cat /proc/cmdline和cat /proc/meminfo对比看，就能判断是uboot传参问题，还是内核DTB里的memory节点问题，不要把锅都甩给内核。

4. 设备树解析结果，原来就摊在/proc/device-tree里

4.1 设备树变成目录树

RK3568和其他主流ARM64平台一样，启动时由uboot把DTB传给内核，内核解析后会把设备树展开成目录结构放在/proc/device-tree下。在很多发行版里，这个路径是一个符号链接，实际指向/sys/firmware/devicetree/base。你在设备树里写的每一个节点，在这里都会变成目录；每个属性，都会变成一个文件。这个机制非常有用，它让你在运行时验证“内核看到的设备树”和你编译时写的设备树是否一致。

举个例子，你在dts里写了一个i2c1下的ov5695节点，正常解析后，ls /proc/device-tree/i2c1/应该能看到一个名字类似ov5695@36的目录，compatible、reg、clocks等属性也都在。如果节点没出现，说明dts没有编译进去，或者设备树里i2c1本身就被disable了。这种情况在RK3568上用SDK开发时特别常见，因为有些板型会把摄像头节点写在单独dtsi里，你忘了include，结果节点自然不存在。

4.2 用hexdump读取节点属性

设备树属性文件用cat直接读会出现乱码，因为这些属性不是文本，而是二进制大端数据。比如你cat /proc/device-tree/ov5695@36/reg，大概率输出一个不可见的字节序列，看起来像乱码。正确姿势是用hexdump或od查看。hexdump -C /proc/device-tree/ov5695@36/reg会显示类似00 00 00 36这样的字节，这个36就是I2C地址0x36，也就是ov5695在7位地址模式下的值。

同理，compatible属性是可打印字符串，可以用cat直接读。clocks属性通常是phandle数组，需要对照设备树头文件解释。熟悉这种数据格式后，你就能在runtime直接验证dts里每个属性屁股后面对不对。曾经有次我把sensor的reset-gpio属性写错了引脚号，在dts里看是&gpio3 RK_PC2 GPIO_ACTIVE_LOW，然后去/proc/device-tree对应节点里hexdump，发现和预期的GPIO number不一致，立刻定位到是头文件宏定义问题。

4.3 修改设备树后“不生效”的定位技巧

很多新手在RK3568上改了dts，重新编译并烧录boot.img，发现修改没生效。第一反应是“烧录失败”或者“缓存”，其实最直接的方法就是去/proc/device-tree里找对应节点看一下。比如你改了lcd的timing，就去/proc/device-tree/display-timing下看数值变没变。如果没变，再看dtb文件本身是否被uboot正确加载。有时候uboot会把多个dtb打在boot分区里，根据硬件id选择加载，你以为烧的是这个dtb，实际上加载的是另一个。

至于判断一个节点是否被disable，设备树里的status属性会体现在/proc/device-tree/xxx/status文件里。cat显示okay表示使能，显示disabled表示被关闭。如果某个外设驱动不probe，先去看status是不是overlay后变成disabled，这个比看内核log还直观。

5. 实战复盘：ov5695黑屏两天，最后靠/proc/interrupts破了案

5.1 问题现象与第一轮错误排查

回到开头那个ov5695项目。具体型号是OV5695，MIPI CSI-2接口，接在RK3568的一个CSI控制器上。现象是驱动注册正常，v4l2-ctl --stream-mmap能打开设备，但抓到的每一帧都是零，像是sensor没有输出有效数据。第一轮排查时，我用了最笨但最常用的许方法：怀疑初始化序列不对，于是从vendor的代码里重新核对寄存器列表，确认sensor分辨率、帧率、数据lane数都匹配；又怀疑供电纹波，直接在sensor电源引脚上挂了示波器看了一个上午。

期间还测了sensor的PWDN和RESETB时序，发现驱动在probe时确实按照先拉低复位、再拉高的流程走了一遍。但所有经手人都忽略了一个事实：CSI控制器的中断始终没有动静。当时我们的注意力全在sensor侧，总觉得sensor已经初始化成功就等于图像应该能出来，现在回头看，这个想法害死人。

5.2 关键一步：对比/proc/interrupts里csi/isp中断计数

具体操作很简单：

cat /proc/interrupts | grep -Ei "csi|isp|cif"

让应用开始拉流，等几秒，停掉，再执行一次同样的命令，对比计数。正常情况，只要MIPI RX有数据，csi相关中断计数会几十上百地涨。那次实验里，我连续操作了三次，计数一帧不动。这意味着什么？意味着CSI控制器根本没有收到来自MIPI PHY的帧同步信号，也就是说sensor这边的MIPI TX大概率在“空转”，数据没有真正发到RK3568那边。

有了这个结论，排查方向立即收窄到MIPI物理层：sensor的MCLK是否稳定、PHY的参考时钟是否给了、MIPI lane的端接电阻是否焊好。注意，MCLK有波形不代表频率和相位对，特别像ov5695这种对MCLK触发沿有严格要求的sensor，频率不对照样不会有输出。

5.3 时钟链路的最终修复

最终定位到的原因在sensor的主时钟供给上。RK3568设备树里ov5695节点的clocks属性，通常会用clk_ref作为MCLK时钟源。我们当时的dts把assigned-clock-rates写成了24000000，但RK3568的某个CRU输出无法在sensor侧给出正确的占空比，导致ov5695的MIPI PLL没有锁定，信号虽然看起来有波形，但协议层完全对不上。后来我把该时钟输出切换到另外一个更干净的时钟源，重新设定频率，中断计数开始猛跳，图像也出来了。

修复后我特意又cat了几次/proc/interrupts，看到CSI的中断计数持续增长，才放心把代码提交。整个过程中，除了示波器，最关键的一次判断就来自一个静态的proc节点。这也印证了一个原则：中断计数是外设“有没有真正干活”的金标准，比任何log都可靠。

5.4 给新人的排查流程表

遇到MIPI摄像头不出图，我现在的固定套路是这样：

这套流程我按顺序执行，很少有查不出来的摄像头问题。

6. RK3568以太网PHY参考时钟与/proc/net/dev的坑

6.1 eth0_refclko_25m是什么

RK3568的GMAC经常被拿来接千兆PHY，比如RTL8211F、YT8531这些。在设计上，PHY需要的25MHz参考时钟可以由RK3568的某个引脚输出，这个信号在原理图和设备树里经常叫eth0_refclko_25m。它意味着SoC的CRU生成一个25MHz时钟，从特定GPIO或功能引脚输出给PHY，作为PHY的TX时钟或参考时钟来源。

这个时钟在设备树里往往体现在&gmac0或&gmac1节点的clocks属性，以及assigned-clocks、assigned-clock-rates里。如果硬件上采用SoC输出25M给PHY的方案，但设备树里配置成了PHY自振模式，就会导致RGMII接口协商失败或吞吐异常。反过来，如果硬件上是PHY自己接晶振，又错误地打开了SoC的25M输出，也可能带来信号质量干扰。

6.2 /proc/net/dev教你区分“丢包”和“不干活”

排查网络问题，/proc/net/dev是快照式的好帮手。它按接口列出收发包数、错误数、丢包数、fifo错误等统计。很多人只看ifconfig或者ip -s，但/proc/net/dev在所有底层网络驱动里都会更新，哪怕是自定义驱动也一样，信息更通用。

举个例子，RK3568的网口出现ping丢包，我先cat /proc/net/dev | grep eth0记录RX和TX累计值，然后持续ping一段时间，再cat一次。如果RX packets在涨，RX errors也在同步涨，说明数据确实到达了MAC，但可能在MAC或PHY侧被丢弃。这时候去查RGMII的时钟延迟、PHY寄存器配置才有意义。如果RX packets根本不涨，那就不是丢包，而是数据根本没进来，先去查PHY有没有link，再查时钟引脚，不要一上来就优化内核协议栈参数。

6.3 网关吞吐异常的排查经验

有次在RK3568上做多网口网关，wan口吞吐始终跑不满，iperf3只到500Mbps，千兆完全发挥不出来。我第一件事就是用cat /proc/interrupts | grep eth看GMAC中断是不是都挤在CPU0上。RK3568的gic支持中断分发，如果所有网卡中断都固定在同一个核，单核处理软中断容易成为瓶颈。用proc计数确认之后，我把GMAC中断通过irqaffinity打散到不同CPU，吞吐立刻上了一截。

接着看/proc/net/softnet_stat里的drop计数，发现个别CPU的softnet backlog有丢包，又检查了NAPI的poll预算和设备驱动的中断合并参数。最终定位到PHY的RGMII TX delay配置不对，导致RGMII收发时序裕量不够，偶尔产生CRC错误。整个过程里，proc字段的变化帮我把范围从OS层一路压到PHY寄存器，最后修的是设备树里tx-internal-delay的取值。

7. 把proc吃透：openbmc监控RK3568的快速实现

7.1 openbmc的基础设施里，proc是现成传感器

openbmc很多场景下会跑在服务器BMC或带外管理控制器上，主要用来监测电压、温度、风扇转速、系统状态。如果你基于RK3568做一套精简openbmc，或者把openbmc作为管理平面去监控同板卡上的Linux应用处理器，那/proc就是我们不需要额外驱动的现成“传感器”。

比如系统健康监控，CPU占用率可以从/proc/stat计算，系统负载可以直接读/proc/loadavg，内存余量看/proc/meminfo，内核版本看/proc/version。这些信息在进程还在正常运行的前提下，几乎不会出现“读不到”的情况，比依赖I2C传感器更加可靠。所以我通常建议在openbmc的早期原型里，先打通proc采集，再慢慢加硬件传感器。

7.2 一个最小健康监控脚本

下面是一个很小的Python示例，演示如何周期采集并在异常时上报：

#!/usr/bin/env python3 import time def read_proc_mem(): with open('/proc/meminfo') as f: data = {} for line in f: if 'MemTotal' in line or 'MemAvailable' in line: parts = line.split(':') name = parts[0].strip() value = int(parts[1].strip().split()[0]) data[name] = value return data def read_loadavg(): with open('/proc/loadavg') as f: parts = f.read().split() return float(parts[0]), float(parts[1]), float(parts[2]) while True: mem = read_proc_mem() load1, load5, load15 = read_loadavg() mem_used = mem.get('MemTotal', 0) - mem.get('MemAvailable', 0) print(f"mem_used_kb={mem_used}, load1={load1}") time.sleep(5)

这段脚本可以直接跑在RK3568的rootfs里，也可以放进openbmc的某个应用里。关键在于，它只读不写，不需要特殊用户态权限，生产环境也能放心使用。数据出来后，再用DBus或MQTT推给上层管理界面，完整监控链路就通了。

7.3 读取频率和DBus上报的注意点

读取proc的频率不宜太密。有些监控程序每秒循环cat /proc/meminfo几十次，在高负载下会放大CPU抖动。一般业务场景3到5秒采一次就够了，如果要做曲线图，1秒钟一次也足矣。另外，openbmc里很多守护进程用sdbusplus访问DBus，可以把采集任务放到循环里，但要注意proc读取本身是同步阻塞的，不要在DBus主循环里直接做大量文件读取，否则会卡住其他服务。

如果真的要让openbmc作为带外监控完整掌控宿主机，还可以通过读取宿主机串口或远程执行命令的方式访问/proc。这种方案实现最快，但要在安全边界内使用，不要在生产环境裸奔。我在RK3568原型上验证过，openbmc的Python服务里定期采集/proc完全没问题，资源开销可以忽略。

8. 自己写一个proc节点，把内核状态握在手里

8.1 什么时候应该自己造节点

有些内部驱动调试，内核现成的proc节点不够用。比如你写了一个自定义外设驱动，希望把最近一次传输的错误码、dma描述符状态、环形缓冲区的读写指针暴露给用户态测试脚本，最直接的做法就是在驱动里创建一个proc节点。比起每次加debugfs临时开开关，一个精心设计的proc节点能让调试信息随叫随到。

RK3568 SDK默认内核基本都打开了CONFIG_PROC_FS，你可以用zcat /proc/config.gz | grep CONFIG_PROC_FS确认。老版本内核没有自动挂载configfs，有时没有config.gz，那就用grep PROC_FS /boot/config-*或者在内核源码目录查/usr/src/linux-headers-*/.config。一般来说，嵌入式产品的内核都会保留proc，否则很多系统工具都会失灵。

8.2 用seq_file写一个最小proc接口

新内核推荐用seq_file接口来操作proc文件。下面是常见的内核模块片段：

#include <linux/module.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> static int my_proc_show(struct seq_file *m, void *v) { seq_printf(m, "rk3568 custom proc node\n"); seq_printf(m, "some_counter: %d\n", 42); return 0; } static int my_proc_open(struct inode *inode, struct file *file) { return single_open(file, my_proc_show, NULL); } static const struct file_operations my_proc_fops = { .owner = THIS_MODULE, .open = my_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static int __init my_proc_init(void) { proc_create("rk3568_debug", 0444, NULL, &my_proc_fops); return 0; } static void __exit my_proc_exit(void) { remove_proc_entry("rk3568_debug", NULL); } module_init(my_proc_init); module_exit(my_proc_exit); MODULE_LICENSE("GPL");

把这个模块编进RK3568内核或作为外部模块加载后，cat /proc/rk3568_debug就能看到输出。注意这里用了single_open，它适合一次输出全部内容的场景。如果数据量很大，建议用seq_open加seq_operations的show循环，避免一次性分配过大缓冲区。

8.3 proc还是debugfs：选型与安全

如果你要在调试完成后永久保留一个状态查询接口，proc是可以的，但要控制写权限。如果仅用于开发调试，随时会删，我更推荐debugfs，挂载点通常是/sys/kernel/debug。proc更适合那些“长期存在、可读性良好、系统工具也需要看”的信息，比如版本号、中断统计。debugfs适合那些“调试期临时看、内容可能大而杂”的信息。

还有一个安全提醒：千万不要图方便给proc节点开0666写权限，然后把一个没有校验的寄存器写接口暴露给用户态。至少在我的经验里，产品验收时监管方会拿这类接口做文章。宁可麻烦一点，把写入命令设计成白名单格式，在内核里做严格参数校验。RK3568平台很多客户定制功能都要过安全测试，这类细节提前处理比事后补洞省心得多。

最后再分享一个小技巧：排查问题时，多留意proc节点“数字不变”这件事。很多人盯着异常数字看半天，却忽略了“该变没变”背后的信息。中断计数不涨，说明数据没进来；CPU占用率不变，说明任务根本没跑；meminfo里CmaFree不回收，说明内存拿了没还。proc文件系统最迷人的地方就在这里，它安静地展示一切，而你要做的是学会看穿数字背后的物理世界。