企业官网建设流程全解析

RV1106 这颗芯片我前前后后调了小半年，从最开始裸机点亮 sensor，到后面把 H264 编码链路完整跑通，中间踩过的坑确实不少。做嵌入式视觉方案的工程师应该都有感触：捕获一路视频流不难，难的是让它在持续运行时不花屏、不丢帧、延迟可控、码率稳定，尤其在资源有限的小型 IPC 和 AI 盒子上。最近刚好有朋友在问 RV1106 上从 sensor 采集到出流的具体流程，干脆把完整链路写出来，从 V4L2 抓帧、硬件 ISP 处理，到 MPP 编码器配置、H264 码流输出，每一步的代码逻辑、参数依据和实操经验都摊开讲。这篇文章适合正在做摄像头方案开发的同行，也适合刚拿到 RV1106 开发板、想把视频跑起来的新手，你不需要有很深的视频编解码基础，按照这条链路一步步走，基本能把整个流程吃透。

1. RV1106 平台概览与视频链路整体架构

1.1 为什么选择 RV1106 做视频编码方案

瑞芯微 RV1106 是一颗面向智能视觉应用的 SoC，它最大的特点就是把“捕获、处理、编码、AI 分析”这几件事整合到了很低的功耗和很小的封装里。芯片内部集成了一颗双核 ARM 处理器，主频可以跑到 1.2GHz 左右，这个算力跑轻量级 AI 模型没问题，跑系统调度和网络协议栈也够用。最核心的部分是它内置的 VPU，也就是视频处理单元，支持 H.264 和 H.265 的硬件编码，最大分辨率能到 5M 像素级别，对于目前主流的 300 万像素、500 万像素摄像头方案来说，刚好对口。

我之前用过好几款同级别的芯片，说实话，RV1106 的编码器有个非常明确的优势：它的 MPP（Media Process Platform）软件栈比较干净，接口设计得很直观，而且提供了完整的多路编码支持。做 IPC 方案时，很常见的一路主码流做录像、一路子码流做预览的需求，在 RV1106 上可以直接通过 MPP 开两个编码通道实现，不需要额外的软件转码，省了不少内存和 CPU 开销。编码后的码流质量在同等码率下，主观观感和客观 PSNR 指标都做得不错，尤其是暗光场景下，只要 ISP 调试到位，编码器侧不会额外引入明显的块效应和色彩偏差。

选择 RV1106 还有一个现实原因：它周边配套的 sensor 支持非常全，RK 社区的驱动模型对各种常见 sensor（比如 IMX、OV、SC 系列）适配得都很快，基本稍微改改设备树就能点亮。对于做产品而不是做研究的人来说，这套生态能省下大量“从零开始调驱动”的时间。

1.2 视频从捕获到 H264 码流的完整链路

在 RV1106 上，一路视频画面从 sensor 进来到最终输出 H264 码流，中间会经过这么几个环节：

1. sensor 采集 RAW 数据，通过 MIPI CSI-2 接口送入 SoC。
2. SoC 内部的 ISP 模块对 RAW 数据进行处理，完成去噪、坏点校正、自动曝光、自动白平衡、色彩校正等操作，输出 YUV 图像数据。
3. YUV 数据经过 V4L2 驱动框架进入用户空间，以 buffer 的方式交给应用层。
4. 应用层将 YUV buffer 送入 MPP 编码器，由硬件 VPU 完成 H264 编码。
5. 编码器输出 H.264 Annex-B 格式的码流，应用层负责按帧取出，加上时间戳后封装成 RTSP/FLV/MP4 等格式输出。

这条链路看起来简单，但每一步都有容易出问题的地方。最典型的坑在第三步和第四步之间：V4L2 输出的 buffer 格式、对齐方式和 MPP 编码器要求的输入格式不一致，如果没做好格式转换或者 stride 对齐，编码出来的画面就会出现绿边、花屏甚至编码器直接报错。我在 3.2 节和 4.2 节会专门把这两个环节的参数对齐讲清楚。

另外需要说明一点，RV1106 的 ISP 通路是可以通过 V4L2 子设备接口来配置的，sensor 本身也是一个 V4L2 subdev，整个链路是标准的 media controller 框架。所以如果你之前调过其他平台的 V4L2 驱动，上手 RV1106 会非常顺畅，核心的 open/request buffer/stream on/stream off 流程和 Linux 主线驱动是兼容的。

