目录

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

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. 角色定义：

服务端（Server）：接收数据的设备；

Role Definition

 Server: Device receiving data
 Client: Device sending data
 客户端（Client）：发送数据的设备。

3. TCP 带宽测试（常用）

Bandwidth Test (Commonly Used)

 
Step 1: Start the server

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

步骤 2：客户端发起测试Step 2: Initiate the test from the client

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

扩展命令（自定义参数）

# 测试30秒，每2秒输出一次实时数据
iperf3 -c [服务端IP] -t 30 -i 2
# 测试双向带宽（服务端/客户端互传）
iperf3 -c [服务端IP] -d

4.UDP 丢包 / 延迟测试

步骤 1：启动服务端

iperf3 -s

步骤 2：客户端发起测试

# 测试UDP（指定带宽100Mbps）
iperf3 -c [服务端IP] -u -b 100M

5.结果解读（示例）

TCP 测试结果