RK3576 BSP 摄像头 Bring-up 实战：从 IMX585 点亮到 ISP、3A 与视频流稳定输出

原创于 2026-05-03 21:11:18 发布 · 762 阅读

12 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#接口隔离原则 #c语言 #开发语言 #ai #服务器

rockchip 专栏收录该内容

18 篇文章

订阅专栏

该文章已生成可运行项目，

📺 B站嵌入式孙老师：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

RK3576 BSP 摄像头 Bring-up 实战：从 IMX585 点亮到 ISP、3A 与视频流稳定输出

在 Rockchip 平台上调一颗 IMX585，表面看是“加一个摄像头驱动”，实际做的是一条完整视频链路的 BSP 适配。

这条链路不是只有 sensor，也不是只有 ISP，更不是只改一个 JSON 就能稳定跑。真正的核心是：

Sensor 能不能稳定出 RAW
DTS 有没有把硬件链路描述对
ISP/rkaiq 能不能正确处理 RAW
3A 能不能控制曝光和白平衡
应用层能不能持续拿到 buffer

整条链路可以这样看：

IMX585 Sensor
   ↓ MIPI CSI-2 RAW10 / RAW12
RK3576 MIPI CSI / DPHY
   ↓
RK3576 ISP
   ↓
rkaiq / 3A server
   ↓
V4L2 / VI / Rockit / GStreamer
   ↓
VPSS / VENC / VO
   ↓
预览、编码、录像、推流

一句话：BSP 的目标不是“驱动 probe 成功”，而是让这条链路稳定、有图、有帧、有画质。

在这里插入图片描述

1. IMX585 在 BSP 里到底是什么角色？

IMX585 是 Sony 的 4K 大底图像传感器。它输出的不是 JPEG，也不是 H.264，而是 RAW 数据。

它负责：

感光
曝光
增益
输出 RAW10 / RAW12
通过 MIPI CSI-2 把图像送给 SoC

它不负责：

白平衡
颜色校正
降噪
锐化
H.264/H.265 编码
显示
推流

这些后面的事情由 RK3576 的 ISP、rkaiq、VENC 和应用层完成。

所以从 BSP 角度看，IMX585 驱动的核心任务是：

上电
复位
给时钟
I2C 初始化
配置寄存器
打开 stream
输出稳定 MIPI RAW 数据

2. 第一层：硬件电源和 Reset 是基础

IMX585 不是单电源 sensor，它有三路核心电源：

DVDD 1.1V：数字核心电源
OVDD 1.8V：接口 IO 电源
AVDD 3.3V：模拟电源

在板级原理图里通常对应：

CAM_1V1_S0 → DVDD
CAM_1V8_S0 → OVDD
CAM_3V3_S0 → AVDD

IMX585 datasheet 推荐的上电顺序是：

1.1V → 1.8V → 3.3V

很多板子为了省控制脚，会用一个 PWREN_H 同时打开三路电源：

PWREN_H 拉高
   ↓
1.1V DC-DC 启动
1.8V LDO 启动
3.3V LDO 启动

这在原理图上看是“同时使能”，但实际电压谁先起来，要看电源芯片软启动、电容、负载和 EN 阈值。

这就是 BSP bring-up 里很容易被忽略的坑：软件时序写得再漂亮，如果电源实际波形不对，sensor 也可能偶发失败。

调试时必须测：

PWREN_H
CAM_1V1_S0
CAM_1V8_S0
CAM_3V3_S0
RST_H / XCLR
PWDN
INCK / MCLK

特别要确认：

三路电源电压正确
Reset 极性正确
PWDN 极性正确
INCK 有稳定时钟
I2C 电平正常

3. 第二层：DTS 不是摆设，它决定硬件链路

IMX585 的高速图像数据走 MIPI CSI-2。MIPI 高速 lane 不是 GPIO，不能像普通控制脚那样写。

控制脚用 GPIO：

reset-gpios = <&gpioX RK_Pxx GPIO_ACTIVE_HIGH>;
pwdn-gpios  = <&gpioX RK_Pxx GPIO_ACTIVE_HIGH>;
power-gpios = <&gpioX RK_Pxx GPIO_ACTIVE_HIGH>;

高速 lane 用 endpoint 描述：

data-lanes = <1 2 3 4>;

这表示 sensor 使用 4 条 MIPI data lane，对应原理图里的：

CSI0_RX_D0P/N
CSI0_RX_D1P/N
CSI0_RX_D2P/N
CSI0_RX_D3P/N
CSI0_RX_CLKP/N

DTS 里最关键的是这几类信息：

compatible
reg，也就是 I2C 地址
clocks / xvclk
reset-gpios / pwdn-gpios / power-gpios
data-lanes
link-frequencies
remote-endpoint
mipi dphy 节点
rkisp 节点
camera-module-name
camera-module-lens-name

