Test File Download

uart file download ：uart
test.wav download ：test.wav
UartAssist.exe download：UartAssist.exe

Basic Equipment Information

1. Basic Equipment Information

2. Core Hardware Configuration

3. Power Supply Parameters

I. 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. Test Environment and Tool Adaptability

3. Basic Test Procedure Specifications

1. DC Power Interface Compatibility Test

• Test Steps:

  1.Confirm the DC power adapter is 12V 2A DC with 5.5mm×2.0mm interface size.

  2.Connect the adapter to the device power interface, then check if the device powers on normally.

• Judgment Standard:

  The power plug can be smoothly inserted and pulled out, and the device starts up normally without any abnormality. 

2. Input Voltage Lower Limit Verification

• Test Steps:

  1.Adjust the adjustable DC power supply to 11.5V (lower than 12V) and connect it to the device.

  2.Observe whether the device fails to boot or other abnormal conditions occur.

   
• Judgment Standard:

  The device cannot start normally when the voltage is lower than 12V, which is consistent with the notes of power supply parameters.

3. POE Interface Extended Power Supply Test (Optional) 

• Test Steps:

  1.Connect the POE module to the reserved POE interface of the device.

  2.Power on the POE module and observe the operating state of the device.

   
• Judgment Standard:

          The device can be stably powered by the POE module and operates normally.

II.Wired Communication Interface Test 

1.RS232 Serial Port Test

 RS232 corresponding device node: ttyS3 (V1.2 version) / ttyS4 (V1.4 version)

 Test Preparation:

1.Confirm the serial port node

# Method 1: List all serial ports
ls -la /dev/ttyS*

# Method 2: Determine by hardware version
# Check board version label or run:
cat /proc/device-tree/model
# If output contains V1.4, use /dev/ttyS4
# If output contains V1.2, use /dev/ttyS3

2.Two-minute Loopback Test

# Step 1: Hardware Short Connection (Required)
# Short TX (Pin 2) and RX (Pin 3) of the RS232 interface using a jumper wire

# Step 2: Prepare Test Tool
# Upload the UART test program to the device (if transferring from Windows)
adb push C:\Users\Administrator\Desktop\uart ./

# Step 3: Grant Permissions
chmod 777 ./uart

# Step 4: Execute Test
# Terminal 1: Receive data
cat /dev/ttyS3

# Terminal 2: Send data
./uart /dev/ttyS3
# Enter test text and check the reception result in Terminal 1

Output Example

# Terminal 2 Program Output Example:
# fcntl=0
# isatty success!
# fd-open=3
# set done!
# please input:         # Waiting for user input (e.g. 45 3A F7 98)

# Terminal 1 receives the data input from Terminal 2 (e.g. 45 3A F7 98)

2.RS485 Serial Port Test

Test Purpose
 Verify the bidirectional data communication function of the RS485 serial port (mapped to system device /dev/ttyS0) of the RK3588 device with the UART Assist tool on the computer side, ensuring the availability of the serial port hardware, driver and communication link.

1. Test Environment

3. Hardware Wiring 

1. Connect RK3588 RS485 pins to the USB-to-RS485 module:
   • RK3588 RS485_A → Module A
   • RK3588 RS485_B → Module B
   • RK3588 GND → Module GND (Common ground is required to avoid signal interference)
2. Connect the USB-to-RS485 module to the computer's USB port and install the corresponding driver (e.g. CH340 driver).

4. Test Steps

4.1 PC-side UART Assist Configuration 

1. Open the UART Assist tool and select the serial port corresponding to the USB-to-RS485 adapter (e.g. COM3);
2. Configure parameters: Baud rate 115200, Data bits 8, Parity none, Stop bits 1, Flow control none;
3. Click "Open Serial Port" to confirm a successful connection.

4.2 Unidirectional Transceiver Test (PC → RK3588)

1. Start serial port reception on the RK3588 side:

# Step 1: Prepare Test Tool
# Upload the UART test program to the device (if transferring from Windows)
adb push C:\Users\Administrator\Desktop\uart ./

# Step 2: Grant Permissions
chmod 777 ./uart

# Step 3: Execute Test
# Terminal 1: Receive data
cat /dev/ttyS0

# Terminal 2: Run the command tool to configure correct serial port parameters
./uart /dev/ttyS0

      2.Enter test data (e.g. "RK3588 RS485 Test") in UART Assist on the PC side, and click "Send" (as shown in the figure below);

Image Added

      3.Observe RK3588 Terminal 1 (as shown in the figure below). If the received test data is displayed, the unidirectional receiving function is normal.

Image Added

4.3 Unidirectional Transceiver Test (RK3588 → PC)

1.  Keep UART Assist on the PC side in the "Open" state;
2. Send test data on the RK3588 side:

# Step 1: Prepare Test Tool
# Upload the UART test program to the device (if transferring from Windows)
adb push C:\Users\Administrator\Desktop\uart ./

# Step 2: Grant Permissions
chmod 777 ./uart

# Step 3: Execute Test
# Send data
./uart /dev/ttyS0
# Enter test text (as shown in the figure below)

Image Added      

3.Observe UART Assist on the PC side (as shown in the figure below). If the received test data is displayed, the unidirectional transceiver function is normal.

Image Added

3. USB Interface Test 

1.Device Connection Status Identification 
Use the following commands to confirm whether the device is connected to the system and obtain device node information:

# View all block devices and identify the USB device node (e.g. /dev/sda1)
lsblk
# View detailed USB device information, including controller and device ID
lsusb

Result Description: In the output of lsusb, ID 1d6b:0002 stands for USB 2.0 controller, and ID 1d6b:0003 stands for USB 3.0 controller. The corresponding USB version can be judged by the bus where the device is mounted.

2.USB Version Compatibility Test
 Accurately confirm USB version via device speed parameters. USB2.0 corresponds to High-Speed (480Mbps), USB3.0 corresponds to Super-Speed (5000Mbps). Operations are as follows:

1.Check 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.Verify through detailed information

# View detailed parameters of specified USB device, filter Speed field
lsusb -v | grep -E "Speed|Device"

 Result description: In the output, Speed: 480Mbit/s corresponds to USB2.0, and Speed: 5000Mbit/s corresponds to USB3.0.

3. Transmission Performance Test

 Transmission speed is the core difference between USB2.0 and USB3.0. The theoretical speed of USB2.0 is 480Mbps, while that of USB3.0 is 5Gbps. Two commonly used test methods are provided below, applicable to USB storage devices and network USB devices respectively.

1. Simple Test: dd Command

 The dd command can quickly test read and write speeds for preliminary verification. Mount the USB device first before testing.
 1.1 Mount the USB device:

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

 1.2 Test sequential write speed:

# Write 1GB 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 the read speed
dd if=/mnt/usb/testfile of=/dev/null bs=1M iflag=direct

 1.4.Clean up temporary files after testing：

rm /mnt/usb/testfile

Result Description: After the command is executed, the transfer time and speed will be displayed.

• The actual write speed of USB 2.0 is usually 10 - 30 MB/s.
• The actual write speed of USB 3.0 is usually 50 - 150 MB/s (affected by the performance of the device itself).

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.Code block for 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

# Mixed random read/write test (default read/write ratio 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

4. Type-C Interface Test

1. ADB Function Test

1.1 Basic ADB Connection Test

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

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

Expected Results:

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

1.2 Core ADB Command Execution Test

Test Purpose: Verify that core ADB commands work properly over the Type-C link.
Test Steps:

1. File transmission:
    Run adb push test_file /data/ to send files to the device.
    Run adb pull /data/test_file ./ to download files to PC.
2. Device control:
    Run adb reboot to restart the device, then execute adb devices again after reboot.
3. Log capture:
    Run adb logcat -d > adb_log.txt to capture system logs.

Expected Results:

1. File transmission completes successfully, and the downloaded file has the same size as the original.
2. ADB connection recovers automatically after reboot.
3. The log file is not empty and contains valid running logs.

1.3 Type-C Plug & Play and Stability Test

Test Purpose: Verify the stability of ADB connection during Type-C cable plugging, unplugging and shaking.
Test Steps:

1. Single plug operation: Plug and unplug the data cable 10 times, and run adb devices after each operation.
2. Continuous plug operation: Rapidly plug and unplug 20 times with an interval of 1–2 seconds.
3. Shake test: Keep the cable connected and shake it gently, then observe the connection status.

Expected Results:

1. The device is recognized normally after each operation with no offline status.
2. ADB connection remains stable during shaking with no I/O errors.

1.4 High-load Stability Test for Type-C Connection

Test Purpose: Verify the stability of Type-C ADB function under high load.
Test Steps:

1. Large file transmission: Push a 1GB file to the device while running adb logcat.
2. Concurrent commands: Run adb push, adb shell top and adb logcat simultaneously.
3. Long-duration connection: Maintain ADB connection for 24 hours and run adb devices every hour.

Expected Results:

1. ADB connection stays active during large file transmission, and log capture works normally.
2. No crash or timeout occurs when running multiple commands; CPU usage ≤ 80%.
3. The connection status remains device within 24 hours with no disconnection.

2. Type-C to USB Hub Test

2.1 Device Recognition and Compatibility Test

Prerequisites:

1. The development board is powered on and the system boots up completely.
2. The Type-C to USB Hub is connected properly.

