一、测试文件下载与设备基础信息1.测试文件下载测试音乐下载 :test.wav 串口工具下载:MobaXterm_Portable_v23.0_cn.zip | 项目 | 详情 |
|---|
| 设备型号 | RP01A-RK3588S2开发板(硬件版本:V1.0A) | | 系统版本 | Debian12 XFCE 桌面(固件版本:rk3588-rp01a-debian12-rkr6-xfce-20251230-更新fw.img) | | 内核版本 | Linux 6.1.118 |
| 项目 | 配置详情 |
|---|
| CPU | RK3588S Octo-core, Cortex-A76 and Cortex-A55 频率高达2.4GHz | | GPU | Mali-G610 GPU,OpenGL ES 1.1/2.0/3.2,OpenCL 2.2,Vulkan 1.2 内嵌高性能2D加速硬件 | 内存(DDR)
| LPDDR5X,4G/8G/16G/32G可选
| | AI 算力(NPU) | 6.0 Tops | | 内置存储 | 支持 eMMC5.1,SDIO3.0 16GB/32GB/64G/128G(可选) |
| 项目 | 规格说明 |
|---|
| 直流电源要求 | 输入:12V 2A DC 接口规格:5.5mm × 2.0mm 圆柱电源口 ⚠️ 注意:输入电压低于 12V 可能导致设备无法开机 |
二、电源基础测试1. 电源接口功能验证- 验证设备电源接口的兼容性、电气性能及安全性,确保符合供电参数要求。
2. 测试环境与工具适应性| 工具 / 环境 | 规格说明 |
|---|
| 直流电源适配器 | 12V 2A DC(匹配 5.5mm×2.0mm 接口) | | 万用表 | 支持电压 / 电流测量 | | 待测设备 | 目标产品(含电源接口) |
3.基础测试流程规范1.直流电源接口兼容性测试 - 测试步骤:
- 确认直流电源适配器规格为 “12V 2A DC”,接口尺寸 “5.5mm×2.0mm”;
- 将适配器接入设备电源接口,通电后观察设备是否正常开机。
- 判定标准:
接口可稳定插入 / 拔出,设备正常开机无异常。
2.输入电压下限验证 - 测试步骤:
- 使用可调直流电源,将电压调至11.5V(低于 12V),接入设备;
- 观察设备是否出现 “无法开机” 等异常现象。
- 判定标准:
电压低于 12V 时,设备无法正常开机(与供电参数 “注意” 项一致)。
三、有线通信接口测试1.Debug 串口(UART)测试| 项目 | 内容 |
|---|
| 测试目的 | 验证开发板 Debug 串口(UART)的硬件通信功能,确保能正常输出内核启动日志、接收 / 响应命令行指令,满足底层调试需求。 | | 前提条件 | 1. 开发板已断电,无外接电源; 2. 准备工具:USB 转 TTL 串口线(3.3V 电平,匹配开发板 Debug 口)、PC 端串口工具(如MobaXterm、 SecureCRT、Putty、串口助手); 3. 确认开发板 Debug 口引脚定义(TX/RX/GND),并核对串口参数(常见:波特率 1500000、8 位数据位、1 位停止位、无校验、无流控); 4. PC 已安装串口驱动(USB 转 TTL 芯片驱动,如 CH340/PL2303)。 |
步骤 1:硬件连接 - 按开发板手册标注的 Debug 口引脚,将 USB 转 TTL 串口线对应连接:
- 开发板 Debug 口 TX → 串口线 RX
- 开发板 Debug 口 RX → 串口线 TX
- 开发板 Debug 口 GND → 串口线 GND
(⚠️ 注意:TX/RX 交叉连接,严禁接反;3.3V 电平串口禁止接 5V,避免烧损) - 将 USB 转 TTL 串口线的 USB 端插入 PC 主机 USB 接口。
步骤 2:PC 端串口工具配置 - 打开串口工具(以 MobaXterm 为例),进行参数配置:
- 串口端口:在 PC 设备管理器中查看 “端口 (COM 和 LPT)”,选择串口线对应的 COM 口(如 COM3);
- 波特率:1500000(开发板默认 Debug 口波特率,需与内核启动参数一致);
- 数据位:8;
- 停止位:1;
- 校验位:None;
- 流控:None;
- 点击“会话”选择“Serial”,选择对应的Serial端口和波特率:1500000,点击 “OK” 打开串口连接。
步骤 3:启动日志输出测试 - 给开发板上电,观察 PC 端串口工具的输出:
- 记录从 “U-Boot 启动” 到 “内核初始化” 再到 “系统登录提示符” 的完整日志;
- 重点检查是否有 “Serial: xxx”“console=ttyS2,1500000” 等串口相关初始化日志。
1. 设备连接状态识别 通过以下命令确认设备是否接入系统并获取设备节点信息: | 代码块 |
|---|
| # 查看所有块设备,识别USB对应的设备节点(如/dev/sda1)
lsblk
# 查看USB设备详细信息,包括控制器和设备ID
lsusb |
结果说明:lsusb输出中,ID 1d6b:0002对应 USB2.0 控制器,ID 1d6b:0003对应 USB3.0 控制器,可通过设备挂载的总线判断其关联的 USB 版本。
| 代码块 |
|---|
| # 遍历所有USB设备,输出其传输速度
for device in $(ls /sys/bus/usb/devices/); do
if [ -f "/sys/bus/usb/devices/$device/speed" ]; then
speed=$(cat /sys/bus/usb/devices/$device/speed)
echo "Device: $device, Speed: $speed Mbps"
fi
done |
2.通过详细信息验证 | 代码块 |
|---|
| # 查看指定USB设备的详细参数,搜索Speed字段
lsusb -v | grep -E "Speed|Device" |
结果说明:输出中Speed: 480Mbit/s对应 USB2.0,Speed: 5000Mbit/s对应 USB3.0。 1.1.挂载 USB 设备: | 代码块 |
|---|
| # 假设通过lsblk确认USB设备节点为/dev/sda1,创建挂载点并挂载
mkdir -p /mnt/usb
mount /dev/sda1 /mnt/usb |
1.2. 测试顺序写速率: | 代码块 |
|---|
| # 写入1GB零数据到USB设备,绕过缓存确保结果真实
dd if=/dev/zero of=/mnt/usb/testfile bs=1M count=1024 conv=sync oflag=direct |
1.3.测试顺序读速率: | 代码块 |
|---|
| # 读取USB设备中的测试文件并丢弃,测试读取速度
dd if=/mnt/usb/testfile of=/dev/null bs=1M iflag=direct |
1.4.测试后清理临时文件: 结果说明:命令执行完毕后会显示传输时间和速率,USB2.0 实际写速率通常在 10 - 30MB/s,USB3.0 实际写速率通常在 50 - 150MB/s(受设备本身性能影响)。 2.1.安装 fio: | 代码块 |
|---|
| # Ubuntu/Debian
sudo apt install fio -y |
2.2.fio测试命令代码块: | 代码块 |
|---|
| # 顺序写测试
fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=write -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1
# 顺序读测试
fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=read -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1
# 随机写测试
fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randwrite -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1
# 随机读测试
fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randread -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1
# 随机读写混合测试(默认读写比例 50:50)
fio -filename=/temp/testfile -direct=1 -ioengine=psync -iodepth 128 -rw=randrw -bs=1M -size=3G -numjobs=4 -runtime=30 -group_reporting -name=iopstest -time_based=1 |
1.1. ADB基础连接测试 测试目的:验证 Type‑C 接口可正常建立 ADB 连接,设备可被 PC 识别。 测试步骤: 1.用 Type‑C 数据线连接待测设备与 PC。 2.设备端开启「开发者选项」→「USB 调试」。 3.PC 端执行 adb devices,检查设备是否被识别。 4.执行 adb shell,验证是否可进入设备命令行。 预期结果: 1.adb devices 输出设备序列号,状态为 device。 2.成功进入设备 shell,无连接超时或权限拒绝。 1.2. ADB 核心指令执行测试 测试目的:验证 ADB 核心指令在 Type‑C 链路下可正常执行。 测试步骤: 1.用文件传输: 执行 adb push test_file /data/ 推送文件至设备。 执行 adb pull /data/test_file ./ 拉取文件至 PC。 2.设备控制: 执行 adb reboot 重启设备,重启后重新执行 adb devices。 3.日志抓取: 执行 adb logcat -d > adb_log.txt 抓取系统日志。 预期结果: 1.文件传输无失败,拉取文件与原文件大小一致。 2.重启后 ADB 连接可自动恢复。 3.日志文件非空,包含有效运行日志。 1.3. Type‑C 插拔与稳定性测试 测试目的:验证 Type‑C 接口在插拔、晃动等场景下 ADB 连接的稳定性。 测试步骤: 1.单次插拔:插拔数据线 10 次,每次插拔后执行 adb devices。 2.连续插拔:快速插拔 20 次,间隔 1–2 秒。 3.晃动测试:保持连接状态,轻微晃动数据线,观察连接状态。 预期结果: 1.每次插拔均可正常识别设备,无 offline 状态。 2.晃动过程中 ADB 连接不中断,无 IO 错误。 1.4. Type‑C 插拔与稳定性测试 测试目的:验证高负载场景下 Type‑C ADB 功能的稳定性。 测试步骤: 1.大文件传输:推送 1GB 文件至设备,同时执行 adb logcat。 2.多指令并发:同时执行 adb push、adb shell top、adb logcat。 3.长时间连接:保持 ADB 连接 24 小时,每小时执行 adb devices。 预期结果: 1.大文件传输过程中 ADB 不中断,日志抓取正常。 2.多指令并发无卡死或超时,CPU 占用 ≤ 80%。 3.24 小时内连接状态持续为 device,无自动断开。 2.Type-C 转 hub(USB)测试2.1 设备识别与兼容性测试前置条件: 1.开发板上电正常,系统启动完成 2.Type-C 转 USB Hub 连接正常 操作步骤: 1.将 Type-C 端插入开发板 Type-C 接口 2.将 USB 设备(U 盘、鼠标、键盘)依次插入 Hub 的 USB 口 3.执行命令 lsusb 查看设备列表 4.查看系统日志 dmesg | grep usb 预期结果: 1.所有 USB 设备均能被系统正确识别,lsusb 输出中可见对应设备 ID 2.系统日志无 USB 设备识别失败或报错信息 3.U 盘可正常挂载 / 读写,鼠标 / 键盘可正常响应 2.2 数据传输速率测试 前置条件: 1.同 2.1 2.准备 1GB 测试文件(test.img) 操作步骤: 1.插入 USB3.0 U 盘并挂载到 /mnt/usb 2.执行文件拷贝命令: | 代码块 |
|---|
dd if=/dev/zero of=/mnt/usb/test.img bs=1M count=1024 |
3.记录传输耗时,计算速率:速率 = 1024MB / 耗时(秒) 4.反向拷贝回开发板,重复测试 3 次 预期结果: 1.USB3.0 模式下传输速率 ≥ 80MB/s(约 640Mbps) 2.USB2.0 模式下传输速率 ≥ 30MB/s(约 240Mbps) 3.无数据丢失、无传输中断、无文件损坏 2.3 供电能力测试 前置条件: 1.同 3.1 2.准备 2.5 英寸移动硬盘(需 5V/0.5A 以上供电) 操作步骤: 1.将移动硬盘插入 Hub 的 USB 口 2.观察硬盘指示灯是否亮起,执行 lsblk 查看设备节点 3.进行大文件读写操作,持续 10 分钟 4.查看系统日志是否有供电不足或设备掉线信息 预期结果: 1.移动硬盘正常启动,系统可识别并读写 2.长时间读写过程中无设备掉线、无数据损坏 3.系统日志无 over-current 或供电相关报错 2.4. 异常场景测试 1.热插拔测试:在数据传输过程中插拔 USB 设备,验证系统稳定性 2.低电压测试:降低开发板供电电压至 4.5V,验证 USB 设备是否正常工作 3.多设备并发测试:同时插入多个 USB 设备,验证 Hub 负载能力 3.Type-C 转 HDMI/DP 输出测试3.1 视频输出功能测试 前置条件: 1.开发板上电正常,系统启动完成 2.Type-C 转 HDMI/DP 转接器连接正常,显示器通电 操作步骤: 1.将 Type-C 端插入开发板 Type-C 接口,HDMI/DP 端插入显示器 2.执行显示配置命令(Linux:xrandr;Android:系统设置) 3.切换显示输出到 HDMI,设置分辨率为 1080P@60Hz 4.观察显示器画面,检查是否有花屏、黑屏、闪烁 预期结果: 1.显示器自动点亮,显示开发板桌面 / 画面 2.分辨率、刷新率可正常配置,画面清晰无失真 3.无花屏、无黑屏、无闪烁、无延迟 3.2 音视频同步输出测试 前置条件: 1.同 3.1 2.显示器支持 HDMI/DP 音频输出 操作步骤: 1.播放 1080P 测试视频(带音轨) 2.观察画面流畅度,同时监听显示器扬声器 3.检查音画是否同步,有无杂音、断音 预期结果: 1.视频画面流畅,帧率稳定(≥30fps) 2.音画同步,无延迟、无卡顿 3.声音清晰,无杂音、无断音、无爆音 3.3 热插拔测试 前置条件: 同 3.1 操作步骤: 1.先连接 Type-C 转 HDMI/DP,确认显示正常 2.拔掉 HDMI/DP 端,观察系统反应 3.重新插入 HDMI/DP 端,观察系统反应 4.重复热插拔 10 次,记录每次结果 预期结果: 1.拔掉 HDMI/DP 后,系统自动切回板载显示或黑屏(符合设计预期) 2.重新插入后,显示器自动恢复显示,无需手动配置 3.热插拔过程中无系统崩溃、无驱动报错 3.4. 异常场景测试 1.分辨率切换测试:在 720P/1080P/4K 之间切换,验证显示兼容性 2.长时间播放测试:连续播放视频 24 小时,验证稳定性 3.低分辨率输出测试:设置为 480P,验证向下兼容能力 四、显示与视频接口测试1.HDMI输出测试1.规格说明: | 接口 | 核心规格 | 关键限制 |
|---|
| HDMI 2.1 | 单接口、支持 8K@30Hz/4K@60Hz、HDCP2.3 | 需 HDMI2.1 认证线缆,最大带宽 48Gbps |
1.显示接口及分辨率列表查询 | 代码块 |
|---|
| # 图形界面(X11)- 直观查看支持的分辨率/刷新率/HDCP状态
xrandr --verbose | grep -E "HDMI|DP|3840|7680|HDCP" |
2.音频输出测试步骤(命令行操作) | 代码块 |
|---|
| # 步骤1:通过adb连接设备(确保设备已开启调试模式)
adb shell
# 步骤2:推送测试音频文件到设备(电脑端执行)
adb push C:\Users\Administrator\Desktop\test.wav /test.wav
# 步骤3:查看设备音频输出列表(确认card编号对应关系)
aplay -l
# 步骤4:HDMI0音频输出测试
aplay -D plughw:0,0 /test.wav
# 预期现象:HDMI连接的显示设备播放音频
# 步骤5:DP1音频输出测试
aplay -D plughw:4,0 /test.wav
# 预期现象:DP连接的显示设备播放音频
|
2.Camera(摄像头)功能测试| 测试目的 | 内容 |
|---|
| 测试目的 | 验证开发板 MIPI CSI/USB 摄像头接口的硬件连接有效性及视频采集功能。 | | 前提条件 | 1. 开发板已上电并进入 Linux系统; 2. 摄像头已正确连接(MIPI CSI 排线插紧)。 |
测试步骤: 步骤1:摄像头设备节点识别测试 1.打开终端,执行以下命令查看系统是否识别到摄像头设备: 2.【补充校验】执行以下命令确认设备可用性(可选,增强严谨性): | 代码块 |
|---|
v4l2-ctl --list-devices |
步骤 2:摄像头实时预览测试 1.开发板接有 HDMI显示器,执行以下命令进行实时预览: | 代码块 |
|---|
gst-launch-1.0 v4l2src device=/dev/video22 ! videoconvert ! autovideosink |
2.观察 HDMI 显示器画面,持续预览 10 秒后,按 Ctrl + C 停止命令。 预期结果:HDMI 显示器上出现清晰、流畅的实时视频画面,无花屏、无卡顿、无黑屏;停止命令后终端无 “Internal data stream error” 类核心报错。 3.视频硬解码性能测试1.测试环境(MPP 视频硬解码设备) 基于 Rockchip MPP(Media Process Platform)框架的硬解码工具信息: | 项目 | 详情 |
|---|
| 工具名称 | ppvidedec | | 工具版本 | 1.14.4 | | 依赖库路径 | /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrockchipmpp.so | | 支持编码格式 | HEVC/H.265、AVC/H.264、VP8、VP9 | | 解码类型 | 硬件加速解码 | | 最大解码能力 | 8K 10-bit 视频解码,支持 8K 60Hz 视频输出 |
2.测试步骤: 2.1.准备测试视频: | 代码块 |
|---|
| #1.本地测试视频路径:
C:\Users\Administrator\Desktop\test_video\4K_60fps.mp4
# 2.通过 ADB 将视频推送至开发板:
adb push "C:\Users\Administrator\Desktop\boot\4K_60fps.mp4" /tmp/
|
2.2.执行硬解码测试(以 H.264 格式为例)
| 代码块 |
|---|
| # 使用gst-launch-1.0调用 MPP 硬解码工具,验证解码功能:
gst-launch-1.0 filesrc location=/tmp/4K_60fps.mp4 ! \
qtdemux ! \
h264parse ! \
mppvideodec ! \
videoconvert ! \
autovideosink |
2.3.测试验证要点 - 视频播放状态:需无花屏、绿屏、卡顿等异常现象;
- 日志信息:终端输出中不得出现
decode error、Resource not found、pipeline doesn't want to preroll等报错,需呈现正常启动流程(示例如下); - 显示效果:执行播放命令后,显示界面应呈现完整、清晰的视频画面(无解码异常导致的画面畸变、色彩失真)。
| 代码块 |
|---|
| Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Prerolled, waiting for async message to finish...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
#日志逐行说明:
#Setting pipeline to PAUSED ...:GStreamer 管道进入暂停状态,开始初始化音视频解码组件(如 MPP 硬解码器),无报错代表组件加载初始化无异常;
#Pipeline is PREROLLING ...:管道进入预滚动阶段,开始读取视频文件并解析码流,为硬解码做数据准备;
#Pipeline is PREROLLED ...:预滚动完成,视频码流解析成功,RK3566 的 MPP 硬解码单元已获取有效数据;
#Prerolled, waiting for async message to finish...:预滚动完成后等待异步消息确认,是 GStreamer 适配嵌入式设备的正常等待流程,无异常;
#Setting pipeline to PLAYING ...:管道切换至播放状态,硬解码开始输出视频帧至显示设备;
#New clock: GstSystemClock:系统时钟同步完成,音视频时序匹配,无卡顿、音画不同步风险。 |
(注:配图为视频正常播放时的界面示例,可直观验证画面无畸变、显示正常)
Image Modified
3.开启第二个终端进行cpu占用率监控 3.1操作步骤 | 代码块 |
|---|
| # 第一步:进入ADB交互式shell
adb shell
# 第二步:在shell中执行top命令(此时有TTY环境,可正常运行)
top -n1 | head -20 |
3.2系统状态输出示例(终端执行后输出如下,红框为核心监控项) | 代码块 |
|---|
| #
top - 06:01:06 up 17:57, 1 user, load average: 2.10, 2.61, 2.56
Tasks: 276 total, 2 running, 274 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.8 us, 6.0 sy, 0.0 ni, 90.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3899.3 total, 91.5 free, 822.6 used, 2985.2 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1694.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1981 root 20 0 4747336 266284 215960 R 50.0 6.7 877:37.20 Xorg
2456 blueber+ 20 0 1839264 74872 56884 S 12.5 1.9 60:46.06 xfwm4
2513 blueber+ 20 0 314400 39220 29936 S 12.5 1.0 44:54.98 xfce4-p+
38043 root 20 0 529528 23188 11316 S 12.5 0.6 0:13.87 gst-lau+
38263 root 20 0 9048 3400 2712 R 6.2 0.1 0:00.02 top
1 root 20 0 165012 9932 7220 S 0.0 0.2 5:17.56 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.45 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par+
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_perc+
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tas+
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tas+
11 root 20 0 0 0 0 S 0.0 0.0 0:04.57 ksoftir+ |
3.3状态分析 | 监控项 | 结果 | 说明 |
|---|
| CPU 整体负载 | 用户 3.8% + 系统 6.0% + 空闲 90.2% | 空闲占比超 90%,CPU 资源冗余充足;当前高占比进程为桌面服务(Xorg、xfwm4),属于系统基础负载 | | 内存状态 | 总 3899MB,已用 829MB,可用 2968MB | 内存剩余充足,无内存不足风险 | | 关键进程 CPU 占比 | 桌面服务(Xorg)占 50%,终端(tilda)占 12.5% | 若此时运行视频播放进程,需重点关注其 % CPU 值(硬解码生效时通常<10%) | | 内存占用 | 已用 829MB,缓存占 2864MB | 内存缓存占比高,系统数据读写效率有保障 |
3.4测试结论:视频功能播放正常,无卡顿、花屏现象;CPU 占用率低(硬解码加速生效),系统资源负载符合预期。
声卡编号(card) | 设备标识 | 设备编号(device) | 硬件对应 | 核心功能 | 适用场景 |
|---|
card 0 | rockchip,es8388-codec | device 0 | 板载 ES8388 音频 Codec | 模拟音频输出(3.5mm 耳机 / 喇叭)+ 音频解码 | 耳机播放(核心设备) | | card 1 | rockchip,hdmi0 | device 0 | HDMI 接口音频通道 | 数字音频输出(HDMI 显示器 / 电视) | HDMI 音频播放 |
| 代码块 |
|---|
| # 步骤1:验证ADB连接(避免设备未连接导致后续操作失败)
adb devices
# 预期输出:列出设备序列号,状态为device(若显示offline/未列出,重新插拔USB/重启调试)
# 步骤2:推送测试音频文件到设备(电脑端执行)
adb push C:\Users\Administrator\Desktop\test.wav /test.wav
# 步骤3:进入ADB交互式shell(后续命令均在设备端执行)
adb shell
# 步骤4:查看设备音频输出列表(确认card编号对应关系)
aplay -l
# 步骤5:HDMI0音频输出测试
aplay -D plughw:1,0 /test.wav
# 预期现象:HDMI连接的显示设备播放音频
# 步骤6:板载音频(耳机)输出测试
aplay -D plughw:0,0 /test.wav
# 预期现象:3.5mm耳机播放音频
# 步骤7:硬件功能验证(正弦波测试,排除文件本身问题)
speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2
# 预期现象:耳机输出1000Hz双声道正弦蜂鸣声
|
测试项 | 操作命令 | 预期结果 |
|---|
HDMI0 音频输出 | aplay -D plughw:1,0 /test.wav | 显示设备正常播放音频 | | 板载耳机输出 | aplay -D plughw:0,0 /test.wav | 耳机正常播放音频 | | 硬件正弦波测试 | speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2 | 耳机输出蜂鸣声 |
1.列出所有音频采集设备 | 代码块 |
|---|
| # 查看系统音频设备列表(重点关注“Capture”(输入)设备)
arecord -l
|
2.典型输出示例 | 代码块 |
|---|
| **** List of CAPTURE Hardware Devices ****
card 0: rockchipes8388c [rockchip,es8388-codec], device 0: dailink-multicodecs ES8323 HiFi-0 [dailink-multicodecs ES8323 HiFi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: rockchipes7210 [rockchip,es7210], device 0: fe480000.i2s-ES7210 4CH ADC 0 ES7210 4CH ADC 0-0 [fe480000.i2s-ES7210 4CH ADC 0 ES7210 4CH ADC 0-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
|
3.结果解析 | 设备类型 | 设备名 / 驱动 | 设备编号(device) | 硬件对应 | 核心功能 | 能否用于耳机播放 |
|---|
| card 0 | rockchip,es8388-codec | device 0 | 板载 ES8388 codec音频解码 / 模拟输出 | 音频解码 / 模拟输出(3.5mm 耳机 / 线路输出) | ✅ 是(核心耳机设备) | | card 2 | rockchip,es7210 | device 0 | ES7210 ADC | 4 通道音频采集(麦克风 / 线路输入) | ❌ 否(仅输入) |
4.录音测试(实时采集+播放) | 代码块 |
|---|
| # 功能:实时采集音频输入(hw:1,0)并输出到音频输出(hw:1,0)
# 参数说明:
# - arecord端:
# -D hw:0,0:指定音频输入设备(需根据实际`arecord -l`结果调整)
# -r 48000:采样率48000Hz(适配多数音频设备)
# -c 2:立体声采集(若MIC为单声道,可改为-c 1)
# -f s16_le:16位小端音频格式(通用兼容格式)
# -t raw:以原始格式传输(避免文件编码开销)
# - aplay端:
# -D hw:1,0:指定音频输出设备(如HDMI/板载扬声器)
# - 其余参数与arecord保持一致(确保格式匹配)
# - &:后台运行(避免终端阻塞)
arecord -D hw:0,0 -r 48000 -c 2 -f s16_le -t raw | aplay -D hw:1,0 -r 48000 -c 2 -f s16_le -t raw &
|
- 执行命令:在终端输入上述命令并回车;
- 触发音频输入:对着 MIC 说话 / 播放声音;
- 验证效果:从音频输出设备(扬声器 / 耳机)能实时听到采集的声音,无杂音、卡顿、延迟(<200ms)即为测试通过;
- 停止测试:执行
kill %1(后台任务编号)终止实时采集。
- 若执行报错
Device or resource busy:先执行killall arecord aplay关闭占用音频设备的进程,再重新测试; - 若无声音:检查
-D参数的设备编号(通过arecord -l/aplay -l确认正确的输入 / 输出设备); - 若杂音较大:将
-c 2改为-c 1(单声道),或调整采样率为44100。
六、存储接口测试M.2接口测试1.硬件信息完整性 - 接口类型:PCIE2.0 *1 M.2 M-Key 5Gbps
- 硬件安装:将 M.2 SSD 插入开发板 M.2 插槽
2.基础连接有效性 1.设备识别验证 | 代码块 |
|---|
| # 查看系统是否识别到M.2 SSD
lsblk |
预期结果:输出中显示 SSD 对应的磁盘设备(如nvme0n1)。 2.磁盘信息读取 | 代码块 |
|---|
| # 查看M.2 SSD的详细信息(如容量、接口协议)
sudo fdisk -l |
预期结果:显示 SSD 的容量、分区表类型(如 GPT),PCIe x4 总线 + NVMe 存储协议。 3.读写性能测试 | 代码块 |
|---|
| # 安装测试工具
sudo apt install hdparm fio
# 测试读取性能
sudo hdparm -tT /dev/nvme0n1 # 替换为实际SSD设备名
# 测试随机读写性能(示例:1GB数据)
fio --name=ssd-test --filename=/dev/nvme0n1 --size=1G --rw=randrw --bs=4k --numjobs=4 --iodepth=64 --runtime=30 --time_based |
七、无线通信模块测试1.WIFI测试2.基础连接稳定性 1.启动NetworkManager服务 | 代码块 |
|---|
| sudo systemctl start NetworkManager |
2.扫描并连接WiFi网络 | 代码块 |
|---|
| sudo nmcli dev wifi rescan # 重新扫描WiFi网络
sudo nmcli dev wifi list # 查看可用WiFi列表(可选)
sudo nmcli dev wifi connect "WiFi名称" password "WiFi密码" ifname wlan1 |
3.网络连通性测试 4.示例命令 | 代码块 |
|---|
| sudo nmcli dev wifi connect "Hi nova 9 Pro" password "12345678" ifname wlan1 |
3.Wi-Fi 网络 TCP/UDP 协议性能测试 1.环境准备: 两台测试设备(如开发板 + PC),确保处于同一网络(WiFi / 以太网); 安装 Iperf3
| 代码块 |
|---|
| # Debian/Ubuntu
sudo apt install iperf3 |
2.角色定义: 服务端(Server):接收数据的设备; 客户端(Client):发送数据的设备。 3.TCP 带宽测试(常用) | 代码块 |
|---|
| # 服务端默认监听5201端口
iperf3 -s |
| 代码块 |
|---|
| # 测试TCP带宽(持续10秒,默认)
iperf3 -c [服务端IP] |
| 代码块 |
|---|
| # 测试30秒,每2秒输出一次实时数据
iperf3 -c [服务端IP] -t 30 -i 2
# 测试双向带宽(服务端/客户端互传)
iperf3 -c [服务端IP] -d |
4.UDP 丢包 / 延迟测试 | 代码块 |
|---|
| # 测试UDP(指定带宽100Mbps)
iperf3 -c [服务端IP] -u -b 100M |
5.结果解读(示例) TCP 测试结果 | 代码块 |
|---|
| [ 5] local 192.168.1.10 port 5001 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec # 实际带宽:943Mbps |
UDP测试结果 | 代码块 |
|---|
| [ 5] local 192.168.1.10 port 5001 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.035 ms 0/85000 (0%) # 丢包率:0% |
6.常见场景测试 | 测试目标 | 命令示例 |
|---|
| 长连接稳定性(1 小时) | iperf3 -c [IP] -t 3600 | | 多线程并发测试 | iperf3 -c [IP] -P 4(4 线程) | | 限制带宽测试 | iperf3 -c [IP] -b 500M(限制为 500Mbps) |
2.蓝牙连接测试
2.进入蓝牙命令模式 | 代码块 |
|---|
| # 通过adb连接设备
adb shell
# 启动蓝牙控制工具
sudo bluetoothctl |
3.扫描并连接蓝牙设备 | 代码块 |
|---|
| scan on # 开启蓝牙扫描(按Ctrl+C停止扫描)
trust [设备MAC地址] # 信任目标设备
pair [设备MAC地址] # 配对目标设备
connect [设备MAC地址] # 连接目标设备 |
4.操作示例 | 代码块 |
|---|
| # 扫描后,对MAC为7C:B4:37:11:5B:83的设备执行操作
trust 7C:B4:37:11:5B:83
pair 7C:B4:37:11:5B:83
connect 7C:B4:37:11:5B:83 |
|