其中 camera-module-name 和 camera-module-lens-name 很重要，因为 rkaiq 通常会根据这些字段拼出 IQ 文件名。例如：

rockchip,camera-module-name = "CMK-IMX585-PX1";
rockchip,camera-module-lens-name = "FH34SRJ-30SCK0";

它可能会去找：

imx585_CMK-IMX585-PX1_FH34SRJ-30SCK0.json

如果 DTS 名字和 IQ 文件名不匹配，sensor 可能能出 RAW，但 rkaiq 找不到 IQ，3A 就跑不起来。

4. 第三层：kernel sensor driver 负责“吐 RAW”

IMX585 驱动的核心不是 probe 成功，而是这几个能力完整：

power_on / power_off
reset / pwdn 控制
xvclk 控制
I2C 读 chip id
寄存器表初始化
stream on / stream off
曝光控制
模拟增益控制
数字增益控制
VTS / HTS 控制
frame interval / fps 控制

典型启动流程：

power on
reset low
enable clock
reset high
I2C read chip id
write mode registers
set format
stream on

驱动里最敏感的参数有：

width / height
HTS
VTS
pixel_rate
link_freq
line_time
exposure_min / exposure_max
gain_min / gain_max
vblank
hblank

例如日志：

hts=4400 vts=13896 line=7407ns vblank_lines=11716

可以解读为：

HTS：一行总时钟长度
VTS：一帧总行数
line：一行时间
vblank_lines：垂直空白行数

帧率大概由：

frame_time = VTS × line_time
fps = 1 / frame_time

决定。

所以如果当前实际是 10fps，但 IQ/3A 里写 60fps，就可能导致 AE 预期和实际 sensor 时序不一致，进一步引发出帧异常、曝光异常，甚至应用层等待 buffer。

5. 第四层：ISP 不是可选项，RAW 必须经过它

IMX585 输出的是 RAW。RAW 直接看一般是偏色、偏暗、噪声大、没有正常色彩的。

RK3576 的 ISP 负责把 RAW 变成正常图像：

BLC 黑电平校正
LSC 镜头阴影校正
Demosaic
AWB 白平衡
CCM 颜色矩阵
Gamma
降噪
锐化
HDR
色彩处理

所以 ISP 决定“图像好不好看”。

而 sensor driver 决定“有没有 RAW”。

二者关系是：

imx585.c：负责 sensor 出 RAW
rkisp：负责接收 RAW
rkaiq：负责计算 ISP 和 sensor 参数
IQ JSON：负责提供默认标定参数

6. 第五层：3A server 不是只设置 ISP

很多人会以为 3A server 只是 ISP 参数配置。其实更准确地说，它同时控制 sensor 和 ISP。

3A server 的工作循环是：

ISP 统计当前画面亮度/颜色
   ↓
rkaiq 运行 AE/AWB/AF 算法
   ↓
AE 下发曝光和增益到 sensor
AWB 下发白平衡和颜色参数到 ISP
AF 如果有马达，下发对焦位置
   ↓
下一帧继续修正

AE 主要影响：

exposure
analogue_gain
digital_gain
vblank / vts

AWB 主要影响：

R/G/B gain
CCM
色温判断
颜色校正

所以一个错误的 IQ JSON，不只是“颜色难看”，也可能影响 sensor 的曝光、帧长、HDR 模式，从而影响视频流是否稳定。

7. 第六层：IQ JSON 是 BSP 里最容易被误解的文件

imx585_xxx.json 不是 sensor 驱动，也不是编解码器参数。它是 rkaiq 的 IQ 配置文件。

它通常包含：

sensor_calib
module_calib
main_scene
  normal
  hdr
    scene_isp39
      ae_calib
      wb_v32
      ablc
      ccm
      lut3d
      debayer
      gamma
      noise reduction
      sharp

其中：

sensor_calib：告诉 rkaiq sensor 的曝光/增益/HDR/DCG 模型
module_calib：镜头、光圈、IR-cut 等模组信息
ae_calib：自动曝光策略
wb_v32：自动白平衡参数
ablc：黑电平
ccm：颜色矩阵
lut3d：3D LUT
debayer：RAW 转 RGB 相关参数

这里有一个非常实际的问题：如果没有 IMX585 专用 IQ，能不能拿 IMX415 的 JSON 改名？

答案是：可以临时跑，但有风险。

IMX415 和 IMX585 都是 Sony 4K 8MP 方向，IMX415 的 ISP39 JSON 是最接近的临时参考。但它不能当正式 IQ，因为：

黑电平不同
噪声模型不同
AWB 标定不同
CCM 不同
LSC 不同
HDR/DCG 不同
曝光路线不同

临时 JSON 最危险的字段包括：

CISHdrSet
AecFrameRateMode
Gain2Reg
Time2Reg
CISGainSet
CISTimeSet
CISDcgSet

