将RK3588s/LubanCat4开发板IMX415摄像头官方4k30fps驱动修改为4K60fps完全指北
官方标准配置跑通(pipeline优化)
索尼的imx415 DATAsheet Vision Components 的通用 MIPI 驱动文档声称 IMX415 4lane RAW10 全幅理论/驱动可到接近 60fps。
SDK根目录下kernel/arch/arm64/boot/dts/rockchip/rk3588s-lubancat-4-csi.dtsi
摄像头控制节点定义
修改过后的Boardconfig
路径在sdk下的device/rockchip/rk3588/BoardConfig-LubanCat-3588-debian-xfce-imx415.mk
去掉其中的"-imx415"就是官方板级配置
IQ 文件就是给 ISP/3A 用的图像质量调参文件。驱动负责把 sensor 跑起来，IQ 文件负责让 ISP 把 RAW 处理成颜色、曝光、白平衡、降噪、锐化都比较正常的图像
黑电平校正 BLC 镜头阴影校正 LSC 坏点校正 DPC 去噪 NR 锐化 sharpness 颜色校正 CCM Gamma 白平衡 AWB 参数 自动曝光 AE 参数 自动对焦 AF 参数 色彩饱和度、对比度、亮度 不同光照环境下的调节曲线这些参数很多就放在IQ文件里
用以下几个指令可以确认当前生效的板级配置文件
官方4k30fps原始图像链路未优化
rendered 已经成功显示出来的帧数。也就是 sink 真正渲染到窗口/屏幕的帧。
dropped 因为来不及显示、时间戳太晚、队列策略等原因被丢掉的帧数。
current 最近一个统计窗口内的瞬时 FPS。它会波动，比如 18、22、30。
average 从 pipeline 开始运行到现在的平均 FPS。它会受到启动阶段、卡顿、网络抖动、解码慢等影响。此时没有达到30帧属于意料之中,因为这会用的还是传统的videoconvert,压力全部给到了cpu,想要跑满这个帧数,就要上瑞芯微提供的硬件加速
用v4l2的小工具可以查看当前raw原始图像源头的帧数
顺带一提,这里可以看到RG10的字样,意思是此时使用的raw流是每个像素点用10bit表示(1024个亮度等级)
在瑞芯微（Rockchip）平台摄像头链路里，RKCIF（Rockchip Camera Interface）就是 Rockchip SoC 内部的摄像头接口控制器驱动模块。
RKCIF 负责接收 Sensor/MIPI CSI 送来的图像数据，并通过 DMA 搬运到内存，向 V4L2 框架提供 video 节点。
把指令修改为MPP硬编码
gst-launch-1.0 -e v4l2src device=/dev/video11 \ ! video/x-raw,format=NV12,width=1024,height=576,framerate=30/1 \ ! mpph264enc \ ! h264parse \ ! rtph264pay config-interval=1 pt=96 \ ! udpsink host=192.168.10.87 port=5000 sync=false async=false此时预览终于达到了官方标称的30fps
此时可以证明
IMX415 CAM0 以官方 4K30 模式完成采集链路验证
RKCIF RAW10 3864x2192 与 RKISP NV12 3840x2160 均实测 30fps。
可以开始卷帧数了
帧数优化过程:
思路:
新增更高帧率 mode table
调整 VMAX/HMAX
提高 MIPI link frequency
更新驱动里的 max_fps、vts_def、hts_def、mipi_freq_idx、寄存器表
调整 VMAX/HMAX
当前官方配置
reg_list = imx415_linear_10bit_3864x2192_891M_regs width/height = 3864x2192 RAW = RAW10 VMAX = 0x08ca = 2250 HMAX = 0x044c = 1100 max_fps = 30fps mipi_freq_idx = 14K 模式高度是 2192，当前 VMAX=2250，驱动注释要求 VMAX >= height + 46，也就是最低约 2238，几乎没空间靠减 VTS 提帧率。所以真正要动的是 HMAX，必要时还要提高 MIPI lane rate。
更准确一点：
参数 含义 影响 HMAX 每一行的总时钟数，也就是一行的周期 行时间、总帧率、MIPI 输出压力 VMAX 每一帧的总行数，也就是一帧包含多少行 帧时间、帧率、最大曝光时间 hblank 水平消隐，约等于 HMAX - active_width 的驱动表达 一行里非有效像素区域 vblank 垂直消隐，等于 VMAX - active_height 一帧里非有效图像行 帧率大致由它们共同决定：
fps ≈ 时钟 / (HMAX * VMAX)
我参考了这个大佬的github仓库(https://github.com/tipoman9/imx415_modes) IMX415 驱动里写了4K30 改 HMAX 可到 35/36fps，最高“37 possible”。
当前 Rockchip 官方： VMAX = 0x08CA = 2250 HMAX = 0x044C = 1100 约 4K30
第三方参考： HMAX = 0x03B0 = 944，注释写 35fps HMAX = 0x0390 = 912，注释写 36fps
换算也对得上：
1100 * 30 / 35 ≈ 943
打开驱动源代码,我的路径是~/rk3588/lubancat_rk3588_sdk/kernel/drivers/media/i2c/imx415.c
首先修改寄存器 HMAX
官方原寄存器设置,在DATAsheet中是这样定义的
把 HMAX 从 0x044C 改成 0x03B0：
{0x3024, 0xCA}, {0x3025, 0x08}, {0x3028, 0xB0}, {0x3029, 0x03},0x3024/0x3025 是 VMAX，先不要动。
下一步是修改mode参数
找到
修改两处
.denominator 从300000 改为 350000
.hts_def 从0x044c 改为 0x03b0
成功力!
然后进一步尝试追加消隐值看加到40fps会发生什么
过程同上,具体参数为
寄存器表:
{0x3028, 0x39}, {0x3029, 0x03}, // HMAX = 0x0339mode:
.denominator = 400000, .hts_def = 0x0339 * IMX415_4LANES * 2,果不其然,失败了
出现这个现象简单来说是因为只减少水平 blanking，没有同步提升 MIPI lane rate 和 D-PHY timing，导致 sensor 输出时序超过当前 891Mbps 工作点的稳定范围。
恢复到35fps的驱动
网络推流到我的虚拟机查看此时画面
画面正常,帧数提高,成功
尝试更高程度的优化
在索尼提供的imx415_datasheet中发现已经给出了支持4k60fps的寄存器配置,因此我尝试修改lubancat的imx415.c驱动
这是目前我SDK中的高频档位基础,可以看到还没有没有 4K60 线性寄存器表，但 link_freq_items 里已经有 MIPI_FREQ_891M，也就是 4K60 需要用的 1782Mbps 数据率基础。
定位当前 4K RAW10 mode 配置块
查出当前生效的mode
这就是我现在 35fps 的来源。 下一步就是修改驱动文件
第 4 步：对比寄存器表和mode配置
左边是旧寄存器表,左边是新表,这里在寄存器表中恢复了很多默认设置,然后把默认设置作为 1782M 基础，然后补必要的 RAW10、曝光、模拟/校准推荐值。
在mode中切换到高频协议,再查datasheet给了合法的 1782Mbps operating mode；驱动要做的是让 sensor 发端、RK3588 DPHY 收端、RAW10 格式描述三者完全一致。
切换通信频率的具体寄存器配置写在0x3033位
根据 IMX415 datasheet All-pixel mode / CSI-2 serial / 4lane 表，IMX415 在 4lane RAW10 场景下支持 1782Mbps/lane 数据率，对应 60fps、HMAX=0x0226、VMAX=0x08CA、SYS_MODE=0x04 的工作模式。
关键寄存器对比
| 寄存器 | datasheet 含义 | 35fps | 4K60 | 说明 |
|---|---|---|---|---|
| 0x3024~0x3026 | VMAX，一帧总行数 | 0x08CA | 0x08CA | 4K60 没靠减少帧行数提速 |
| 0x3028~0x3029 | HMAX，一行周期 | 0x03B0 | 不写，默认 0x0226 | 核心之一，4K60 用更短行周期 |
| 0x3031 | ADBIT，内部 ADC 位宽 | 0x00 | 0x00 | 都是 10bit |
| 0x3032 | MDBIT，CSI 输出位宽 | 0x00 | 0x00 | 都是 RAW10 |
| 0x3033 | SYS_MODE，MIPI 数据率模式 | 0x05 | 不写，默认 0x04 | 核心之一，0x05=891Mbps，0x04=1782Mbps |
| 0x4001 | LANEMODE，2lane/4lane | 默认 4lane | 默认 4lane | CAM0 仍是 4lane |
| 0x400C | INCKSEL6 | 0x00 | 不写，默认 0x01 | 891M 和 1782M 档位不同 |
| 0x4074 | INCKSEL7 | 0x01 | 不写，默认 0x00 | 891M 和 1782M 档位不同 |
| 0x4018~0x4028 | MIPI D-PHY timing | 891M 对应值 | 不写，默认 1782M 对应值 | 很重要，决定高速 MIPI 时序 |
| 0x3050~0x3052 | SHR0，曝光/快门时间 | 0x0008 | 0x0384 | 影响默认曝光，不是帧率主因 |
根据以上内容修改好imx415.c驱动,编译后烧录extboot,开发板上电测试 raw原始出流
v4l2-ctl -d /dev/video0 \ --set-fmt-video=width=3864,height=2192,pixelformat=RG10 \ --stream-mmap=4 \ --stream-count=600 \ --stream-poll
测 ISP 4K60 实际输出
然后网络推流到电脑查看画面有无撕裂模糊,但是传输可能编码/网络/虚拟机解码显示链路损耗,实际出流已经有60fps了
中途遇到的问题
使用官方4k30fps设备树以及iq文件配置,实际4k出帧只有5fps
用v4l2-ctl实测官方 IMX415 4K30 RAW 采集链路达到 30fps,
很可能是 ISP 输出模式/带宽/驱动默认配置/3A 参数链路在 4K mainpath 下限制住了。因为只要降到 2560x1440 就能回到 30fps，说明整条链路不是整体性能不够，而是 4K mainpath 触发了某个特殊限制。
dmesg 里有大量：
rkisp0-vir0: MIPI drop frame
说明RKISP mainpath 在 4K 输出时消费不过来/配置不对，导致丢帧，最终 /dev/video11 只有 5fps。
解决方法:
强制设置 4K crop 再测
pkill -f gst-launch-1.0 v4l2-ctl -d /dev/video11 \ --set-fmt-video=width=3840,height=2160,pixelformat=NV12 v4l2-ctl -d /dev/video11 \ --set-selection=target=crop,left=0,top=0,width=3840,height=2160 v4l2-ctl -d /dev/video11 --all然后再测试
效果绝佳,说明:之前 5fps 不是 RKISP 4K 跑不动，而是/dev/video11 的 V4L2 状态残留/裁剪配置不一致。
出现这种问题原因是之前我用 HDMI 预览测过 1024x576/1280x720，驱动里残留了一个低分辨率输出 + 1920x1080 crop的状态。后来 GStreamer 虽然 caps 写了：width=3840,height=2160
但它没有可靠地把 V4L2 selection/crop 一起重置到 4K 全幅，导致 ISP mainpath 处在一个不干净的配置状态，表现就是：rkisp0-vir0: MIPI drop frame /dev/video11 4K 只有 5fps
把分辨率降低并通过网络udp推流之后预览,此时
2.修改后仍然30fps
在30->35fps优化过程中,曾今遇到确实改了 .max_fps 和 .hts_def，但是不管怎么测raw出流都是30fps,后来定位到问题在于:
真正写进 sensor 的 4K 891M 寄存器表还没改。
我把前面另一个表的 0x3028/0x3029 改成了 0x03B0，后面的当前 mode 专用表又把它覆盖回 0x044C，所以实际输出仍然 30fps。(简单来说就是改成12bit表了,但是4k用的是raw10)
附录:
1.raw10和raw12有什么区别
RAW10和RAW12的核心区别就是：
每个像素点保存的原始亮度数据位数不同。
RAW10：每个 Bayer 像素 10 bit RAW12：每个 Bayer 像素 12 bit
这里的 “像素” 不是完整 RGB 像素，而是 Bayer RAW 里的一个采样点，比如 R/G/B 中的一个分量。
同一个光强变化，RAW10 只能分成 1024 档，RAW12 可以分成 4096 档。
所以理论上：
RAW12 的动态范围、后期调节空间、ISP 处理余量更好。
但注意，是“理论上”。实际画质还要看 sensor 噪声、镜头、ISP、IQ 参数。
2. 什么是 3A？
3A 是三个自动控制算法的统称：
AE：Auto Exposure，自动曝光 AWB：Auto White Balance，自动白平衡 AF：Auto Focus，自动对焦
对 IMX415 这种常见板载模组来说，通常重点是AE 和 AWB。因为很多 IMX415 模组是定焦镜头，没有马达，所以 AF 不一定有用。
ISP 负责把 RAW 图处理成正常 YUV/RGB 画面； 3A 服务负责根据画面统计信息动态调 sensor 和 ISP； IQ 文件负责给 3A/ISP 提供一套“调图参数”
AE：自动曝光
AE 的目标是让画面亮度合适。
它会根据当前画面的亮度统计信息，动态调这些东西：
曝光时间 exposure 模拟增益 analog gain 数字增益 digital gain 光圈 iris，如果硬件有
比如画面太暗，AE 可能会：
增加曝光时间 增加 sensor gain 提高 ISP gain
画面太亮，就反过来降低。
在驱动里常见的这些控制项：
V4L2_CID_EXPOSURE V4L2_CID_ANALOGUE_GAIN V4L2_CID_VBLANK
很多时候就是 AE 服务最终要调的东西。
所以做 IMX415 高帧率时，AE 会受影响。因为把 VMAX 降低后，每帧时间变短，最大曝光时间也会变短。例如：
60fps：一帧约 16.67ms 75fps：一帧约 13.33ms 90fps：一帧约 11.11ms
所以高帧率模式下，画面更容易暗。这不是 3A 坏了，而是曝光上限变短了。
AWB：自动白平衡
AWB 的目标是让颜色正常。
不同光源颜色不一样：
太阳光偏自然 白炽灯偏黄 冷白 LED 偏蓝/绿
sensor 采出来的 RAW 图本身只是 Bayer 数据，红绿蓝比例不一定舒服。AWB 会根据图像统计信息计算 R/G/B 增益，让白色物体看起来接近白色。
如果 AWB 没跑起来，常见现象是：
画面发绿 画面发紫 画面偏蓝 画面偏黄 颜色很怪
很多 Rockchip 摄像头项目里，“能出图但颜色怪”，不一定是 sensor 驱动错了，而是IQ 文件不匹配或 rkaiq_3A_server 没跑起来。
AF：自动对焦
AF 的目标是让画面清晰。
但 AF 必须硬件支持镜头马达，比如 VCM。算法根据清晰度统计值调整镜头位置。
IMX415 模组很多是定焦镜头，所以你这个项目里可以先把 AF 放后面。面试里可以说：
IMX415 当前模组为定焦镜头，项目重点关注 AE/AWB 以及 ISP IQ 参数匹配。