清空记录

历史记录

清空记录

历史记录

取消

清空记录

历史记录

选型朱工18603053699

咨询李工18165728385

EN ▏

淘宝店铺

瑞芯微RK系列调试工具与量产测试手册--下｜rockchip-test软件测试与PCBA量产验收

2026-10-22 18:10:00太阳成集团tyc234cc主页7

调试手段按「从软到硬」排：串口日志是最常用的一层，串口失效再上JTAG；测试则分软件功能/压测和量产PCBA两级。本文把这四块串成一套完整的调试与验收方法，分上下篇为大家分享。

上篇讲了开发期两条调试链路：串口日志调通、JTAG 兜底早期崩溃。对上篇感兴趣可点此跳转，本文为下篇，转向验收侧——「手点一遍」不算测试，量产阶段每一块板都要过体检。核心内容两块：SDK 自带的rockchip-test 软件测试框架怎么跑功能与压力；量产 PCBA 测试框架 rk_pcba_test 怎么搭、怎么判定 PASS/FAIL。

系统化测试功能用例与压测

"手点一遍"不算测试。瑞芯微SDK自带一套rockchip-test 软件测试框架，把 CPU/DDR/GPU/Flash/音频/相机/网络/压力测试都做成了可复跑的用例。用框架+压力测试规范化操作，功能才算真正验证过。

SDK的软件测试框架在 external/rockchip-test/：主脚本 rockchip_test.sh 提供交互式菜单，每个模块一个目录（cpu/ddr/gpu/npu2/flash_test/audio/camera/video/wifibt/pcie/benchmark/auto_reboot…，注意 NPU 目录是 npu2、Flash 是 flash_test）。做法：先跑功能用例验证行为，再跑压力测试验证稳定（压测通过才算数）。

1、框架长什么样

external/rockchip-test/rockchip_test.sh（V2.4）启动后打印菜单，模块号与用例（源码里直接可见）：

模块号	用例	适合场景
1 / 2 / 3 / 4	ddr / cpu / gpu / npu stress	计算与存储压力，长时间跑稳定性
6 / 7	auto reboot / power lost	反复重启/断电，查异常重启
8	flash stress	Flash/eMMC 读写压力
10 / 11 / 12	audio / camera / video	多媒体功能回归（见篇章四/五）
13 / 14 / 15 / 16 / 17	bt / wifi / wifibt config / pcie / chromium	无线、高速接口、浏览器压测
18	benchmark（unixbench、glmark2…）	性能基准（配合 09.01）

注：菜单里的9为 recovery wipe（recovery 擦除）测试，属recovery范畴，本系列不展开。

2、怎么用