如果 JSON 里默认：

"hdr_en": 1

但驱动实际跑 linear 模式，就可能造成 ISP/rkaiq 预期不一致。

如果 JSON 里写：

"FpsValue": 60

但驱动实际只有 10fps，也会让 AE 和实际时序不一致。

临时 bring-up 建议保守：

先关 HDR
先固定实际 fps
先让 linear 模式稳定出帧
先验证 V4L2 裸流
再打开 rkaiq
最后跑 GStreamer

8. 第七层：GStreamer 卡住，往往不是 GStreamer 的锅

当 GStreamer 卡住，很多人第一反应是 pipeline 写错了。实际 BSP 调试里，更常见的是底层没有稳定输出 buffer。

典型路径是：

GStreamer 等待 /dev/videoX buffer
   ↓
video node 没有帧
   ↓
ISP 没有正常输出
   ↓
MIPI 没收到帧 / rkaiq 配置异常 / sensor stream 异常

排查顺序不要反过来。建议按这个顺序：

先看 media 拓扑

media-ctl -p

确认链路是：

imx585 → dphy/csi → rkisp → video node

再看不跑 rkaiq 是否出帧

killall rkaiq_3A_server
killall rkaiq_tool_server

v4l2-ctl --stream-mmap --stream-count=100 -d /dev/videoX

如果这里都卡住，问题在 sensor/MIPI/ISP/DTS，不在 3A。

再打开 rkaiq

rkaiq_3A_server &

看日志：

dmesg -w | grep -Ei "imx585|rkisp|rkaiq|csi|mipi|timeout|frame"

如果不开 rkaiq 能出帧，开 rkaiq 后卡住，就重点怀疑：

IQ JSON
HDR 配置
AE 帧率
曝光/增益换算
VTS 更新
ISP 统计配置

9. 第八层：Rockit 和 GStreamer 是应用层，不负责点亮 sensor

Rockit 文档里会讲 VI、VPSS、VENC、VO 这些模块。它们很重要，但它们不是 sensor bring-up 的第一现场。

Rockit 的位置是：

ISP/rkaiq 已经输出图像
   ↓
VI 获取帧
   ↓
VPSS 缩放/裁剪/旋转/格式转换
   ↓
VENC 编码 H.264/H.265/JPEG
   ↓
VO 显示或应用保存/推流

它不负责：

IMX585 电源
Reset
I2C 初始化
MIPI lane
DTS endpoint
IQ 调参
3A 算法

所以 Rockit/GStreamer 是验证视频链路最终是否可用的工具，而不是解决 sensor 点亮的根因工具。

10. RK3576 上 IMX585 BSP 适配的完整 checklist

硬件层

1.1V / 1.8V / 3.3V 是否正常
电源上电顺序是否合理
reset/pwdn 极性是否正确
INCK/MCLK 是否存在
I2C 上拉是否正常
FPC lane 是否对应

DTS 层

I2C 地址是否正确
clock 是否正确
GPIO 是否正确
data-lanes 是否正确
remote-endpoint 是否正确
rkisp/csi/dphy 节点是否连通
camera-module-name 是否匹配 IQ 文件

驱动层

chip id 能否读到
寄存器表是否对应当前模式
HTS/VTS 是否正确
pixel_rate/link_freq 是否正确
exposure/gain control 是否正确
stream on/off 是否正常

ISP/3A 层

IQ 文件是否存在
IQ 文件名是否匹配
ISP 版本是否匹配，比如 isp39
linear/HDR 是否匹配
fps 是否匹配
AE/AWB 是否工作

应用层

v4l2-ctl 是否能取帧
GStreamer 是否能拿 buffer
Rockit VI/VENC 是否能编码
帧率是否稳定
长时间运行是否掉帧或卡住

11. 最终结论：BSP 的核心是“链路一致性”

IMX585 在 RK3576 上调试，最怕的不是某一层完全不懂，而是每一层都“差一点”：

DTS lane 看起来对，但 endpoint 没连好
I2C 能读 ID，但 MIPI 不出帧
sensor 能 stream on，但 ISP 没 buffer
IQ 能加载，但 HDR/fps 和驱动不匹配
GStreamer 能启动，但一直等帧

所以 BSP 的核心不是堆参数，而是让这些信息完全一致：

硬件原理图
DTS
sensor driver
sensor 寄存器模式
MIPI lane/link frequency
ISP 版本
rkaiq IQ JSON
3A server
应用 pipeline

真正稳定的 IMX585 方案应该是：

RK3576 + ISP39 + IMX585 + 当前镜头模组 + 当前驱动模式 + 当前 rkaiq 版本

📺 B站嵌入式孙老师：博主个人介绍

📘 博主书籍-京东购买链接*：Yocto项目实战教程

📘 加博主微信，进技术交流群： jerrydev

本文章已经生成可运行项目