2. 开发环境搭建与底层驱动准备

2.1 SDK 目录结构与交叉编译环境

拿到 RV1106 开发板后，第一件事就是把瑞芯微官方提供的 SDK 拉下来。SDK 里通常包含了 u-boot、kernel、buildroot、app 层示例代码，整个编译流程由脚本统一管理。我比较推荐在 Ubuntu 18.04 或 20.04 的 64 位系统上做交叉编译，装好repo工具后repo sync拉取全量代码，然后执行./build.sh就能构建完整固件。

RV1106 的交叉编译工具链是 arm-rockchip830-linux-uclibcgnueabihf，这是一个 32 位 ARM 的工具链，因为 RV1106 的内核和用户空间都是 32 位的。编译应用层代码时，需要把工具链的 bin 目录加进 PATH，比如：

export PATH=/opt/arm-rockchip830-linux-uclibcgnueabihf/bin:$PATH

然后写 CMakeLists.txt 时指定交叉编译器：

set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(TOOLCHAIN_PREFIX arm-rockchip830-linux-uclibcgnueabihf-) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g++)

这里有个经验：如果只是想验证编码功能，直接用 SDK 里自带的mpi_enc_test示例就能跑通。但我们做产品时还是要自己写应用，所以我会建议把 MPP 的头文件和库拷贝到自己的工程里，或者直接用find_package的方式链接 SDK 生成的 MPP 动态库。MPP 的动态库在 SDK 编译完成后会生成在buildroot/output/rockchip_rv1106/target/usr/lib/下，拷贝出来用就行。

2.2 设备树与 sensor 驱动配置

设备树是 RV1106 视频链路能否正常工作的基础。你需要确保设备树里同时打开了 ISP、MIPI DPHY 和 sensor 三个节点，并且 sensor 的 I2C 地址、reset/电源控制引脚配置正确。

一个典型的 sensor 节点配置大概是这样的：

&csi2_dphy0 { status = "okay"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; mipi_dphy0_out: endpoint { remote-endpoint = <&sc530ai_csi2_out>; }; }; port@1 { reg = <1>; mipi_dphy0_in: endpoint { remote-endpoint = <&isp0_in>; }; }; }; };

配置好设备树后，重新编译内核并烧录固件。上电后先用media-ctl工具查看整个管线是否注册完整：

media-ctl -p

正常情况下，你会看到类似这样的拓扑：sc530ai 0-0030→csi2-dphy0→rkisp0这样的链路。如果 sensor 节点没有注册，先查 I2C 能否读到 sensor ID；如果 ISP 节点没有和 sensor 连接上，多半是 remote-endpoint 的 phandle 指错了。设备树这块调试比较费时间，我的建议是先跑通 SDK 自带的内核配置，确认硬件没问题后再按需裁剪。

3. V4L2 视频流捕获实现

3.1 V4L2 捕获流程的代码骨架

视频流捕获是整条链路的第一步，代码层面走的是标准 V4L2 框架。整体流程可以总结为“打开设备、设置格式、申请缓冲区、入队、开始采集、出队处理、入队回填”这几步。

先打开/dev/video0，然后通过 VIDIOC_S_FMT 设置采集格式。RV1106 的 ISP 输出通常是 NV12 格式，这个格式在内存里是先存 Y 平面、再交错存储 UV 分量的布局。宽度和高度要注意对齐，通常按 16 像素对齐，也就是设置 1920x1080 时，实际 stride 可能是 1920 或更高，这个值会通过v4l2_format.fmt.pix.bytesperline返回给应用。

申请缓冲区时，我习惯用V4L2_MEMORY_MMAP模式，这也是最常用的方式。流程是先调用VIDIOC_REQBUFS申请 4 个 buffer，再逐个通过VIDIOC_QUERYBUF获取 buffer 信息，并mmap映射到用户空间。然后调用VIDIOC_QBUF把空闲 buffer 放入驱动队列，最后VIDIOC_STREAMON开始采集。

