1. 项目概述为什么Rockchip平台上的HAL3相机开发值得深挖在嵌入式Android设备领域尤其是智能终端、工业视觉、车载影像和边缘AI盒子这类对图像质量、低延迟和硬件协同要求极高的场景里“能用相机”和“用好相机”之间隔着一整条产线调试的沟壑。我做过不下20个Rockchip平台的相机项目——从RK3288到RK3566、RK3588再到最新的RK3576每一次把OV5695、IMX335、GC2053这些Sensor点亮都不是简单改个dts就能完事。真正卡住团队进度的从来不是Sensor datasheet读不懂而是HAL3层那套看似标准、实则高度平台定制的抽象机制它既不像HAL1那样直白也不像V4L2那样贴近驱动而是在Binder IPC、gralloc buffer管理、metadata传递、request pipeline调度之间织了一张细密的网。你改一行CameraDeviceClient的onResult回调可能影响帧率稳定性调一个setEntryMetadata的参数顺序会导致AE/AWB收敛失败甚至只是把HAL层的buffer count从4改成6就可能触发SurfaceFlinger的deadlock。这不是玄学是Rockchip在Android AOSP基础上叠加的私有扩展、ISP tuning接口、以及对Android CTS Camera2 API兼容性做的大量胶水逻辑。所以这篇内容不讲“怎么编译Android源码”也不堆砌AOSP HAL3文档里的定义而是聚焦在RK平台真实产线中——从dts配置写错导致sensor根本不上电到logcat里看到HAL: request queue full却查不出是谁卡住了pipeline再到用adb shell dumpsys media.camera发现active stream config和实际预览分辨率对不上……这些每天都在发生的、让FAE和固件工程师抓狂的问题。关键词里反复出现的“调试”恰恰说明HAL3开发的终点不是编译通过而是每一帧图像都稳定、低延迟、符合ISP标定参数。如果你正在RK3566上适配一个支持HDRAF的双摄模组或者需要在RK3588上跑通USB UVCMIPI双路输入的混合相机架构又或者被客户投诉“扫码模糊”“夜景发绿”“切换前后摄黑屏2秒”那么这篇实战记录就是为你写的。它不假设你熟悉Binder线程池调度但会告诉你ICameraDeviceUser::notifyRequestError这个回调在RK平台里实际由哪个线程触发它不解释什么是android.hardware.camera2.params.StreamConfigurationMap但会手把手教你用adb shell service call media.camera 12命令绕过Java层直接验证HAL是否返回了正确的stream list它更不会回避Rockchip私有HAL库libcamera_client_rk.so里那些没文档的ioctl magic number。因为真正的HAL3开发从来不是照着AOSP写代码而是在Rockchip提供的二进制blob、patched kernel driver、以及一堆隐藏在vendor目录下的.mk文件之间找到那条能跑通request flow的缝隙。2. Rockchip HAL3整体架构与设计逻辑拆解2.1 RK平台HAL3分层模型AOSP标准与Rockchip私有层的真实映射Rockchip的HAL3实现并非完全遵循AOSP原生路径而是采用“标准接口私有实现”的混合架构。理解这一点是避免后续所有调试陷入迷宫的前提。整个数据流可以拆解为四个物理层级第一层是Kernel Driver层RK平台使用自研的rkisp1或rkisp2驱动框架取决于SoC型号它不直接暴露V4L2标准接口给HAL而是通过/dev/videoX节点提供一套Rockchip定制的ioctl控制集。比如标准V4L2的VIDIOC_S_FMT在这里被替换为RKISP1_VIDIOC_S_ISP_CFG其参数结构体rkisp1_isp_cfg里不仅包含分辨率还硬编码了ISP tuning参数索引、3A统计buffer地址、甚至ISP clock gating开关位。这意味着即使你HAL层代码完全符合AOSP规范只要ioctl参数构造错误kernel就会直接返回-EINVAL而log里只显示HAL: ioctl failed: Invalid argument根本不会告诉你错在哪一个bit。第二层是Vendor HAL层这是Rockchip真正动手的地方位于vendor/rockchip/common/hardware/camera目录下。它包含两个核心模块libcamera_client_rk.so负责与CameraService通信和librkcamerahal.so实际处理request dispatch。关键点在于librkcamerahal.so并不直接调用kernel ioctl而是通过一个叫CamHwItf的抽象接口与底层交互。这个接口的实现类CamHwItfRkisp里藏着所有Rockchip私有逻辑比如它会把AOSP的CaptureRequest中的CONTROL_AE_MODE转换成rkisp驱动能识别的ae_mode_t枚举并插入一段硬件时序补偿代码——当AE模式从ON切到OFF时自动插入2帧dummy exposure以避免ISP pipeline状态紊乱。这种细节在AOSP文档里绝不会提但在RK3566上适配IMX335时如果跳过这段补偿就会出现切模式后第一帧严重过曝。第三层是CameraService胶水层AOSP的frameworks/av/services/camera/libcameraservice在RK平台上被打了大量patch。最典型的是CameraService::connectDevice函数它在调用HAL open()之前会先读取/vendor/etc/camera/camera_config.xml从中提取sensor name、module id、以及一个叫hal_version的字段。这个字段决定了后续request pipeline走哪条路径hal_version1走老式同步request队列hal_version2才启用AOSP标准的异步burst mode。很多团队卡在“预览卡顿”就是因为误把hal_version设成1导致HAL层每个request都阻塞等待ISP完成而不是利用RK3588的多核ISP并行处理能力。第四层是App/Framework层这里看似标准实则暗藏陷阱。比如CameraCharacteristics.SENSOR_INFO_ACTIVE_ARRAY_SIZE这个key在RK平台返回的值不是Sensor原生分辨率而是经过ISP crop后的有效区域。如果你在App里用这个值计算AF区域结果AF框会偏移——因为RK的tuning tool默认启用了digital crop而HAL3 metadata里SENSOR_INFO_PRE_CORRECTION_ACTIVE_ARRAY_SIZE才是原始尺寸。这解释了为什么网络热词里频繁出现“相机标定”标定不只是为了矫正畸变更是为了对齐HAL层上报的坐标系与ISP实际处理的坐标系。提示不要迷信adb shell dumpsys media.camera输出的“Supported Hardware Level”。RK平台常把LIMITED设备上报为FULL只为通过CTS测试但实际不支持ANDROID_CONTROL_AVAILABLE_EFFECTS等高级特性。验证方法是用adb shell service call media.camera 10 i32 1getCameraCharacteristics拿到raw blob用xxd查看第0x124字节——该字节为0x03表示真FULL0x02才是LIMITED。2.2 Rockchip HAL3核心流程图从openDevice到frame callback的完整链路整个HAL3流程不是线性的而是一个由Binder IPC、HAL线程池、ISP中断、DMA buffer轮转共同驱动的状态机。我用RK3566OV5695的实际调试日志还原出关键节点openDevice阶段App调用CameraManager.openCamera()CameraService通过Binder调用HAL的openCamera()。此时HAL会加载/vendor/etc/camera/sensor_configs/ov5695.xml解析pinmux、power sequence、i2c addr调用rkisp1_v4l2_open()打开/dev/video0并执行RKISP1_VIDIOC_S_ISP_INITioctl初始化ISP寄存器分配gralloc内存池注意RK平台默认用ION allocatorbuffer count由gralloc_buffer_count属性控制而非AOSP的android.hardware.camera2.params.StreamConfigurationMap。若此处分配失败log显示HAL: gralloc alloc failed: No memory但实际是ION heap碎片化需重启device而非改HAL代码。configureStreams阶段App传入OutputConfiguration列表HAL将其转换为rkisp1_stream_config结构体。关键差异点AOSP要求stream config按size降序排列RK HAL却要求按pixel format升序YUV_420_SP YUV_422_SP JPEG若App请求IMPLEMENTATION_DEFINED格式RK HAL会强制映射为HAL_PIXEL_FORMAT_YCrCb_NV12并忽略App指定的usage flag最致命的是RK3566的HAL有个bug当同时配置preview1280x720和record1920x1080两个stream时若record stream的width*height preview width*heightHAL会错误地将preview buffer size设为record size导致preview画面拉伸。修复方法是在configureStreams()里手动swap两个stream的buffer size字段。submitRequest阶段App构建CaptureRequestCameraService序列化后通过Binder传给HAL。HAL的processCaptureRequest()函数执行解析CONTROL_AE_TARGET_FPS_RANGE转换为rkisp的fps_range_t并校验是否在sensor datasheet的max_fps范围内将STATISTICS_LENS_SHADING_MAPmetadata写入ISP的shading LUT RAM但RK HAL要求该map必须是16x12网格否则丢弃启动DMA调用RKISP1_VIDIOC_S_DMATX_CFG配置YUV buffer地址此时若地址未按64-byte对齐kernel log出现rkisp1_dmatx: invalid address但HAL层无提示。frame callback阶段ISP DMA完成中断触发HAL从/dev/video0读取v4l2_buffer填充CaptureResultmetadata通过ICameraDeviceUser::notifyResult()回调。这里有个隐蔽陷阱RK HAL的notifyResult()实现里会检查result-frame_number是否连续。若因ISP timeout导致某帧丢失HAL会主动丢弃后续3帧以“重同步”造成log里看到HAL: frame drop detected, reset sequence——但这不是bug是Rockchip为防止metadata错位设计的保护机制。注意RK平台HAL3的request_id和frame_number不是一一对应。HAL层会把多个App request batch成一个ISP jobframe_number由ISP hardware counter生成request_id由HAL软件计数器维护。因此当看到result-frame_number105但result-request_id102时不要慌这是正常batch行为。2.3 Rockchip私有扩展机制为什么标准AOSP HAL3代码在RK上必然失败Rockchip为兼容不同Sensor和ISP版本在HAL3中引入了三类私有扩展它们是所有调试问题的根源第一类Vendor Tag扩展AOSP的CameraMetadata只定义了ANDROID_*命名空间RK额外添加了RK_*和VENDOR_*。例如RK_ISP_TUNE_INDEX用于动态切换ISP tuning profileVENDOR_SENSOR_EXPOSURE_TIME_NS用于绕过AE算法直接设置曝光。这些tag必须在CameraCharacteristics里声明支持否则App调用setEntry()会静默失败。声明方式不是写XML而是在HAL的getCameraCharacteristics()函数里向characteristics对象插入entry// rk_camera_device.cpp if (mSensorName ov5695) { characteristics.insertEntry(ANDROID_REQUEST_AVAILABLE_CAPABILITIES, {ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MANUAL_SENSOR}); // 添加RK私有tag支持 characteristics.insertEntry(RK_ISP_TUNE_INDEX, {0, 1, 2}); // 支持profile 0/1/2 }没这行代码App里captureRequest.set(RK_ISP_TUNE_INDEX, 1)就无效。第二类HAL Property扩展RK HAL通过property_get(ro.vendor.camera.hal.version, ...)读取运行时配置。常见property包括ro.vendor.camera.isp.version2决定用rkisp1还是rkisp2驱动栈ro.vendor.camera.sensor.modenormal控制sensor初始化时加载哪套timing tablero.vendor.camera.debug.level3开启HAL层详细log级别3会打印每个request的metadata内容。这些property必须在/vendor/build.prop里预置不能在runtime修改。曾有团队试图用SystemProperties.set()动态修改结果HAL仍读取旧值——因为HAL在openCamera()时已缓存property后续不再刷新。第三类Binary Blob依赖RK3566及以后平台HAL3功能严重依赖/vendor/lib64/librkisp.so这个二进制库。它封装了ISP firmware加载、3A算法、LSC校准等核心逻辑。该库版本必须与kernel driver严格匹配librkisp.sov2.3.1只能配rkisp1driver v2.3.x若混用v2.2.x driverHAL在initIsp()时会返回-ENODEVlog只显示HAL: isp init failed没有更多线索。验证方法是用readelf -d /vendor/lib64/librkisp.so | grep NEEDED查看依赖的so版本再对比ls /lib/modules/$(uname -r)/extra/里的driver ko版本。3. 核心配置与调试实操要点详解3.1 dts配置从pinmux到clock的逐行解析Rockchip平台的camera dts配置是HAL3启动的第一道关卡90%的“sensor不识别”问题源于此。以RK3566OV5695为例关键节点i2c3和m0_camera必须精确匹配i2c3 { status okay; clock-frequency 400000; // OV5695最大支持400kHz超频会导致ACK失败 #address-cells 1; #size-cells 0; ov56953c { // I2C地址0x3c必须与sensor硬件跳线一致 compatible ovti,ov5695; reg 0x3c; clocks cru CLK_GMAC_PTP; // 这里是坑OV5695不需要GMAC clock应改为cru CLK_CIF_OUT clock-names xvclk; power-domains pmu RK3566_PD_VI; pinctrl-names default; pinctrl-0 cif_clk cif_data0 cif_data1 cif_data2 cif_data3 cif_hsync cif_vsync cif_reset cif_pwdn; iovcc-supply vcc3v3; // IO电压OV5695要求3.3V错接1.8V会烧毁 avdd-supply vcc1v2; // Analog电压必须1.2V±5%否则图像噪点飙升 dvdd-supply vcc1v2; // Digital电压同上 reset-gpios gpio0 12 GPIO_ACTIVE_LOW; // RESET引脚低电平有效 pwdn-gpios gpio0 13 GPIO_ACTIVE_HIGH; // PWDN引脚高电平有效 clock-frequency 24000000; // sensor xclk频率必须与datasheet一致 rockchip,camera-module-name ov5695_mipi; rockchip,camera-module-lens-name lg5007; }; }; m0_camera { status okay; rockchip,grf grf; rockchip,pmu pmu; rockchip,cru cru; rockchip,phy phy_mipi_dphy; rockchip,mipidphy mipidphy; rockchip,isp rkisp1; rockchip,sensor ov5695; rockchip,csi-port 0; // MIPI CSI port 0RK3566只有port0支持4-lane rockchip,lane-num 4; // 必须与sensor输出lane数一致OV5695是4-lane rockchip,phy-mbps 800; // 每lane速率OV5695最大800Mbps超频会link fail };关键陷阱解析clocks cru CLK_GMAC_PTP这是RK SDK默认模板的错误OV5695的xvclk必须接CLK_CIF_OUT否则sensor无法产生valid clockI2C通信虽能建立但i2cdetect能看到设备i2cget读寄存器却全0xFF。iovcc-supply vcc3v3OV5695的IO电压范围是2.7~3.6V但RK3566的vcc3v3实际输出3.35V略超上限。实测发现长期运行后sensor内部LDO失效图像出现水平条纹。解决方案是改用vcc3v03.0V或在dts里加regulator-min-microvolt 3000000约束。rockchip,phy-mbps 800OV5695 datasheet标称最大800Mbps但RK3566的MIPI PHY在高温下不稳定。我们产线测试发现750Mbps成功率99.9%800Mbps在50℃环境下降至82%。最终在dts里设为750并在HAL层setPhyRate()函数里硬编码该值避免runtime动态调整。实操心得dts修改后必须clean build kernel不能只make modules。因为rkisp1驱动编译时会读取dts生成rkisp1_platform_data结构体若dts变更未rebuild driverHAL层读到的lane_num仍是旧值导致mipi_csi_lane_enable()失败log显示rkisp1_csi: lane enable failed。3.2 HAL3代码移植从AOSP模板到RK适配的关键补丁Rockchip官方提供的HAL3代码如vendor/rockchip/common/hardware/camera是起点但绝非终点。以下是必须打的三个核心补丁Patch 1解决request queue overflow问题AOSP HAL3默认queue size为8RK3566的ISP pipeline深度为12当App连续submit 10个request时HAL层mRequestQueue满触发HAL: request queue full。标准做法是增大queue size但RK HAL有个bugqueue resize后mRequestQueue的mNextRequestID计数器未重置导致新request的request_id从旧值继续累加CameraService认为重复提交而丢弃。修复方法是在configureStreams()成功后强制重置计数器// rk_camera_device.cpp status_t RkCameraDevice::configureStreams( const VectorStreamConfiguration streams) { // ... 原有代码 if (ret OK) { // 关键修复重置request ID计数器 mNextRequestID 0; ALOGI(HAL: reset request ID after configureStreams); } return ret; }Patch 2修复metadata timestamp精度丢失AOSP HAL3要求ANDROID_SENSOR_TIMESTAMP精度为ns但RK ISP硬件counter只有μs级。HAL层直接用clock_gettime(CLOCK_MONOTONIC, ts)获取时间导致timestamp低位全0App里计算帧间隔出现巨大跳变。正确做法是读取ISP寄存器ISP_TSTAMP地址0x0124该寄存器存储硬件捕获时间戳// rkisp1_device.cpp uint64_t RkIsp1Device::getHardwareTimestamp() { struct rkisp1_stat_buffer stat_buf; int ret ioctl(mIspFd, RKISP1_VIDIOC_G_STAT_BUF, stat_buf); if (ret 0) { return stat_buf.tstamp; // 单位ns由ISP crystal clock生成 } // fallback to system time struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); return (uint64_t)ts.tv_sec * 1000000000ULL ts.tv_nsec; }Patch 3增加sensor mode动态切换支持OV5695支持多种分辨率模式1080p/720p/VGA但RK HAL默认只初始化一种。要支持runtime切换需扩展HAL接口// 新增HAL method status_t RkCameraDevice::setSensorMode(const char* mode_name) { if (strcmp(mode_name, 1080p) 0) { mSensorMode SENSOR_MODE_1080P; // 重新配置sensor timing table writeReg(0x300a, 0x00); // frame length high writeReg(0x300b, 0x05); // frame length low // reload ISP tuning for 1080p ioctl(mIspFd, RKISP1_VIDIOC_S_ISP_TUNE, mTune1080p); } else if (strcmp(mode_name, 720p) 0) { mSensorMode SENSOR_MODE_720P; writeReg(0x300a, 0x00); writeReg(0x300b, 0x03); ioctl(mIspFd, RKISP1_VIDIOC_S_ISP_TUNE, mTune720p); } return OK; }App通过CameraCharacteristics查询RK_SENSOR_SUPPORTED_MODES再调用setEntry(RK_SENSOR_MODE, 720p)触发切换。3.3 调试工具链实战从logcat到硬件probe的全栈排查Rockchip HAL3调试不是单点突破而是多工具协同的立体作战。以下是我在RK3588项目中沉淀的黄金组合工具1logcat分级过滤HAL3日志分散在多个tag必须组合过滤才能定位问题# 只看HAL层关键事件 adb logcat -b main -b system | grep -E (HAL|rkisp|camera_service) # 追踪request生命周期 adb logcat -b main | grep -E (processCaptureRequest|notifyResult|request_queue) # 查看ISP硬件状态 adb logcat -b events | grep isp关键技巧RK HAL的日志级别由ro.vendor.camera.debug.level控制level3会打印每个request的metadata内容但会产生海量log。建议先设为2只打印error/warning定位到问题后再临时设为3。工具2dumpsys深度分析adb shell dumpsys media.camera是HAL3的X光机但需懂如何解读# 获取当前设备状态 adb shell dumpsys media.camera 0 # 输出关键字段解析 # - Device state: CONFIGURED表示HAL已readyIDLE表示未open # - Active stream configs: 列出当前active stream若为空说明configureStreams失败 # - Request queue size: 显示HAL queue当前长度持续6说明App submit过快 # - Last error: 记录最近一次HAL error如HAL: ioctl failed: Device or resource busy曾遇到一个案例dumpsys显示Active stream configs为空但logcat无错误。用adb shell service call media.camera 10 i32 0getCameraCharacteristics拿到raw data发现ANDROID_SENSOR_INFO_ACTIVE_ARRAY_SIZE字段为0根源是dts里rockchip,camera-module-name拼写错误HAL找不到对应的tuning file。工具3硬件probe验证当软件层无log时必须上硬件I2C通信验证用i2cdetect -y 3确认OV5695在0x3c地址响应i2cget -y 3 0x3c 0x0000 w读sensor ID寄存器应为0x5695若返回0xffff说明I2C线路断开或电源异常。MIPI信号测量用示波器测MIPI clock lane通常为GPIO7_A0正常应有24MHz方波测data lane应有眼图。若clock正常但data无信号检查dts里rockchip,phy-mbps是否超限。ISP中断验证cat /proc/interrupts | grep rkisp确认rkisp1中断计数随预览帧率上升。若计数停滞说明ISP未收到DMA完成中断检查rkisp1_dmatx驱动是否加载。工具4自定义debug工具我开发了一个rk_cam_debug命令行工具集成在vendor bin目录# 查看HAL层buffer状态 rk_cam_debug --buffer-status # 强制触发一次AE算法 rk_cam_debug --trigger-ae # 导出当前ISP tuning参数到文件 rk_cam_debug --dump-tuning /data/vendor/camera/tune.bin源码基于RK提供的librkisp.soAPI比adb shell更直接。例如--buffer-status会调用rkisp1_get_buffer_info()返回每个buffer的phy addr、size、stateFREE/QUEUED/PROCESSING比logcat里HAL: buffer 0x12345678 in use直观得多。4. 全流程调试实战从零开始点亮OV5695的72小时记录4.1 Day1dts与kernel驱动联调——让sensor“呼吸”起来目标确保OV5695上电、I2C通信正常、MIPI link建立。Step 1验证电源时序OV5695上电时序要求严格PWDN拉高后RESET需保持低电平≥1ms再拉高。用逻辑分析仪抓GPIO波形发现RK3566的pwdn-gpios配置为GPIO_ACTIVE_HIGH但HAL层setPowerMode()函数里pwdn和reset的时序控制代码被注释掉了。恢复代码并修正delay// rk_sensor.cpp void RkSensor::setPowerMode(bool on) { if (on) { gpio_set_value(mPwdnGpio, 1); // PWDN high usleep(1000); // wait 1ms gpio_set_value(mResetGpio, 0); // RESET low usleep(2000); // wait 2ms gpio_set_value(mResetGpio, 1); // RESET high } else { gpio_set_value(mResetGpio, 0); gpio_set_value(mPwdnGpio, 0); } }Step 2I2C通信调试i2cdetect -y 3能看到0x3c但i2cget -y 3 0x3c 0x0000 w返回0xffff。检查原理图发现OV5695的SDA/SCL线上有4.7kΩ上拉电阻但RK3566的I2C3控制器内部弱上拉未关闭。在dts里添加i2c3 { i2c-scl-falling-time-ns 100; i2c-sda-falling-time-ns 100; i2c-scl-rising-time-ns 300; i2c-sda-rising-time-ns 300; // 关闭内部上拉 rockchip,i2c-pull 0; };重编译dts后i2cget成功读到0x5695。Step 3MIPI link建立dmesg | grep mipi显示mipi_dphy: link training failed。检查rockchip,phy-mbps设为800但示波器测得clock lane只有12MHz。原来OV5695的xvclk是24MHzMIPI phy速率24MHz×2×4192Mbps per lane不是800Mbps。修正dtsrockchip,phy-mbps 192; // 每lane速率 rockchip,lane-num 4; // 总带宽768Mbpsdmesg出现mipi_dphy: link up且cat /sys/kernel/debug/rockchip-mipi-dphy/phy0/status显示PHY_STATUS: 0x1link ok。注意MIPI link建立后必须立即调用RKISP1_VIDIOC_S_ISP_INIT否则ISP无法接收数据。这个ioctl在HAL的openCamera()里执行若dts里rockchip,isp节点指向错误ioctl会失败。4.2 Day2HAL3初始化与stream配置——打通数据管道目标HAL open成功configureStreams返回OKpreview画面出现。Step 1HAL open失败排查logcat | grep HAL:显示HAL: open camera failed: -19ENODEV。dumpsys media.camera显示Device state: IDLE。检查/vendor/etc/camera/camera_config.xml发现camera id0 moduleov5695_mipi里的module名与dts里rockchip,camera-module-name ov5695_mipi一致但HAL层getModuleByName()函数里字符串比较用了strncmp()而非strcmp()导致匹配失败。修复// rk_camera_provider.cpp for (int i 0; i mCameraConfigs.size(); i) { if (strcmp(mCameraConfigs[i].module.c_str(), module_name) 0) { return mCameraConfigs[i]; } }Step 2configureStreams失败App调用createCaptureSession()后HAL log显示HAL: configureStreams failed: -22EINVAL。用adb shell service call media.camera 11getSupportedStreamConfigurations拿到HAL支持的config发现只返回{1280x720, YUV_420_SP}没有JPEG。检查HAL代码发现getSupportedStreamConfigurations()里硬编码了mSupportedFormats {HAL_PIXEL_FORMAT_YCrCb_NV12}漏了JPEG。添加mSupportedFormats.push_back(HAL_PIXEL_FORMAT_BLOB); mSupportedSizes.push_back(Size(1920, 1080));Step 3preview黑屏configureStreams成功但SurfaceView无画面。dumpsys media.camera显示Active stream configs有1280x720但/dev/video0无数据。用v4l2-ctl --device /dev/video0 --all查看发现fmt: yuv420m的sizeimage为0。根源是HAL层rkisp1_stream_config结构体里sizeimage未计算修复// rkisp1_device.cpp config.sizeimage width * height * 3 / 2; // NV12 size重启HALpreview画面出现但有严重绿色噪点。实操心得绿色噪点90%是AVDD电压不稳。用万用表测OV5695的AVDD引脚发现纹波达120mV。在原理图AVDD滤波电容旁并联一个10uF钽电容噪点消失。这提醒我们HAL3调试不仅是软件更是软硬协同。4.3 Day3request pipeline与3A调试——让图像“活”起来目标AE/AWB收敛正常图像清晰无延迟。Step 1AE不工作preview画面始终过曝。logcat | grep AE显示HAL: AE not converged。用rk_cam_debug --dump-tuning导出tuning file发现ae_target_lum设为128但OV5695的target应该是80。修改tuning file的ae_target_lum字段reload后AE开始收敛。Step 2AWB偏色白天画面偏黄夜间偏蓝。检查awb_gain_r/g/bmetadata发现R/G/B gain比为1.8/1.0/1.5而标准D65应为1.5/1.0/1.2。原因是AWB算法未校准。用RK提供的tuning_tool加载ov5695_d65.tune再rk_cam_debug --load-tuning ov5695_d65.tune色彩恢复正常。Step 3切换分辨率卡顿App从1080p切到720p预览停顿2秒。dumpsys media.camera显示Request queue size: 12说明HAL queue满。根源是configureStreams()未释放旧stream buffer。在HAL的configureStreams()里添加buffer cleanup// 清理旧stream buffers for (auto buf : mStreamBuffers) { if (buf.handle) { gralloc-free(buf.handle); } } mStreamBuffers.clear();卡顿消失切换时间100ms。**Step 4最终