目录

一、测试文件下载与设备基础信息

1.测试文件下载

测试音乐下载 ：test.wav
串口工具下载：MobaXterm_Portable_v23.0_cn.zip

2. 设备基础信息

3. 核心硬件配置

4. 供电参数

二、电源基础测试

1. 电源接口功能验证

• 验证设备电源接口的兼容性、电气性能及安全性，确保符合供电参数要求。

2. 测试环境与工具适应性

3.基础测试流程规范

1.直流电源接口兼容性测试

• 测试步骤：
  1. 确认直流电源适配器规格为 “12V 2A DC”，接口尺寸 “5.5mm×2.0mm”；
  2. 将适配器接入设备电源接口，通电后观察设备是否正常开机。
• 判定标准：
   接口可稳定插入 / 拔出，设备正常开机无异常。

2.输入电压下限验证

• 测试步骤：
  1. 使用可调直流电源，将电压调至11.5V（低于 12V），接入设备；
  2. 观察设备是否出现 “无法开机” 等异常现象。
• 判定标准：
   电压低于 12V 时，设备无法正常开机（与供电参数 “注意” 项一致）。

三、有线通信接口测试

1.Debug 串口（UART）测试

步骤 1：硬件连接

1. 按开发板手册标注的 Debug 口引脚，将 USB 转 TTL 串口线对应连接：
   • 开发板 Debug 口 TX → 串口线 RX
   • 开发板 Debug 口 RX → 串口线 TX
   • 开发板 Debug 口 GND → 串口线 GND
      （⚠️ 注意：TX/RX 交叉连接，严禁接反；3.3V 电平串口禁止接 5V，避免烧损）
    
2. 将 USB 转 TTL 串口线的 USB 端插入 PC 主机 USB 接口。 

步骤 2：PC 端串口工具配置 

1. 打开串口工具（以 MobaXterm 为例），进行参数配置：
   • 串口端口：在 PC 设备管理器中查看 “端口 (COM 和 LPT)”，选择串口线对应的 COM 口（如 COM3）；
   • 波特率：1500000（开发板默认 Debug 口波特率，需与内核启动参数一致）；
   • 数据位：8；
   • 停止位：1；
   • 校验位：None；
   • 流控：None；
2. 点击“会话”选择“Serial”，选择对应的Serial端口和波特率：1500000，点击 “OK” 打开串口连接。

步骤 3：启动日志输出测试

1. 给开发板上电，观察 PC 端串口工具的输出：
   • 记录从 “U-Boot 启动” 到 “内核初始化” 再到 “系统登录提示符” 的完整日志；
   • 重点检查是否有 “Serial: xxx”“console=ttyS2,1500000” 等串口相关初始化日志。

2.USB 2.0/3.0接口测试

1. 设备连接状态识别

 通过以下命令确认设备是否接入系统并获取设备节点信息：

# 查看所有块设备，识别USB对应的设备节点（如/dev/sda1）
lsblk
# 查看USB设备详细信息，包括控制器和设备ID
lsusb

结果说明：lsusb输出中，ID 1d6b:0002对应 USB2.0 控制器，ID 1d6b:0003对应 USB3.0 控制器，可通过设备挂载的总线判断其关联的 USB 版本。

2. 设备配套 USB 版本兼容性

通过设备速度参数精准判断 USB 版本，USB2.0 对应高速（480Mbps），USB3.0 对应超高速（5000Mbps），操作如下：

1.查看设备速度文件

# 遍历所有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。

3.传输性能测试

传输速率是 USB2.0 与 USB3.0 的核心差异点，USB2.0 理论速率 480Mbps，USB3.0 理论速率 5Gbps。以下提供两种常用测试方法，分别适用于存储设备和网络类 USB 设备。

1. 简易测试：dd 命令

dd命令可快速测试读写速率，适合初步验证，测试时需先挂载 USB 设备。

 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.测试后清理临时文件：

rm /mnt/usb/testfile

 结果说明：命令执行完毕后会显示传输时间和速率，USB2.0 实际写速率通常在 10 - 30MB/s，USB3.0 实际写速率通常在 50 - 150MB/s（受设备本身性能影响）。

2. 专业测试：fio 工具

fio工具支持复杂的 IO 场景测试，结果更全面，适合深度性能评估。

 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