采集过程中，应用层通过VIDIOC_DQBUF等待一个填充好的 buffer，拿到 buffer 后，里面的图像数据就可以送去编码。处理完后必须马上调用VIDIOC_QBUF把这个 buffer 还给驱动，否则 buffer 耗尽，画面就会卡住。这个“出队-处理-入队”的循环是整个视频采集的核心循环，每个 IPC 方案都跑在这一段逻辑上，所以代码务必写得清晰高效，避免在这里加任何不必要的拷贝或者延时。

3.2 ISP 通路配置与图像的 stride 对齐

很多人第一次调 RV1106 都会在 ISP 这步吃亏。ISP 的输入输出格式、裁剪区域和 stride 不对齐是导致编码器报错或画面异常的最高频原因。

我在驱动里已经把 ISP 输出设置成 NV12 了，但实际从bytesperline拿到的不一定是 1920，而可能是 1920 对齐后的 1920 或 1984 之类的值。这是因为 ISP 硬件内部为了保证带宽效率和 SIMD 处理，经常会把行像素数对齐到 16 甚至 32 字节。如果你直接以为 stride 等于 width，送给编码器的每个 plane 的 stride 就不对，编码出来的图像会出现右侧偏色或亮度偏移。

解决办法很简单：在 V4L2 的VIDIOC_S_FMT之后，马上读取v4l2_format.fmt.pix.bytesperline和sizeimage，把这两个值缓存起来，后面操作 buffer 时全程使用这两个值而不是自己算。

另外，ISP 还有一个容易忽略的点：sensor 输出的图像比例和编码器要的目标分辨率可能不一致。如果 sensor 是 4:3 的 500 万像素 CCD，而编码器要输出 16:9 的 1080p，那么应该在 ISP 链路中设置裁剪区域（crop），先在 ISP 阶段裁掉上下多余的部分，再输出 YUV，而不是直接把整幅图送到编码器里让它硬压。在 ISP 阶段裁剪的好处是省内存带宽，编码器输入的图像也干净，后续预览和录像两边都能复用同一路 YUV。

3.3 缓冲区管理与帧率控制细节

缓冲区数量默认设 4 是很多 SDK 示例的惯例，但在实际产品中，我会根据内存余量和延迟要求来调整：如果内存紧张，可以减到 3；如果采集端有偶发性的处理耗时，最好设到 5~6，这样能平滑抖动，减少因为 buffer 不足导致的丢帧。

帧率控制这块，我在项目里很少直接依赖 V4L2 设置 sensor 帧率，而是更倾向于让 sensor 固定工作在 30fps，然后在应用层按需丢弃或者复制帧。原因是 sensor 的帧率切换经常会触发重新稳帧、曝光收敛等过程，如果编码端的路数多（主码流 + 子码流），一下子切换帧率可能引发几帧的异常。把 sensor 固定在一个稳定帧率，由上层决定丢哪些帧，整个管线会稳定很多。

也有一点要注意：ISP 输出的帧时间是持续递增的，但 V4L2 buffer 的timestamp默认可能是 monotonic clock，也可能是 realtime clock，取决于驱动里的配置。在后续封装 RTSP 或者 MP4 时，时间戳的基准必须全程一致。我习惯在VIDIOC_QUERYCAP时检查capabilities，或者在驱动初始化时统一设定时间戳类型为V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC，这样编码器输出和网络发送都能使用同一个时钟源，不会出现音视频不同步的诡异问题。

4. H264 编码器配置与码流封装

4.1 MPP 编码器初始化与关键参数解析

RV1106 的 H264 编码器走的是瑞芯微 MPP 框架。MPP 的接口其实非常简单，核心结构体是MppCtx和MppEncCfg。初始化大概分三步：创建编码器上下文、配置编码参数、准备输入输出分组。

创建上下文的代码片段：

MppCtx ctx; MppEncCfg cfg; mpp_create(&ctx, &MPP_ENC_H264); mpp_init(ctx, MPP_CTX_ENC, MPP_ENC_H264); mpp_enc_cfg_init(&cfg);

配置参数时，需要设置分辨率、帧率、码率、GOP 间隔、码率控制模式等关键项。以 1080p30 为例，典型配置如下：