Operation Steps:

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

Expected Results:

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

2.2 Data Transfer Speed Test

Prerequisites:

1. Same as Section 2.1
2. Prepare a 1GB test file named test.img

Operation Steps:

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

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

3.Record the transmission time and calculate the speed: Speed = 1024MB / Time (seconds)

4.Copy files back to the development board in reverse direction and repeat the test 3 times.

Expected Results:

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

2.3 Power Supply Capability Test

Prerequisites:

1. Same as Section 2.1
2. Prepare a 2.5-inch portable hard drive (requiring power supply of 5V/0.5A or above)

Operation Steps:

1. Connect the portable hard drive to the USB port of the Hub.
2. Check if the hard drive indicator light is on, and run lsblk to view the device node.
3. Perform large file read and write operations continuously for 10 minutes.
4. Check system logs for warnings about insufficient power or device disconnection.

Expected Results:

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

2.4 Abnormal Scenario Test

1. Hot-plug 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 and check if USB devices work normally.
3. Multi-device concurrency test: Connect 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 and the system boots up completely.
2. The Type-C to HDMI/DP adapter is connected properly and the monitor is powered on.

Operation Steps:

1. Plug 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 screen and check for screen distortion, black screen or flickering.

Expected Results:

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

3.2 Audio and Video Synchronization Test

Prerequisites:

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

Operation Steps:

1. Play a 1080P test video with audio tracks.
2. Observe video fluency and listen to sound from the monitor speaker.
3. Check audio-video synchronization and verify for noise or audio interruption.

Expected Results:

1. The video plays smoothly with stable frame rate (≥30fps).
2. Audio and video are synchronized without lag or stutter.
3. Sound is clear with no noise, interruption or popping sound.

3.3 Hot-plug Test

Prerequisites:
 Same as Section 3.1
Operation 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. Reconnect the HDMI/DP end and observe system response.
4. Repeat hot plugging 10 times and record each result.

Expected Results:

1. After unplugging HDMI/DP, the system automatically switches back to the onboard display or goes black (in line with design requirements).
2. The monitor restores display automatically after reconnection 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-time playback test: Play videos continuously for 24 hours to verify stability.
3. Low-resolution output test: Set resolution to 480P to verify downward compatibility.

III. Display and Video Interface Test

1. HDMI/DP Output Test

1. Specification Description:

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

1.Query display interfaces and resolution list

# Graphical Interface (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 debugging mode is enabled on the device)
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: Check 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. HDMI Input Test

1. Test Preparation

1. Hardware Connection: Connect a valid HDMI signal source (such as a laptop, HDMI camera, set-top box, etc.) to the HDMI IN interface of the development board using a standard HDMI cable.
2. Signal Source Configuration: Ensure the HDMI signal source is powered on, and the output resolution/frame rate is compatible with the development board's HDMI IN interface (1920×1080@60Hz is recommended to avoid recognition failure caused by non-standard resolutions).
3. System Login: Log in to the development board system via SSH / Serial Port / Local Terminal. It is recommended to operate with a user with graphics display permissions (e.g., blueberry).

2. HDMI Input Device Node Query and Verification

1. View the system video device list

# Switch to the user with graphical display permissions (to avoid device access failure due to insufficient permissions)
su - blueberry

# List all video-related devices under the /dev directory and confirm the device node corresponding to HDMI IN
ls -la /dev/video*

Query Results:

-rw-rw----  1 root video     4 Dec  2 02:18 /dev/video-dec0
-rw-rw----  1 root video     4 Dec  2 02:18 /dev/video-enc0
crw-rw----+ 1 root video 81, 0 Dec  2 02:18 /dev/video0

2.Query device details

# Execute command:
cat /sys/class/video4linux/video0/name
# Output result: stream_hdmirx
# Description: stream_hdmirx indicates this is a video stream HDMI receiving device (hdmirx = HDMI Receiver)

Result Analysis：

3.Query device driver information：

readlink -f /sys/class/video4linux/video0/device/driver

Output: /sys/bus/platform/drivers/rk_hdmirx
Description: The device uses the official Rockchip rk_hdmirx driver, which is the core driver for HDMI input function on Rockchip platforms. The driver is loaded normally.

3. HDMI Input Video Stream Playback Test

1.Execute video playback command:

# Switch to the user with graphical display permissions
su - blueberry

# Configure display environment variable (specify main screen output), play HDMI input video stream via GStreamer
gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! autovideosink

2. Execution Result Verification