I. Download of Test Files & Basic Device Information

1. Test File Download 

• Test music download: test.wav
• Serial port tool download: MobaXterm_Portable_v23.0_cn.zip

2. Basic Device Information

3. Hardware Configuration

4. Power Supply Parameters

II. Basic Power Supply Test

1.Power Interface Function Verification

 Verify the compatibility, electrical performance and safety of the device power interface to ensure compliance with power supply parameter requirements.
 

2.Adaptability of Test Environment and Tools

3. Standard Basic Test Procedures

(1) DC Power Interface Compatibility Test

 Test Steps:
 Confirm the DC power adapter specification is "12V 2A DC" with a connector size of "5.5mm×2.0mm";
 Connect the adapter to the device power interface, and check whether the device powers on normally after energization.
 Judgment Criteria:
 The connector can be stably plugged in/unplugged, and the device powers on normally without abnormalities.
 

(2) Input Voltage Lower‑Limit Verification

 Test Steps:
 Use an adjustable DC power supply, set the voltage to 11.5V (lower than 12V), and connect it to the device;
 Observe whether abnormalities such as "failing to power on" occur.
 Judgment Criteria:
 The device cannot power on normally when the voltage is lower than 12V (consistent with the note in power supply parameters).

III. Wired Communication Interface Test

1.Debug Serial Port (UART) Test

Step 1: Hardware Connection

 
According to the Debug port pinout marked in the development board manual, connect the USB‑to‑TTL serial cable correspondingly:
 

• Board Debug TX → Serial Cable RX
• Board Debug RX → Serial Cable TX
• Board Debug GND → Serial Cable GND

 
⚠️ Note: Cross‑connect TX/RX; reverse connection is strictly prohibited. Do not connect a 5V serial cable to the 3.3V‑level Debug port to avoid hardware damage.
 
Plug the USB end of the USB‑to‑TTL cable into a USB port of the PC host.
 

Step 2: Serial Tool Configuration on PC

 
Open the serial tool (taking MobaXterm as an example) and configure parameters as follows:
 

• Serial Port: Check Ports (COM & LPT) in Windows Device Manager and select the COM port corresponding to the serial cable (e.g. COM3).
• Baud Rate: 1500000 (default Debug port baud rate of the board, consistent with kernel boot parameters)
• Data Bits: 8
• Stop Bits: 1
• Parity: None
• Flow Control: None

 
Click Session → select Serial, choose the corresponding serial port and baud rate 1500000, then click OK to establish serial connection.
 

Step 3: Boot Log Output Test

 Power on the development board and observe output on the PC‑side serial tool:
 Record complete logs from U‑Boot startup, through kernel initialization, to the system login prompt.
 Focus on checking serial‑related initialization logs such as Serial: xxx and console=ttyS2,1500000.

2. USB 2.0 / 3.0 Interface Test

(1) Device Connection Status Identification

Use the following command to confirm whether the device is connected to the system and obtain device node information:

# List all block devices to identify the USB device node (e.g., /dev/sda1)
lsblk

# Display detailed USB device information, including controller and device ID
lsusb

Result Description

 
In the lsusb output:
 

• ID 1d6b:0002 corresponds to the USB 2.0 controller
• ID 1d6b:0003 corresponds to the USB 3.0 controller

 
The USB version associated with the device can be determined by the bus it is connected to.
 

2. Compatibility of the Device with the Corresponding USB Version

 
The USB version can be accurately determined by the device speed parameter:
 

• USB 2.0: High-speed (480 Mbps)
• USB 3.0: Super-speed (5000 Mbps / 5 Gbps)

 
Procedure:
 

1. Check the Device Speed File

# Traverse all USB devices and output their transfer speed
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. Verification via Detailed Information

 # Check detailed parameters of the specified USB device and search for the Speed field lsusb -v | grep -E "Speed|Device"

 
 
Result Description: In the output, Speed: 480Mbit/s corresponds to USB 2.0, and Speed: 5000Mbit/s corresponds to USB 3.0.
 

3. Transfer Performance Test

 
The transfer rate is the core difference between USB 2.0 and USB 3.0. The theoretical rate of USB 2.0 is 480Mbps, and that of USB 3.0 is 5Gbps. Two common test methods are provided below, suitable for storage devices and network USB devices respectively.
 