mpp_enc_cfg_set_s32(cfg, "prep:width", 1920); mpp_enc_cfg_set_s32(cfg, "prep:height", 1080); mpp_enc_cfg_set_s32(cfg, "prep:hor_stride", 1920); mpp_enc_cfg_set_s32(cfg, "prep:ver_stride", 1088); mpp_enc_cfg_set_s32(cfg, "prep:format", MPP_FMT_YUV420SP); mpp_enc_cfg_set_s32(cfg, "rc:mode", MPP_ENC_RC_MODE_CBR); mpp_enc_cfg_set_s32(cfg, "rc:bps_target", 2 * 1024 * 1024); mpp_enc_cfg_set_s32(cfg, "rc:bps_max", 2 * 1024 * 1024 * 11 / 10); mpp_enc_cfg_set_s32(cfg, "rc:bps_min", 2 * 1024 * 1024 * 9 / 10); mpp_enc_cfg_set_s32(cfg, "rc:fps_in_flex", 0); mpp_enc_cfg_set_s32(cfg, "rc:fps_in_num", 30); mpp_enc_cfg_set_s32(cfg, "rc:fps_in_denom", 1); mpp_enc_cfg_set_s32(cfg, "rc:fps_out_flex", 0); mpp_enc_cfg_set_s32(cfg, "rc:fps_out_num", 30); mpp_enc_cfg_set_s32(cfg, "rc:fps_out_denom", 1); mpp_enc_cfg_set_s32(cfg, "rc:gop", 30); mpp_enc_cfg_set_s32(cfg, "rc:gop_mode", MPP_ENC_GOP_MODE_NORMAL_P); mpp_enc_cfg_set_s32(cfg, "codec:type", MPP_VIDEO_CodingAVC); mpp_enc_cfg_set_s32(cfg, "codec:profile", 100); mpp_enc_cfg_set_s32(cfg, "codec:level", 40); mpp_enc_cfg_set_s32(cfg, "codec:cabac_en", 1); mpp_enc_cfg_set_s32(cfg, "codec:cabac_idc", 0); mpp_enc_cfg_set_s32(cfg, "codec:trans_8x8", 1);

有几个参数我想重点说明一下。

prep:ver_stride设置成 1088 而不是 1080，是 H264 编码器内部宏块对齐的要求，1080 不能被 16 整除，所以对齐到 1088。这个值在 V4L2 那边不一定能看到，但 MPP 编码器默认会按这个值去解释输入 buffer。如果你传入的 buffer 本身是按 1080 分配的，那么最后一行的填充区域是无效数据，编码器会自己忽略，不影响画面。

rc:mode控制码率模式。CBR 适合实时视频预览和录像，码率上下波动小；VBR 适合追求画质的场景，码率会跟着画面复杂度走，但带宽不可控。我在做 IPC 时主要用 CBR，配合bps_max和bps_min设置成 target 的 ±10%，既保证了码率稳定性，又给了编码器一定的调整空间。

codec:profile设为 100 是 High Profile，支持 8x8 变换（trans_8x8设为 1）和 CABAC 熵编码，压缩率更好。如果是低端播放器兼容性要求比较高的场景，可以降到 Baseline Profile（66），但文件体积会增大不少。

4.2 帧数据送入编码器的正确姿势

编码器配置好之后，剩下就是循环从 V4L2 拿 YUV 帧，送给 MPP 编码。MPP 的输入输出都是基于MppBuffer和MppPacket的。

送一帧数据前，需要先调用mpi->dequeue(ctx, FRAME_GROUP, &frame)向编码器请求一个空闲输入 frame，然后把这个 frame 的 buffer 指针映射到用户空间，将 V4L2 出队的 YUV 数据memcpy进去。这里有一个容易忽略的性能点：memcpy 一整张 1080p NV12 图像大概要拷贝 3MB 左右的数据，这个开销在 ARM 上至少要 1~2ms。如果每帧都做，对 CPU 是可见的负担。

更高效的做法是使用mpp_buffer_import或者直接使用零拷贝通道。RV1106 的 MPP 支持直接 import 外部 buffer，这样 V4L2 出队的 buffer 可以直接交给编码器，不需要 memcpy。不过这个方案对 buffer 的内存类型有要求，通常需要物理连续内存，所以只能和 V4L2 的V4L2_MEMORY_DMABUF模式配合使用。如果项目对延迟和 CPU 占用率特别敏感，建议直接走 DMABUF 零拷贝路线，能省下整整一段拷贝时间。