# 交互式（菜单选择）
cd external/rockchip-test && ./rockchip_test.sh
# 直接跑某个模块的脚本（看模块目录）
ls external/rockchip-test/cpu external/rockchip-test/benchmark
./external/rockchip-test/cpu/*stress*.sh   # 例：cpu 压测脚本

注意：菜单里含 suspend_resume 等模块，休眠/唤醒相关内容不在本系列范围（见 uboot-series 07.05）。

3、测试方法论：功能用例 + 压测 + 记录

功能用例：逐项验证行为正确（音频出声、相机出图、网络连通…），人工或脚本断言通过/失败；

压力测试：对改动过的模块做长时间/高频压测（如ddr/cpu/flash stress 过夜），记录 dmesg 是否有 error/panic；

记录与判定：每次测试留档（日志/时间/通过数），对照官方 Linux_Software_Test_CN.pdf 的测试规范组织用例与验收标准。

系统化测试 = rockchip_test.sh 菜单跑功能用例 → 对改动模块跑压力测试 → 全程留 dmesg 日志 → 按官方测试规范判定。压测能复现的崩溃，按 call trace 分析直接定位到驱动。

量产板子PCBA测试搭建

量产阶段每一块板都要过"体检"：CPU、DDR、eMMC、SD、摄像头、音频、按键、LED、RTC、USB……SDK 自带的 rk_pcba_test 把每个模块做成独立用例，一个服务端统一调度、回报 PASS/FAIL。本文拆开这个框架，讲清楚怎么搭、怎么看结果。

PCBA 测试 = 量产产线上的"功能体检"。external/rk_pcba_test/ 是官方实现：一个服务端（echo_pcbatest_server）统一调度，每个硬件模块一个独立用例（echo_<模块>_test.c），用例回报 PASS/FAIL/VERIFY/PRESS，结果可存盘（默认 /tmp）。量产时：编好镜像 → 逐模块跑用例 → 全部 PASS 才放行。

1、框架组成

整个测试程序位于 external/rk_pcba_test/，核心三块：

部件	作用
echo_pcbatest_server.c + pcbatest_server.h	服务端：socket 监听 → fork 子进程跑用例 → 收结果（源码里 PARENT_EXIT/CHILD_EXIT/FORK_FAIL 分工）
echo_<模块>_test.c（一模块一文件）	独立测试用例：cpu / ddr / emmc / sdcard / camera / audio(play/record/linein) / bt / ir / key / led / rtc / usbhost / touchpad / rotary / ringmic / wlan 等
common.h + cJSON/	结果协议与状态定义、JSON 序列化（服务端与 PC 测试端通信）

辅助件：pcba_minui（板上迷你UI）、tinyalsa（音频测试）、echo_auto_test.c（一键全测）、echo_discovery.c（设备发现）。构建目标在 CMakeLists.txt：echo_pcbatest_server、pcba-core、各 echo_xxx_test。

2、结果状态与错误码（源码直读）

common.h 里定义了回报给产线的结果：

状态宏	含义
TESTING	测试进行中
PASS	通过
FAIL	失败（配合错误码定位）
VERIFY	需人工确认（如音视频感官项）
PRESS	等待按键/物理动作（如按键测试要人按）

错误码也是负值编号，例如 KEY_OPEN_FAIL=-40、IR_OPEN_FAIL=-130、SDCARD_MOUNT_FAIL=4 等（详见 common.h）。FAIL 时按错误码查原因，比只看"失败"高效得多。结果默认存 /tmp（TEST_RESULT_SAVE_PATH）。

3、覆盖哪些测试模块

从目录里的用例文件即可看出能测哪些硬件（每项对应一个 echo_<模块>_test.c）：

类别	用例文件
计算/存储	echo_cpu_test.c、echo_ddr_test.c、echo_emmc_test.c、echo_sdcard_test.c
音视频	echo_audio_test.c、echo_audio_play/record/linein_test.c、echo_camera_test.c、echo_ringmic_test.c
输入/外设	echo_key_test.c、echo_ir_test.c、echo_led_test.c、echo_touchpad_test.c、echo_rotary_test.c、echo_rtc_test.c
连接/无线	echo_usbhost_test.c、echo_bt_test.c、echo_wlan_test.c

4、怎么搭起来

框架用 CMake 组织（external/rk_pcba_test/CMakeLists.txt），产线镜像里把服务端/用例打进去：

# 1. 交叉编译（在 SDK 内，工具链见 01.01/01.02）
cd external/rk_pcba_test && mkdir build && cd build
cmake .. && make        # 产物: echo_pcbatest_server / pcba-core / echo_xxx_test
# 2. 部署到板子并启动服务端
adb push echo_pcbatest_server /userdata/ && adb shell
chmod +x /userdata/echo_pcbatest_server && /userdata/echo_pcbatest_server &
# 3. 跑单个用例（以 eMMC 为例）
./echo_emmc_test       # 返回 PASS / 打印错误码

产线可把"逐模块跑 + 解析 PASS/FAIL"写成脚本，或直接跑 echo_auto_test.c 一键全测；带 UI 的产线用 pcba_minui 展示结果。

5、结果判定与量产集成

自动项
（CPU/DDR/eMMC/USB…）：直接看 PASS/FAIL + 错误码；
人工项
（音视频感官）：状态 VERIFY，由产线操作员确认；
FAIL 定位
按 common.h 的错误码找到对应打开/查询失败的环节（如 KEY_OPEN_FAIL = 按键节点打不开，先查设备树/驱动）；
产线合格判据：全部模块 PASS/VERIFY 通过才烧正式固件放行；结果落 /tmp（可改 TEST_RESULT_SAVE_PATH 存持久化分区）。

PCBA 量产测试 = 编译 rk_pcba_test → 产线镜像里带服务端与用例 → 逐模块跑（或 auto 全测）→ 按 PASS/FAIL/VERIFY + 错误码判定 → 全过才放行。框架的每个模块都是独立用例、源码可读可改，需要覆盖更多项时可仿照已有文件自行扩展用例（如新增一个 echo_xxx_test.c）。

RK3576板端实测记录

以下在 RK3576+Debian Bookworm上通过adb直连执行（串口一节命令全部可用）：

验证项	命令（adb shell …）	实测结果
printk 级别	cat /proc/sys/kernel/printk	7 4 1 7（console_loglevel=7 全开）
FIQ 串口	ls /dev/ttyFIQ0；dmesg \| grep console	/dev/ttyFIQ0 存在，日志见 console [ttyFIQ0] enabled
rockchip-test	ls /userdata/rockchip-test /usr/bin/rockchip*	未预装（SDK 侧框架，需按 01.02 部署到板）
PCBA 服务端	ls /userdata/echo_pcbatest_server	未预装（需 cmake 交叉编译后 push，见本节省 4）

官方文档依据：

docs/cn/Common/UART/Rockchip_Developer_Guide_UART_CN.pdf
docs/cn/Common/UART/Rockchip_Developer_Guide_UART_FAQ_CN.pdf（串口与 FAQ）

SDK 源码依据：

kernel-6.1/arch/arm64/boot/dts/rockchip/rk3576-linux.dtsi（earlycon/console bootargs）
kernel-6.1/arch/arm64/configs/rockchip_linux_rk3576_defconfig（CONFIG_SERIAL_8250_CONSOLE=y、CONFIG_SERIAL_8250_DW=y、CONFIG_PRINTK_TIME=y）
kernel-6.1/arch/arm64/boot/dts/rockchip/rk3576.dtsi（uart2 节点）

Purple Pi OH2开发板，是触觉智能RK3576核心板SOM7609系列配套的评估开发板，搭载4核A72+4核A53+M0多核异构处理器，主频2.2GHz，集成6Tops算力 NPU，轻松应对AI推理、边缘计算与轻量级AI端侧学习。配套完善SDK、丰富资料与Demo，有助于项目前期快速开发验证。

触觉智能SOM7609系列核心板尺寸仅40.5×40.5mm，基于RK3576/RK3576J SoC，集成高性能GPU与VPU，支持4K视频编解码与多屏异显；提供PCIe、USB3.2、双路千兆以太网、MIPI-DSI、多路MIP CSI、eDP、CAN、SPI、I2C等丰富接口，灵活扩展。