Setting pipeline to PAUSED ...       # Pipeline status: Pausing
Using mplane plugin for capture      # Capture plugin: Using mplane (multi-planar) mode
Pipeline is live and does not need PREROLL ...  # Pipeline status: Active, no preroll required
Pipeline is PREROLLED ...            # Pipeline status: Preroll completed (data ready)
Setting pipeline to PLAYING ...      # Pipeline status: Playing
New clock: GstSystemClock            # Clock initialization: Synchronized with system clock

Output Interpretation

Each log line corresponds to the startup status of the GStreamer pipeline. The absence of error messages indicates:

• The video capture plugin (mplane) is loaded successfully.
• The pipeline completes initialization, activation and preroll, and video stream transmission works properly.
• The clock synchronization component (GstSystemClock) runs normally and provides time reference for the video stream.

Display Performance

A playback window pops up on the monitor connected to the development board, showing real-time images from the HDMI signal source (such as laptop desktop or camera view). The test is passed if there is no screen distortion, stuttering or black screen.

Image Added

4.Troubleshooting Guide

3. Video Hard Decoding Performance Test

1. Test Environment (MPP Video Hard Decoding Device)

Based on the hard decoding tool information of the 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) to clarify the hardware mapping 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

1.Audio Output Function Verification

# Step 1: Connect to the device via ADB (Ensure USB debugging is enabled)
adb shell

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

# Step 3: List audio output devices (Verify corresponding card numbers)
aplay -l

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

# Step 5: Onboard audio (headphone) output test
aplay -D plughw:4,0 /test.wav
# Expected result: Audio plays through the 3.5mm headphone jack

# Step 6: Hardware function verification (Sine wave test to exclude file issues)
speaker-test -D hw:4,0 -t sine -f 1000 -c 2 -l 2
# Expected result: 1000Hz dual-channel sine tone is output 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 3: rockchiphdmiin [rockchip,hdmiin], device 0: rockchip,hdmiin i2s-hifi-0 [rockchip,hdmiin i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 4: rockchipes8388 [rockchip-es8388], device 0: dailink-multicodecs ES8323.3-0010-0 [dailink-multicodecs ES8323.3-0010-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

3.Result Analysis

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

# Function: Real-time audio input capture (hw:4,0) and playback to audio output (hw:0,0)
# Parameter Description:
# - arecord (capture side):
#   -D hw:4,0: Specify audio input device (adjust based on actual 'arecord -l' output)
#   -r 48000: Sample rate 48000Hz (compatible with most audio devices)
#   -c 2: Stereo capture (change to -c 1 for mono microphone)
#   -f s16_le: 16-bit little-endian format (universal compatible format)
#   -t raw: Transmit in raw format (avoid file encoding overhead)
# - aplay (playback side):
#   -D hw:0,0: Specify audio output device (e.g. HDMI/onboard speaker)
#   - Other parameters match arecord (ensure format consistency)
# - &: Run in background (prevent terminal blocking)

arecord -D hw:4,0 -r 48000 -c 2 -f s16_le -t raw | aplay -D hw:0,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 Device or resource busy appears: Run killall arecord aplay to release occupied audio devices, then retry the test.
• No sound output: Verify the device number of the -D parameter via arecord -l and aplay -l.
• Excessive noise: Change -c 2 to -c 1 for mono mode, or set the sample rate to 44100.
• System audio input configuration: Open system sound settings and go to the Input Devices tab. Select Internal Microphone from the Port drop-down list of the target device to enable the audio input channel properly.

Image Added

VI. Storage Interface Test

1.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

4. Judgment Criteria

• Device detection: The SSD is displayed via lsblk → Detection succeeded.
• Interface protocol: fdisk -l shows PCIe 3.0 x4 → Interface matches.
• Performance requirement: Read speed ≥ 1000MB/s (typical value for PCIe 3.0 SSD) → Performance normal.

2. SATA Interface Test

2.1 Hardware Connection Description

Connect the hard drive via standard 7-pin SATA 3.0 interface. The SATA power supply supports 5V 2A output.

2.2 Hard Drive Detection & Health Check

# View hard drive information and SMART status
fdisk -l

# Update software sources (optional, to avoid installation failure)
apt update
# Elevate privileges if permission denied (skip if already root)
# sudo apt update

# Install smartmontools
apt install -y smartmontools

# Note: /dev/sda is the actual SATA device node, adjust according to system output
smartctl -a /dev/sda

Test Result Verification

1. Device detection: fdisk -l shall display the capacity and partition information of the SATA hard drive.
2. SMART health status: The item SMART overall-health self-assessment test result in smartctl -a output shall show PASSED.

VII. Wireless Communication Module Test

1. Wi‑Fi Test

1. Hardware Specification Compliance

WiFi Model: AP6275P. It supports Wi-Fi 6 (IEEE 802.11a/b/g/n/ac/ax MIMO) with 2T2R (2 Transmit, 2 Receive).
 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 网络