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

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);

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

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)

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.

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.

4.Troubleshooting Guide