把帧数据填进 MppFrame 后，通过mpi->encode(ctx, &packet)触发编码。因为 VPU 是硬件编码，encode调用可以异步返回还是同步返回取决于上下文是否设置了异步模式。SDK 里默认是同步，也就是encode返回后，packet已经包含了一帧编码后的 H264 数据。如果是异步模式，需要轮询或等信号量，逻辑会复杂一点，但对于普通单路编码来说，同步模式完全够用，代码也更直观。

从packet拿数据时，注意有个EOS标志位，在视频流结束时packet里可能没有数据，只带了一个结束标记，这个时候不能直接把packet->data当普通码流发送。

4.3 H264 码流格式与时间戳处理

MPP 编码器输出的 H264 是标准的 Annex-B 格式，也就是每个 NALU 前面带起始码00 00 00 01。对 RTSP 分发来说，这个格式可以直接用；对 MP4 封装来说，需要去掉起始码，转成长度前缀格式，然后写在 stbl box 里，这个过程通常在 muxer 层完成。

在编码输出过程中，需要关注的 NALU 类型主要是 SPS、PPS、IDR 和普通 P 帧。SPS/PPS 通常在编码器刚启动时只输出一次，但不少播放器和录制系统要求在关键帧前重新带一遍参数集，防止花屏和无法解码。处理办法有两个：一是在每次检测到 IDR 帧时，把保存过的 SPS/PPS 拼在 IDR 前面；二是通过 MPP 的"rc:gop_mode"配置成智能 GOP，让编码器在 I 帧前自动输出参数集。我实测下来，第二种方式在 MPP 上更稳，设置gop_mode为MPP_ENC_GOP_MODE_SMART_P，并配合 IDR 间隔，就能让 H264 码流里每个 I 帧前都带上 SPS/PPS。

时间戳处理是另一个重灾区。V4L2 buffer 自带 monotonic 时间戳，单位是微秒（tv_sec * 1000000 + tv_usec）。编码器输出的 packet 不带时间戳，需要应用层在把帧送入编码器前记录一个对应的时间戳，编码完成后把这个时间戳传给 packet。我习惯用一个环形队列把输入帧的序号和时间戳绑定，编码输出时按顺序取出来，这样即使编码器偶尔乱序返回，也能保证时间戳跟着正确的帧走。

做 RTSP 推流时，RTP 时间戳的单位是 90000Hz，需要把微秒时间戳做一次换算：

uint32_t ts_rtp = (uint32_t)(ts_us * 90 / 1000);

也就是微秒数乘以 90 再除以 1000。这个换算很容易写错，一旦写错，播放端画面会严重卡顿、音画不同步，而且非常隐蔽。

5. 实测问题排查与调优心得

5.1 编码帧率上不去，掉帧频繁

我在把编码器跑起来之后遇到的第一个大问题就是帧率不稳，20 分钟的测试里时不时掉帧，CPU 占用忽高忽低。排查下来有几个原因，按出现频率排列如下：

1. V4L2 采集侧 buffer 数量不足，导致 ISP 输出侧没有空闲 buffer 可写，驱动直接丢帧。
2. memcpy 拷贝整帧数据耗时太长，在编码和采集循环里形成了串行瓶颈。
3. 应用层日志打印过于频繁，串口和文件 IO 拉低了整个进程的吞吐。

解决办法分别是：把 V4L2 buffer 加到 6 个；改用 DMABUF 零拷贝；重定向打印到内存缓冲区并按需落盘。优化完之后，1080p30 的采集编码链路 CPU 占用率稳定在 5% 上下，编码本身几乎不消耗 CPU，全部由 VPU 完成。

还有一个技巧：在VIDIOC_S_FMT设置采集参数时，把v4l2_pix_format.field设置成V4L2_FIELD_NONE，也就是逐行扫描，避免驱动或 ISP 走隔行处理路径，否则帧率会直接减半。

5.2 画面花屏、绿屏和间歇性偏色

花屏问题我遇到过两类。

第一类是编码器输入 stride 不对。表现为编码后的画面右侧有一道偏色的竖条，或者整体右移了几十像素。排查方法很简单：把编码器输出的 H264 存成裸流，用 ffplay 播放，暂停观察画面右侧像素是否错乱。如果错位，基本可以确定是hor_stride和 V4L2 的bytesperline不一致，严格按第 3.2 节的方式对齐即可。

