目录

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

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