1. Simple Test: dd Command

 
The dd command can quickly test read/write speeds, suitable for preliminary verification. The USB device must be mounted before testing.
 

1.1 Mount the USB Device: 
 

# Assuming the USB device node is /dev/sda1 confirmed by lsblk, create a mount point and mount
mkdir -p /mnt/usb
mount /dev/sda1 /mnt/usb

1.2 Test Sequential Write Speed:

# Write 1GB of zero data to the USB device, bypass cache to ensure real results
dd if=/dev/zero of=/mnt/usb/testfile bs=1M count=1024 conv=sync oflag=direct

1.3 Test Sequential Read Speed:

# Read the test file from the USB device and discard it to test read speed
dd if=/mnt/usb/testfile of=/dev/null bs=1M iflag=direct

1.4 Clean Up Temporary Files After Test:

rm /mnt/usb/testfile

Result Description: The command will display the transfer time and speed upon completion. The actual write speed of USB 2.0 is usually 10 - 30MB/s, and USB 3.0 is usually 50 - 150MB/s (affected by the device's own performance).
 

2. Professional Test: fio Tool

 
The fio tool supports complex IO scenario testing with more comprehensive results, suitable for in-depth performance evaluation.
 

2.1 Install fio:

# Ubuntu/Debian
sudo apt install fio -y

 2.2 fio Test Commands:

# Sequential Write Test
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

# Sequential Read Test
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

# Random Write Test
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

# Random Read Test
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

# Random Read/Write Mixed Test (default 50:50 ratio)
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

IV. Type-C Interface Test

1. ADB Function Test

1.1 ADB Basic Connection Test

 
Test Purpose: Verify that the Type-C interface can establish an ADB connection normally and the device can be recognized by the PC.
 
Test Steps:
 

1. Connect the device under test and the PC with a Type-C data cable.
2. Enable Developer Options → USB Debugging on the device.
3. Execute adb devices on the PC to check if the device is recognized.
4. Execute adb shell to verify access to the device command line.

 
Expected Results:
 

1. adb devices outputs the device serial number with status device.
2. Successfully enter the device shell without connection timeout or permission denial.

1.2 ADB Core Command Execution Test

 
Test Purpose: Verify that core ADB commands can be executed normally over the Type-C link.
 
Test Steps:
 

1. File Transfer:
   • Execute adb push test_file /data/ to push a file to the device.
   • Execute adb pull /data/test_file ./ to pull the file to the PC.
   
    
2. Device Control:
   • Execute adb reboot to restart the device, then run adb devices again after reboot.
   
    
3. Log Capture:
   • Execute adb logcat -d > adb_log.txt to capture system logs.
   
     
   Expected Results:
    

1. File transfer succeeds without failure; the pulled file matches the original size.
2. ADB connection automatically recovers after reboot.
3. Log file is not empty and contains valid runtime logs.

1.3 Type-C Plugging & Stability Test

 
Test Purpose: Verify the stability of the ADB connection during plugging/unplugging and cable movement.
 
Test Steps:
 

1. Single Plug/Unplug: Repeat 10 times, run adb devices after each.
2. Continuous Plug/Unplug: Rapidly repeat 20 times with 1–2 second intervals.
3. Movement Test: Gently shake the cable while connected and observe the connection.

 
Expected Results:
 

1. Device is recognized normally every time, no offline status.
2. ADB connection remains stable without IO errors during movement.

1.4 Type-C High-Load Stability Test

 
Test Purpose: Verify ADB stability under high-load scenarios.
 
Test Steps:
 

1. Large File Transfer: Push a 1GB file while running adb logcat.
2. Concurrent Commands: Run adb push, adb shell top, and adb logcat simultaneously.
3. Long-Term Connection: Maintain ADB connection for 24 hours, run adb devices hourly.

 
Expected Results:
 

1. ADB remains stable during large file transfers; log capture works normally.
2. No freezes or timeouts under concurrency; CPU usage ≤ 80%.
3. Connection status stays device for 24 hours without disconnection.

2. Type‑C to Hub (USB) Test

2.1 Device Recognition and Compatibility Test

 
Prerequisites:
 

1. The development board is powered on normally and the system startup is completed.
2. The Type‑C to USB Hub is connected properly.

 
Test Steps:
 

1. Insert the Type‑C end into the Type‑C port of the development board.
2. Plug USB devices (USB flash drive, mouse, keyboard) into the USB ports of the Hub in sequence.
3. Run the command lsusb to view the device list.
4. Check system logs with dmesg | grep usb.

 
Expected Results:
 

1. All USB devices are correctly recognized by the system, and corresponding device IDs can be seen in the lsusb output.
2. There are no USB device recognition failures or error messages in system logs.
3. The USB flash drive can be mounted/read/written normally; the mouse and keyboard can respond properly.

2.2 Data Transfer Speed Test

 
Prerequisites:
 

1. Same as 2.1.
2. Prepare a 1GB test file (test.img).

 
Test Steps:
 

1. Insert a USB 3.0 flash drive and mount it to /mnt/usb.
2. Execute the file copy command:

dd if=/dev/zero of=/mnt/usb/test.img bs=1M count=1024

1. Record transmission time and calculate speed: Speed = 1024MB / Time Consumed (seconds)
2. Copy files back to the development board in reverse direction and repeat the test 3 times.

 
Expected Results:
 

1. Transmission speed ≥ 80MB/s (approx. 640Mbps) under USB 3.0 mode.
2. Transmission speed ≥ 30MB/s (approx. 240Mbps) under USB 2.0 mode.
3. No data loss, transmission interruption or file corruption.

2.3 Power Supply Capacity Test

 
Prerequisites:
 

1. Same as 2.1.
2. Prepare a 2.5‑inch portable hard disk (requiring power supply above 5V/0.5A).

 
Test Steps:
 

1. Plug the portable hard disk into the USB port of the Hub.
2. Check whether the hard disk indicator light is on, and run lsblk to view device nodes.
3. Perform large‑file read‑write operations for 10 minutes continuously.
4. Check system logs for under‑power or device disconnection information.

 
Expected Results:
 

1. The portable hard disk starts normally and can be recognized, read and written by the system.
2. No device disconnection or data corruption during long‑time read‑write operations.
3. No over‑current or power‑supply‑related errors in system logs.

2.4 Abnormal Scenario Test

1. Hot‑swap Test: Plug and unplug USB devices during data transmission to verify system stability.
2. Low‑voltage Test: Reduce the power supply voltage of the development board to 4.5V to verify whether USB devices work normally.
3. Multi‑device Concurrency Test: Plug in multiple USB devices simultaneously to verify the load capacity of the Hub.

3. Type‑C to HDMI/DP Output Test

3.1 Video Output Function Test

 
Prerequisites:
 

1. The development board is powered on normally and the system startup is completed.
2. The Type‑C‑to‑HDMI/DP adapter is properly connected, and the monitor is powered on.

 
Test Steps:
 

1. Insert the Type‑C end into the Type‑C port of the development board, and connect the HDMI/DP end to the monitor.
2. Execute display configuration commands (Linux: xrandr; Android: System Settings).
3. Switch display output to HDMI and set the resolution to 1080P@60Hz.
4. Observe the monitor screen and check for screen tearing, black screen or flickering.

 
Expected Results:
 

1. The monitor lights up automatically and displays the development board desktop/image.
2. Resolution and refresh rate can be configured normally with clear and undistorted images.
3. No screen tearing, black screen, flickering or lag.

3.2 Audio‑Video Synchronous Output Test

 
Prerequisites:
 

1. Same as 3.1.
2. The monitor supports HDMI/DP audio output.

 
Test Steps:
 

1. Play a 1080P test video (with audio track).
2. Observe video smoothness and listen to the monitor speaker simultaneously.
3. Check audio‑video synchronization and whether there is noise or audio dropout.

 
Expected Results:
 

1. Smooth video playback with stable frame rate (≥30fps).
2. Audio‑video synchronization with no delay or stuttering.
3. Clear sound with no noise, audio dropout or popping noise.

3.3 Hot‑Plug Test

 Prerequisites:
 Same as 3.1.
 
Test Steps:
 

1. Connect the Type‑C‑to‑HDMI/DP adapter first and confirm normal display.
2. Unplug the HDMI/DP end and observe system response.
3. Re‑insert the HDMI/DP end and observe system response.
4. Repeat hot‑plug operation 10 times and record each result.

 
Expected Results:
 

1. After unplugging HDMI/DP, the system automatically switches back to on‑board display or goes black (consistent with design expectations).
2. After re‑insertion, the monitor automatically resumes display without manual configuration.
3. No system crash or driver errors occur during hot‑plugging.

3.4 Abnormal Scenario Test

1. Resolution Switching Test: Switch among 720P/1080P/4K to verify display compatibility.
2. Long‑Duration Playback Test: Play video continuously for 24 hours to verify stability.
3. Low‑Resolution Output Test: Set resolution to 480P to verify downward compatibility.

IV. Display and Video Interface Test

1. HDMI Output Test

1. Specification Description

2. Resolution Verification (Including 8K/4K)

1. Query of Display Interfaces and Resolution List

# GUI (X11) - Intuitively view supported resolutions/refresh rates/HDCP status
xrandr --verbose | grep -E "HDMI|DP|3840|7680|HDCP"

2.Audio Output Test Steps (Command-Line Operation)

# Step 1: Connect to the device via adb (ensure the device has debugging mode enabled)
adb shell

# Step 2: Push the test audio file to the device (execute on the PC)
adb push C:\Users\Administrator\Desktop\test.wav /test.wav

# Step 3: View the device audio output list (confirm the corresponding card number)
aplay -l

# Step 4: HDMI0 audio output test
aplay -D plughw:0,0 /test.wav
# Expected result: The display device connected via HDMI plays audio

# Step 5: DP1 audio output test
aplay -D plughw:4,0 /test.wav
# Expected result: The display device connected via DP plays audio

2.Camera Function Test

Test Steps:
 
Step 1: Camera Device Node Identification Test
 

1. Open the terminal and run the following command to check whether the system recognizes the camera device:

测试步骤： 步骤1：摄像头设备节点识别测试 1.打开终端，执行以下命令查看系统是否识别到摄像头设备：

ls -l /dev/video*

2.[Supplementary Verification] Execute the following commands to confirm device availability (optional, for enhanced rigor):

v4l2-ctl --list-devices

Step 2: Camera Real-Time Preview Test
 

1. Connect the development board to an HDMI monitor, and execute the following command for real-time preview:

gst-launch-1.0 v4l2src device=/dev/video22 ! videoconvert ! autovideosink

Observe the picture on the HDMI monitor, press Ctrl + C to stop the command after continuous preview for 10 seconds.
 Expected Result: Clear and smooth real‑time video appears on the HDMI monitor without screen tearing, stuttering or black screen; no core errors such as "Internal data stream error" are displayed in the terminal after stopping the command.

3. Video Hard Decoding Performance Test

1. Test Environment (MPP Video Hard Decoding Device)
    Hard decoding tool information based on Rockchip MPP (Media Process Platform) framework:

Test Steps:
 2.1 Prepare test videos:

#1. Local test video path:C:\Users\Administrator\Desktop\test_video\4K_60fps.mp4
#2. Push the video to the development board via ADB:
adb push "C:\Users\Administrator\Desktop\boot\4K_60fps.mp4" /tmp/

 2.2.Perform hardware decoding test (take H.264 format as an example)

# Use gst-launch-1.0 to invoke the MPP hardware decoding tool and verify the decoding function:
gst-launch-1.0 filesrc location=/tmp/4K_60fps.mp4 ! \
qtdemux ! \
h264parse ! \
mppvideodec ! \
videoconvert ! \
autovideosink

2.3 Test Verification Points

 Video playback status: No abnormalities such as screen tearing, green screen, or stuttering shall occur;
 Log information: No errors including decode error, Resource not found, or pipeline doesn't want to preroll shall appear in the terminal output. A normal startup process shall be displayed (example shown below);
 Display effect: After executing the playback command, the display interface shall present a complete and clear video image (no image distortion or color distortion caused by decoding exceptions).
 
Example of normal log output (description)

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Prerolled, waiting for async message to finish...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

(Note: The attached picture is an example of the interface during normal video playback, which can intuitively verify that the picture is free of distortion and displayed normally.)

Image Added

3. Open a second terminal to monitor CPU usage

3.1 Operation Steps

# Step 1: Enter the ADB interactive shell
adb shell

# Step 2: Execute the top command in the shell (runs normally with TTY environment available)
top -n1 | head -20

  3.2 Example of system status output (the following content is displayed after terminal execution; core monitoring items are marked in the red box)

#
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 Status Analysis

3.4 Test Conclusion: The video plays normally without stuttering or screen tearing. The CPU usage is low (hardware decoding acceleration is effective), and the system resource load meets expectations.

V. Audio Interface Test

This test targets the device’s audio output interfaces (including onboard Codec and HDMI), and clarifies the hardware mapping relationship of each interface:

1. Test Preparation

1.1 Tools / Files

 
Test audio file: test.wav (recommended format: 16bit, 44.1kHz, stereo)
 
Debugging tools:
 

• PC side: adb (environment variables required)
• Device side: aplay (pre‑installed)

1.2 Hardware Connection

• For HDMI audio test: Connect an HDMI cable between the device’s HDMI port and an audio‑enabled display device (e.g., a monitor with built‑in speakers).
• For onboard audio test: Plug a 3.5 mm headphone into the onboard audio jack.

1. Audio Output Function Verification

# Step 1: Verify ADB connection (to avoid subsequent failures caused by disconnected device)
adb devices
# Expected output: List device serial number with status as device (re‑plug USB or restart debugging if offline or not listed)

# Step 2: Push test audio file to the device (run on PC side)
adb push C:\Users\Administrator\Desktop\test.wav /test.wav

# Step 3: Enter ADB interactive shell (execute subsequent commands on device side)
adb shell

# Step 4: List device audio outputs (confirm mapping of card numbers)
aplay -l

# Step 5: HDMI0 audio output test
aplay -D plughw:1,0 /test.wav
# Expected result: Audio plays on HDMI‑connected display device

# Step 6: On‑board audio (headphone) output test
aplay -D plughw:0,0 /test.wav
# Expected result: Audio plays through 3.5mm headphone

# Step 7: Hardware function verification (sine wave test to eliminate file‑related issues)
speaker-test -D hw:1,0 -t sine -f 1000 -c 2 -l 2
# Expected result: 1000 Hz dual‑channel sine beep sound outputs from headphones

Test Result Recording

2. Audio Input Function Verification

1. List all audio capture devices

# Check the system audio device list (focus on "Capture" (input) devices)
arecord -l

2.Typical Output Example

**** 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. Result Analysis

4.Recording Test (Real-time Capture + Playback)

Function: Capture audio input in real time (hw:1,0) and output to audio output (hw:1,0)
Parameter Description:
- arecord section:
-D hw:0,0: Specify the audio input device (adjust according to actual arecord -l results)
-r 48000: Sampling rate 48000Hz (compatible with most audio devices)
-c 2: Stereo capture (change to -c 1 if the MIC is mono)
-f s16_le: 16-bit little-endian audio format (universal compatible format)
-t raw: Transmit in raw format (avoid file encoding overhead)
- aplay section:
-D hw:1,0: Specify the audio output device (e.g. HDMI/onboard speaker)
Other parameters are consistent with arecord (ensure format matching)
- &: Run in the background (prevent terminal blocking)
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 &

Test Operations and Result Verification

 Execute Command: Enter the above command in the terminal and press Enter.
 Trigger Audio Input: Speak into the MIC or play audio.
 Verify Effect: Real‑time captured sound can be heard from audio output devices (speakers/headphones). The test passes if there is no noise, stuttering or delay (<200 ms).
 Stop Test: Run kill %1 (background task ID) to terminate real‑time capture.
 

Notes

• If the error Device or resource busy occurs: Run killall arecord aplay first to close processes occupying audio devices, then retest.
• If no sound is heard: Check the device ID for the -D parameter (confirm correct input/output devices via arecord -l/aplay -l).
• If there is excessive noise: Change -c 2 to -c 1 (mono), or adjust the sampling rate to 44100.

VI. Storage Interface Test

M.2 Interface Test

1. Hardware Information Integrity

 Interface Type: PCIE 2.0 ×1 M.2 M‑Key, 5 Gbps
 Hardware Installation: Insert the M.2 SSD into the M.2 slot on the development board.
 

2. Basic Connection Validity

1. Device Identification Verification

# Check whether the system recognizes the M.2 SSD.
lsblk

Expected Result: The corresponding disk device of the SSD (e.g., nvme0n1) is displayed in the output.

2.Disk Information Reading

# Check detailed information of the M.2 SSD (e.g., capacity, interface protocol).
sudo fdisk -l

Expected Result: Display SSD capacity, partition table type (e.g., GPT), PCIe x4 bus and NVMe storage protocol.
 3. Read‑Write Performance Test

# Install Test Tools
sudo apt install hdparm fio
# Test Read Performance
sudo hdparm -tT /dev/nvme0n1 # Replace with your actual SSD device name
# Test Random Read/Write Performance (Example: 1GB data)
fio --name=ssd-test --filename=/dev/nvme0n1 --size=1G --rw=randrw --bs=4k --numjobs=4 --iodepth=64 --runtime=30 --time_based

VII. Wireless Communication Module Test

1. Wi‑Fi Test

1. Hardware Specification Compliance

 
Wi‑Fi Model: AP6256, dual‑band Wi‑Fi 5 wireless network access compliant with IEEE 802.11a/b/g/n/ac.
 2. Basic Connection Stability

1. Start the NetworkManager Service

sudo systemctl start NetworkManager

2.Scan and connect to Wi‑Fi networks

sudo nmcli dev wifi rescan                 # 重新扫描WiFi网络
sudo nmcli dev wifi list                   # 查看可用WiFi列表（可选）
sudo nmcli dev wifi connect "WiFi名称" password "WiFi密码" ifname wlan1

3.Network Connectivity Test

ping www.baidu.com

4.Sample Commands

sudo nmcli dev wifi connect "Hi nova 9 Pro" password "12345678" ifname wlan1

3. Wi-Fi Network TCP/UDP Protocol Performance Test

1. Environment Preparation:

 
Two test devices (e.g., development board + PC), ensure they are on the same network (Wi-Fi/Ethernet);
 
Install Iperf3

3.Wi-Fi 网络 TCP/UDP 协议性能测试 1.环境准备： 两台测试设备（如开发板 + PC），确保处于同一网络（WiFi / 以太网）； 安装 Iperf3

# Debian/Ubuntu
sudo apt install iperf3

2. Role Definition

 Server: Device receiving data
 Client: Device sending data
 

3. TCP Bandwidth Test (Commonly Used)

 
Step 1: Start the server

# 服务端默认监听5201端口
iperf3 -s

Step 2: Initiate the test from the client

# 测试TCP带宽（持续10秒，默认）
iperf3 -c [服务端IP]

Extended Commands (Custom Parameters)

Extended Commands (Custom Parameters)

Test for 30 seconds, output real‑time data every 2 seconds

 
iperf3 -c [Server IP] -t 30 -i 2
 Test bidirectional bandwidth (data transmission between server and client)

 
iperf3 -c [Server IP] -d
 

4. UDP Packet Loss / Latency Test

 Step 1: Start the server
 iperf3 -s
 
Step 2: Initiate test from the client
 

Test UDP (bandwidth limited to 100 Mbps)

 
iperf3 -c [Server IP] -u -b 100M
 

5. Result Interpretation (Examples)

TCP Test Result

 [ 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 # Actual bandwidth: 943 Mbps
 

UDP Test Result

 [ 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%) # Packet loss rate: 0%
 

6. Common‑Scenario Tests

 
表格
 
 
 

2. Bluetooth Connection Test

1. Hardware Description

 
AP6256 is a Wi‑Fi 5 + Bluetooth dual‑mode module launched by AMPAK, supporting Bluetooth 5.2.
 

2. Enter Bluetooth Command Mode

Connect to the device via ADB

 
adb shell
 

Launch Bluetooth control utility

 
sudo bluetoothctl
 

3. Scan and Connect Bluetooth Devices

 scan on # Enable Bluetooth scanning (press Ctrl+C to stop scanning)
 trust [Device MAC Address] # Trust the target device
 pair [Device MAC Address] # Pair with the target device
 connect [Device MAC Address] # Connect to the target device
 

4. Operation Example

Perform operations on the device with MAC 7C:B4:37:11:5B:83 after scanning

 trust 7C:B4:37:11:5B:83
 pair 7C:B4:37:11:5B:83
 connect 7C:B4:37:11:5B:83
 

5. Test Result Judgment

 
After executing the connect command, the terminal outputs [CONN] Device 7C:B4:37:11:5B:83 Connected: yes, indicating successful Bluetooth connection.