第二类花屏与 IDR 帧或参数集有关。几个播放器里偶尔出现花屏，但 VLC 和 ffplay 都能正常播。这个多发生在 RTSP 取流时播放器恰好从非关键帧开始解码，且 SPS/PPS 没有随之重发。解决方式就是把每条流里的 SPS/PPS 缓存下来，在 RTSP 的配置消息里带出去，或者按 4.3 节的方法让编码器智能输出参数集。

间歇性偏色则多半是 ISP 白平衡和色彩矩阵没有收敛好，跟编码器没有直接关系。这时候不要死磕编码器，回头看看 ISP 的 AE/AWB 参数和 sensor 的增益配置，往往是在 sensor 曝光切换的瞬间造成色偏。

5.3 编码器输入队列阻塞排查

MPP 编码器偶尔会出现dequeue拿不到空闲 frame、导致整个采集循环堵住的情况。常见的诱发因素有两个：一是应用层在上送帧的速率低于编码器消费速率，导致编码器内部堆积了未完成帧；二是输出侧 packet 没有及时retrive，导致编码器内部 buffer 池耗尽。

处理办法：在采集循环里增加一个超时保护，例如dequeue等待超过 500ms 就丢弃当前帧，而不是无限阻塞下去；同时在编码输出侧，每次encode返回后立刻retrive拿 packet，并把 packet 拷贝到自己的发送队列，包处理完成后再put_packet释放。严格遵循“dequeue → 填帧 → encode → retrive → 拷贝 → put”这个节奏，编码器基本不会堵。

5.4 码率波动偏高和 I 帧大小异常

设置 CBR 后，如果发现实际码率波动超过 ±20%，建议检查bps_max和bps_min的设定是否离 target 太远；另外rc:gop如果设得太大，I 帧之间的 P 帧会积累漂移，导致 I 帧瞬间码率暴涨。我常用的做法是 GOP 设为帧率的 1 到 2 倍，比如 30fps 下 GOP 设 30，即每 1 秒一个 I 帧。这个设置既能保证 seek 响应较快，压缩率也合适。

如果发现 I 帧瞬间码率还是偏大，可以开启"rc:scene_chg_thrd"之类的场景切换阈值参数，让编码器在画面剧烈变化时不强制拉太高码率。不过这些参数对画面质量影响比较微妙，需要结合自己的 sensor 场景反复测试，没有一个通用最优值。

6. 链路调通后的进一步扩展

把 H264 采集编码主链路跑通之后，很多项目会在此基础上加子码流、加 AI 分析、加存储录像。RV1106 的 MPP 支持多通道编码，可以在同一个MppCtx上配置多个编码器实例，也可以直接创建独立的编码器上下文来做多路编码。如果只是做一块小开发板验证方案，参考本文这套流程足够；如果是走向产品，建议在应用层加一个流管理模块，把采集、编码、推流、存储解耦成独立线程，用队列传递帧引用而不是拷贝，这样无论是扩展子码流还是叠加 AI 分析，都不会反过头来影响主码流的稳定性。

再分享一个很实用的经验：在项目初期就把整个链路的对齐参数打印出来，包括 V4L2 的bytesperline、sizeimage、MPP 的hor_stride、ver_stride、编码器的 GOP 和码率控制参数。不要嫌日志难看，这些字段在后续排查花屏、帧率不稳、推流卡顿的时候，能帮你直接锁定问题在哪一层，省下大量反复试错的时间。

我个人在实际调试中的体会是，RV1106 这套捕获-编码流程并不复杂，难的是每个环节之间的参数一致性。V4L2 管的是采集格式，MPP 管的是编码格式，两者看似独立，实际通过 stride、缓冲区大小、时间戳紧密耦合。把这条耦合关系理清了，把每个 buffer 的生命周期管到位，整个 H264 视频流从 sensor 到网络侧的输出就会非常稳定。希望这份流程解析能帮你少走一些弯路，如果你在调 RV1106 的过程中遇到其他奇怪的现象，欢迎随时交流，我踩过的坑也许能给你省下一天甚至一周的时间。