前往官网 
发布
1233 阅读
预计阅读 15 分钟1、结论摘要
双摄启动后应用拿不到图像。根据君正官方文件"Ingenic-SDK\opensource\drivers\isp\tx-isp-PRJ009\PRJ009_inode.md"，逐级读取 /proc/jz/isp/ 节点后，确认存在 两个相互独立 的问题：
Sensor 1 帧率模式配置错误：应用要求两路Sensor都运行在 20 fps，但 isp-w00 显示 Sensor 1 实际生效为 30 fps。这属ISP和sensor配置不一致，不是本次无图的直接原因。
内核配置文件与硬件平台不匹配：开发板烧录的内核是使用 Goat 内核配置文件（单摄及38模组内核配置文件），而开发板使用或者参考 Vela板卡制作的（Vela：多摄及全功能内核配置文件）。Goat / Vela 是 PRJ009 面向不同板卡的两套内核配置文件。误用后会导致多摄数据链路没有建立，没有任何帧进入 ISP，这才是无图的直接原因。
将内核改为 Vela 内核配置文件、并修正 Sensor 1 的帧率模式后，双摄恢复正常取流。
2、测试环境
芯片：T32Pro
SDK：Tassadar-T33_T32Pro-2.0.0-20260804
Sensor 0：GC8613A，3840×2160，2 Lane
Sensor 1：GC5613S1，2880×1620，2 Lane
应用设置帧率：两路均为 20 fps
使用场景：两路 MIPI 同时启动并取流
3、排查方法：把节点当成一条数据链路
/proc/jz/isp/ 下的节点反映的是从 Sensor 输入到用户态取帧这条链路上各阶段的状态快照和累计计数。排查时按数据流方向逐级确认，不把某个节点当成孤立的寄存器 dump：
Sensor ↓ CSI/MIPI ↓ VIC ↓ ISP Core ↓ MSCA / IVDC ↓ Frame Source ↓ 用户态编码
常用节点及作用：
| 节点 | 主要检查内容 |
|---|---|
| isp-w00 | Sensor 名称、状态、分辨率、帧率、I2C、MCLK、MIPI lane 和 MIPI clock |
| isp-w01 | CSI host 状态、时钟、frm_start、frm_done 和 CSI 错误 |
| isp-w02 | VIC 帧中断、通道中断、DMA 中断和错误计数 |
| isp-m0 | ISP Core 的 frameNum、各通道 done、模块 done 和 ISP 错误 |
| isp-msca | 输出通道状态、channeldone 以及软件 buffer 队列 |
| isp-ivdc | 编码直通路径的 frame done、timeout、FIFO 和 DDR 状态 |
| isp-fs | qbufs、done、dqbufs、丢帧、错误和 buffer 状态 |
| isp-tuning | ISP 模式、Sensor 数量和图像处理运行状态 |
排查时建议在正常启动后和异常出现后各采集一次：
for n in isp-w00 isp-w01 isp-w02 isp-m0 isp-msca isp-ivdc isp-fs isp-tuning do cat /proc/jz/isp/$n > /tmp/isp-$n.txt done
由于多数字段是累计计数，单看某一时刻的静态值意义有限。更可靠的做法是间隔一段时间重复读取，用两次读数的差值判断链路是否持续工作。例如：
cat /proc/jz/isp/isp-w02;sleep 10;cat /proc/jz/isp/isp-w02
两次读数之间 frm_done 的差值可以判断 VIC 是否持续收到并处理帧；isp-w01、isp-m0 和 isp-fs 同理。
第一步：确认 Sensor 配置（isp-w00）
cat /proc/jz/isp/isp-w00
现场关键输出：
****************************** TISP SENSOR 0 INFO ****************************** ***** SENSOR 0 STATE ***** state name width height hts vts fps BUSY gc8613a 3840 2160 1200 2250 20 ***** SENSOR 0 DATA BUS ***** dbus_type dtype mipi_clk lanes hvflip MIPI LINEAR 1088 2 0 ****************************** TISP SENSOR 1 INFO ****************************** ***** SENSOR 1 STATE ***** state name width height hts vts fps BUSY gc5613s1 2880 1620 1200 2917 30 ***** SENSOR 1 DATA BUS ***** dbus_type dtype mipi_clk lanes hvflip MIPI LINEAR 846 2 0
应用两路都要求 20 fps，但 Sensor 1 的实际帧率是 30 fps。由此可以确认：
两路 Sensor 驱动都已注册，且已进入工作态（state=BUSY，即 stream on 后的状态）；
Sensor 0 的当前模式与预期一致；
Sensor 1 实际生效的帧率仍为 30 fps，与应用配置不一致。
继续核对 Sensor 驱动后，确认 Sensor 1 选用了错误的帧率模式（sboot配置）。修正该模式、使其与应用的 20 fps 一致后，isp-w00 中的 fps、vts 及相关 MIPI 参数与预期相符。
需要说明的是：这只是一个配置误差，修正它以后应用仍然无图，所以帧率模式并不是本次无图的直接原因。
第二步：确认链路是否真的有帧（isp-w01 / isp-w02 / isp-m0）
CSI（isp-w01）
cat /proc/jz/isp/isp-w01
异常现场输出：
****************************** TISP CSI INFO ****************************** dphy hosts sensors phy_rstz 1 2 2 1 ***** CSI MIPI LINK ***** host state sensor_ids 0 BUSY 0 1 BUSY 1 ***** CSI0 HOST INFO ***** clk_en frm_start frm_done err_cnt err1 err2 err_type ON 0 0 0 0x0 0x0 - ***** CSI1 HOST INFO ***** clk_en frm_start frm_done err_cnt err1 err2 err_type ON 0 0 0 0x0 0x0 -
两路 CSI host 的 clk_en 都是 ON，phy_rstz 也为 1，但 frm_start 和 frm_done 都停在 0。这说明 host 时钟打开只代表时钟路径已使能，并不等于 CSI 已经收到有效视频帧。同时 CSI 侧没有报告 err1/err2 错误（err_type 为 -），说明尚未采样到 CSI 时序/配置类错误。
VIC（isp-w02）与 ISP Core（isp-m0）
cat /proc/jz/isp/isp-w02 cat /proc/jz/isp/isp-m0
两路 Sensor 在 VIC 的 frm_start、frm_done、通道 done 和 DMA 中断均为 0，错误计数也没有增加。ISP Core 的关键计数同样全部为 0：
frameNum ch0done ch1done ch2done 0 0 0 0 sensor frameNum ch0done ch1done ch2done 0 0 0 0 0 1 0 0 0 0 errorNum value errCh0Crop errCh1Crop errCh2Crop errFraStart 0 0 0 0 0 0
至此，链路判断已经比较明确：
Sensor 已进入工作态（BUSY） ↓ CSI host 时钟已打开（clk_en=ON） ↓ CSI frm_start/frm_done = 0 ← 断点在这里 ↓ VIC frm_start/frm_done = 0 ↓ ISP Core frameNum/ch_done = 0
也就是说，帧在到达 CSI 之前、或恰好卡在 CSI 入口处就没有了。因此不需要优先去查编码器和用户态 buffer，故障范围被收敛到了 CSI 及其上游。
关于节点判据的小结：
state=BUSY、clk_en=ON只能说明 Sensor 和 CSI 时钟已就绪，不能证明数据链路上有帧通过；判断是否真有帧，必须看
frm_start/frm_done这类累计计数是否持续增加；上游计数在增长、下游计数为 0 的位置，就是第一嫌疑模块。
4、根因：内核配置文件与平台不匹配
核对启动镜像后发现，现场烧录的内核是用 Goat 内核配置文件（PRJ009_goat_defconfig）编译的，而这块板卡对应的是 Vela 内核配置文件（PRJ009_vela_defconfig）。两者并非同一内核的不同版本，而是 PRJ009 面向不同板卡的两套内核配置文件，主要差异在于 board 选择：
CONFIG_PRJ009_BOARD_GOAT=y CONFIG_PRJ009_BOARD_VELA=y CONFIG_BOARD_NAME="Goat" CONFIG_BOARD_NAME="Vela"
board 不同会进一步决定加载不同的板级/设备树配置。多摄数据链路依赖与板卡匹配的这套配置；烧录了不匹配的 Goat 内核配置文件后，多摄链路无法建立，于是出现“Sensor 能识别、时钟已打开，但没有任何帧进入 ISP”的现象。
误用平台内核时，典型现象是：
Sensor 驱动可以正常识别，isp-w00 仍能显示 Sensor 信息且状态为 BUSY；
isp-w01 的 clk_en 可能显示为 ON；
但 CSI frm_start/frm_done 始终为 0，不随时间增加；
VIC 和 ISP Core 的计数全部保持为 0；
应用侧最终表现为取帧或编码超时。
因此，Sensor 已识别、CSI 时钟已打开、应用初始化成功 都不能作为“内核与平台匹配”的依据。多摄无帧问题必须同时核对：
当前启动使用的内核配置文件是否与板卡平台匹配；
Sensor 的 mode、分辨率和帧率配置；
多摄对应的 CSI / VIN / VIC 支持配置；
节点计数是否从 CSI 开始持续增加。
将 Goat 内核配置文件更换为 Vela 内核配置文件，并修正 Sensor 1 的帧率模式后，重新读取节点，可以看到 CSI、VIC 和 ISP Core 的帧计数开始持续增长，应用恢复正常获取双路视频帧。
5、修复后的验证方法
修复后重新执行：
cat /proc/jz/isp/isp-w00 cat /proc/jz/isp/isp-w01 cat /proc/jz/isp/isp-w02 cat /proc/jz/isp/isp-m0 cat /proc/jz/isp/isp-msca cat /proc/jz/isp/isp-ivdc cat /proc/jz/isp/isp-fs
重点确认：
isp-w00 中两路 Sensor 的 fps 与应用配置一致；
isp-w01 中两路 CSI 的 frm_start 和 frm_done 持续增加；
isp-w02 中 VIC 的 frm_start、frm_done 和通道 done 持续增加；
isp-m0 中 frameNum、每路 Sensor 的 frame done 和 channel done 持续增加；
isp-fs 中输出通道的 qbufs、done、dqbufs 持续增加，lost 和 error 不再增加。
正常出流时的参考示例
isp-w00 中两路 Sensor 的模式和帧率与应用设置一致：
state name width height hts vts fps BUSY gc8613a 3840 2160 1200 2250 20 BUSY gc5613s1 2880 1620 1200 2915 20
isp-w01 中 CSI 两路 host 都收到帧（frm_start/frm_done 同步且持续增长）：
host clk_en frm_start frm_done err_cnt err_type 0 ON 65 64 0 - 1 ON 65 65 0 -
isp-w02 中 VIC 的帧中断和通道完成计数开始增长：
sensor frm_start frm_done err_cnt ch0 done ch1 done 0 64 63 0 63 63 1 65 65 0 65 65
isp-m0 中 ISP Core 已持续处理两路输入：
frameNum ch0done ch1done ch2done 341 329 329 0 sensor frameNum ch0done ch1done ch2done 0 170 165 165 0 1 171 164 164 0
Frame Source 的正常输出通道可以看到 buffer 持续完成并出队。以两路子码流通道（每路 Sensor 的 ch1）为例：
FS CH01 state BUSY stream ON qbufs 287 done 285 dqbufs 285 lost 0 error 0 FS CH04 state BUSY stream ON qbufs 287 done 285 dqbufs 285 lost 0 error 0
主码流对应的 FS 通道（每路 Sensor 的 ch0）应满足相同规律：state=BUSY、stream=ON，且 done、dqbufs 随时间增加。不同应用创建的通道编号可能不同，应以实际 framechan 和 isp-fs 输出为准。
使用 MSCA 输出路径时，isp-msca 中应看到已开启的 Sensor/CH 块，满足：stream=ON、channeldone 持续增加、out_w/out_h 与通道配置一致、qbuf/bbuf 中有正在等待或处理的 buffer、buf_done 随 frame-done 事件增加。
使用 direct/IVDC 路径时，重点看 isp-ivdc 的 isp_start、isp_done、vpu0_done、vpu1_done 是否持续增加，同时 work_to、wait_to、frm_lost、y_ddr、c_ddr 保持不变。
正常出流时，两次间隔 1 秒的节点采样应呈现如下趋势：
CSI frm_done 增加 VIC frm_done 增加 ISP frameNum 增加 ISP chxdone 增加 MSCA channeldone 增加，或 IVDC done 增加 FS done/dqbufs 增加 lost/error/timeout 保持不增加
这与错误内核下的状态形成鲜明对比：错误内核下虽然 isp-w00 仍显示 Sensor 为 BUSY、isp-w01 的 clk_en 也可能为 ON，但 CSI、VIC 和 ISP Core 的帧计数会一直停在 0，应用最终表现为无图或取流超时。
最终排查链路可以概括为：
isp-w00：Sensor 配置是否正确 ↓ isp-w01：CSI 是否收到帧 ↓ isp-w02：VIC 是否完成帧处理 ↓ isp-m0：ISP Core 是否持续处理 ↓ isp-msca/isp-ivdc：输出路径和 buffer 是否正常 ↓ isp-fs：用户态 buffer 是否完成和出队 ↓ 编码器或用户态 DQBUF
6、结论
本次问题由两个相互独立的配置错误组成：
帧率配置错误：Sensor 1 选用了错误的帧率模式，导致 isp-w00 显示的帧率与应用设置不一致；该问题与无图无直接因果关系。
内核配置文件与平台不匹配：多摄场景误用了 Goat 内核配置文件，应改用 Vela 内核配置文件。这是本次无图的直接原因。
借助 /proc/jz/isp/ 节点，可以按 “Sensor → CSI → VIC → ISP Core → 输出 → Frame Source” 的顺序快速缩小范围。遇到多摄启动后无帧时，除了检查 Sensor 和 MIPI 参数，应优先确认当前烧录的内核配置文件是否与板卡平台匹配。