2.2. X5 EVB V2P0 Development Board User Guide
2.2.1. Functional Overview
2.2.1.1. Specifications
The X5 EVB development board serves as a reference platform for the X5 chip, providing various peripheral interfaces such as Ethernet, USB, Camera, LCD, HDMI, and 40PIN. Combined with peripheral accessories like cameras, audio boards, and LCD screens, users can conveniently evaluate and develop image, multimedia, and algorithm applications.
Basic specifications of the development board are as follows:
| Module | Parameters |
|---|---|
| Processor | Sunrise 5 (X5) chip |
| CPU | 8-core ARM® Cortex® A55@1.5GHz |
| BPU | Bayers-architecture BPU@1.0GHz, 10 TOPS |
| Memory | 2GB/4GB LPDDR4, 8GB/16GB eMMC |
| Camera | 1 x 4-lane MIPI CSI interface (can be split into 2 x 2-lane MIPI CSI interfaces via expansion board) 2 x 2-lane MIPI CSI interfaces |
| Display | 1 x HDMI 4K@30fps, 1 x MIPI DSI 2K@30fps |
| USB | 1 x USB Type-A 3.0 interface, 1 x Micro USB 2.0 interface |
| Wired Network | 1 x Gigabit Ethernet interface |
| Wireless Network | 2.4G / 5G Wi-Fi x1, supports 802.11 b/g/n, Bluetooth 5.1 |
| Other Interfaces | TF card interface x1, 40 PIN interface x1, ADC x5, I2S0&PDM x1 |
| Power Supply | DC 12V adapter power input interface |
2.2.1.2. X5 EVB Accessories Description
Before using the X5 EVB development board, users should prepare the following accessories:
Required Accessories
12V power adapter x1, with at least 2A power capability
Gigabit Ethernet cable x1, for network communication
Micro USB 2.0 data cable x2, used separately for serial port and USB communication
Camera module, for video and image function evaluation
Optional Accessories
Monitor and HDMI Type-A cable, for video preview
MIPI LCD display and 24PIN FPC, for display function testing
Audio sub-board, for voice function testing
2.2.2. Functional Module Layout
| Interface | Function | Interface | Function |
|---|---|---|---|
| 1 | 12V DC power adapter interface | 14 | JTAG debugging interface |
| 2 | HDMI Type-A interface, supports up to 4K@30 output | 15 | Wi-Fi 6 & Bluetooth 5.4 module FCS960KAAMD |
| 3 | USB 3.0 Type-A interface | 16 | IPEX Antenna (Bluetooth antenna interface) |
| 4 | Gigabit Ethernet interface | 17 | Wi-Fi SMD Antenna, 2400–2500 MHz; 5150–7125 MHz |
| 5 | Micro USB 2.0 data interface | 18 | Low-power HDMI 1.4 transmitter, LT8618SXB |
| 6 | Reset function button | 19 | Micro USB 2.0 debug serial port |
| 7 | Wake-up function button | 20 | 4-lane MIPI CSI interface (can be split into 2 x 2-lane MIPI CSI interfaces via expansion board) |
| 8 | RTC external power supply interface | 21 | 2-lane MIPI CSI interface |
| 9 | Boot configuration DIP switch, for selecting boot mode | 22 | 2-lane MIPI CSI interface |
| 10 | USB 3.0 host/device mode switching interface | 23 | Power switch |
| 11 | ADC[3-7] functional pins | 24 | 40PIN functional pins, supporting UART, I2C, SPI, PWM, I2S |
| 12 | 4-lane MIPI DSI interface | 25 | Independent I2C interface, can be used to expand MIPI CSI interface |
| 13 | I2S&PDM audio interface | 26 | TF card interface |
2.2.2.1. Dimension Diagram
2.2.3. Interface Usage Instructions
2.2.3.1. Powering On the Development Board
Please follow the steps below to set up and power on the development board.
Before powering on, ensure the boot configuration DIP switch (Interface 9) is set to D0/D5: ON, D1/D2/D4/D11: OFF, indicating boot from
eMMC, serial port baud rate115200, and eMMC latching data on the clock rising edge, as shown in the figure below:
Connect the 12V power adapter (Interface 1), turn on the power switch (Interface 23), and the red indicator light will illuminate, indicating normal power supply to the board.
Note: If the power indicator is on but no output appears on the debug serial port, please verify the DIP switch settings.
2.2.3.2. DIP Switch
The DIP switch (Interface 9) determines the boot mode configuration and debug serial port baud rate of the development board, allowing users to configure different operating modes.
The internal structure and physical appearance of the DIP switch are shown in the figure below. When set to ON, it indicates a high-level signal 1.
D5, D2, D1, D0correspond to the2NDBOOT_SELpin of the X5 chip, used to determine the board’s boot mode.D4corresponds to theUART_BPSpin of the X5 chip, used to set the debug serial port baud rate.D11corresponds to theEMMC_CLK_LATCHpin of the X5 chip, used to select the clock edge for eMMC data sampling.
The corresponding DIP switch truth table is as follows:
| 2NDBOOT_SEL | Value | Option | Boot Mode Description |
|---|---|---|---|
| D5, D2, D1, D0 | 1000 | 2NDBOOT UART | Boot from UART interface |
| 1001 | 2NDBOOT eMMC | Boot from eMMC storage device | |
| 0010 | 2NDBOOT USB2.0 DFU | Boot from USB2.0 DFU (Device Firmware Upgrade) interface, via Dp/Dm | |
| 1011 | 2NDBOOT SD Card | Boot from SD card | |
| 1100 | 2NDBOOT QSPI NOR Flash | Boot from QSPI NOR Flash storage device | |
| 1101 | 2NDBOOT QSPI NAND Flash | Boot from QSPI NAND Flash storage device | |
| 0110 | 2NDBOOT USB3.0 DFU | Boot from USB3.0 DFU (Device Firmware Upgrade) interface, via Dp/Dm | |
| 1111 | 2NDBOOT QSPI NAND Flash (disable mmu) | Boot from QSPI NAND Flash storage device with MMU disabled during boot |
Note: X5 burning only supports the USB 2.0 protocol. Regardless of whether the USB 2.0 or USB 3.0 interface is used, it is burned according to the USB 2.0 protocol, and the maximum speed is 480Mbps.
Note: To boot the board from USB DFU, D5 must be configured to low level (0).
| UART_BPS | Value | Option | Description |
|---|---|---|---|
| D4 | 0 | 115200bps | Debug serial port baud rate set to 115200bps at boot |
| 1 | 921600bps | Debug serial port baud rate set to 921600bps at boot |
| EMMC_CLK_LATCH | Value | Option | Description |
|---|---|---|---|
| D11 | 0 | eMMC clk falling latch data | Sample data on clock falling edge |
| 1 | eMMC clk rising latch data | Sample data on clock rising edge |
2.2.3.3. Debug Serial Port
The development board provides one debug serial port, corresponding to Interface 19. The board uses a CH340N USB-to-serial chip to convert the serial signal to a USB interface. Users can connect a Micro USB data cable to enable serial communication between the PC and the development board.
2.2.3.4. Ethernet
The development board provides one RJ45 network interface, corresponding to Interface 4, supporting 1000BASE-T, 100BASE-T, and 10BASE-T standards. The default ip address of the board is 192.168.1.10. To check the IP address, log in via the serial port and execute the ifconfig command to view information for the eth0 interface.
root@buildroot:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.10 netmask 255.255.255.0 broadcast 0.0.0.0
ether 9a:77:34:d1:fc:ed txqueuelen 1000 (Ethernet)
RX packets 1813 bytes 134485 (131.3 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 4563 bytes 282810 (276.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 38
2.2.3.5. USB 3.0 Interface
The development board provides one USB 3.0 Type-A interface, corresponding to Interface 3, which defaults to Host mode. Users can switch to Device mode as described below.
Enable USB 3.0 Device Mode
USB 3.0 can be set to Device mode via software or hardware methods.
Hardware Method
Shorting the pins on Interface 10 automatically switches USB 3.0 to Device mode. Disconnecting the short reverts it to Host mode.
Software Method
Use system configuration commands to force a switch between USB 3.0 host and device modes.
Command to set USB 3.0 to Device mode:
echo device > /sys/class/usb_role/35100000.usb-role-switch/role
Command to set USB 3.0 to Host mode:
echo host > /sys/class/usb_role/35100000.usb-role-switch/role
2.2.3.6. USB 2.0 Interface
The development board provides one Micro USB 2.0 interface, corresponding to Interface 5, supporting OTG functionality.
Main applications of this interface include:
Functional debugging, defaulting to adb mode, with support for switching to rndis, uvc, etc.
Image flashing, supporting dfu, fastboot, and other flashing modes
Peripheral connection, enabling various USB peripherals via an OTG cable
2.2.3.7. Camera (MIPI CSI) Interface
The development board provides 3 MIPI CSI interfaces, corresponding to Interfaces 20, 21, and 22.
Capabilities and configurations of the three interfaces are listed in the table below:
| Interface | MIPI CSI Host | Max Supported Lanes | I2C Bus | Reset GPIO |
|---|---|---|---|---|
| 20 | MIPI_CSI0&1 | 4 lanes | I2C4 | AON_GPIO_PIN0 - 498 |
| 21 | MIPI_CSI2 | 2 lanes | I2C2 | AON_GPIO_PIN4 - 502 |
| 22 | MIPI_CSI3 | 2 lanes | I2C7 | LSIO_GPIO1_06 - 353 |
Note: Interface 20’s MIPI CSI0&1 can be split into two 2-lane MIPI CSI interfaces (MIPI CSI0 and MIPI CSI1) using an external expansion board.
Currently supported camera modules include SC230AI, SC132gs, IMX415, and others, enabling users to test various imaging scenarios. For the complete list of supported Camera Sensors, please refer to Camera Sensor Support List.
Camera modules are connected to the board’s camera interface via a 24PIN flex cable. Pay attention to the orientation when connecting, as shown in the figure below:
The number of MIPI lanes used by the camera module is the sole factor determining interface selection. Examples:
The
SC132gsmodule uses 2 lanes, so it can be connected to any of Interfaces 20, 21, or 22.The
IMX415module uses 4 lanes, so it can only be connected to a 4-lane interface, i.e., Interface 20.
After installation, use commands to verify if the module’s I2C address is detected. If not detected, check the FPC connection for poor contact or incorrect orientation.
Check I2C address of Camera Sensor on Interface 20:
echo 498 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio498/direction
echo 0 > /sys/class/gpio/gpio498/value
sleep 0.1
echo 1 > /sys/class/gpio/gpio498/value
echo 24000000 > /sys/class/vps/mipi_host0/param/snrclk_freq
echo 1 > /sys/class/vps/mipi_host0/param/snrclk_en
i2cdetect -y -r 4
Check I2C address of Camera Sensor on Interface 21:
echo 502 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio502/direction
echo 0 > /sys/class/gpio/gpio502/value
sleep 0.1
echo 1 > /sys/class/gpio/gpio502/value
echo 24000000 > /sys/class/vps/mipi_host2/param/snrclk_freq
echo 1 > /sys/class/vps/mipi_host2/param/snrclk_en
i2cdetect -y -r 2
Check I2C address of Camera Sensor on Interface 22:
echo 353 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio353/direction
echo 0 > /sys/class/gpio/gpio353/value
sleep 0.1
echo 1 > /sys/class/gpio/gpio353/value
echo 24000000 > /sys/class/vps/mipi_host3/param/snrclk_freq
echo 1 > /sys/class/vps/mipi_host3/param/snrclk_en
i2cdetect -y -r 7
When the Camera Sensor’s I2C address is successfully detected, you will see output similar to the following (example: detecting SC230AI on Interface 22, where address 30 is detected):
root@buildroot:~$ i2cdetect -y -r 7
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
For more information on using Camera Sensors, please refer to Example Code Introduction.
2.2.3.8. HDMI Interface
The development board supports one HDMI Type-A interface, corresponding to Interface 2, with maximum output resolution of 3840x2160@30fps.
Since the system does not support a graphical interface, the HDMI interface is primarily used for real-time preview of camera and network stream images. For specific usage methods, please refer to display-related examples in Example Code Introduction.
2.2.3.9. LCD (MIPI DSI) and TP Interface
The development board supports MIPI DSI and touchscreen interfaces, corresponding to Interface 12, requiring connection to a compatible display, as shown in the figure below:
After successfully entering the Linux system, load the drivers using the following commands:
modprobe panel-jc-050hd134
modprobe vio_n2d
modprobe lontium_lt8618
modprobe vs-x5-syscon-bridge
modprobe vs_drm
The serial port will output:
[ 3343.383052] vs-disp-sif 3e080000.vs-sif: Adding to iommu group 3
[ 3343.384118] vs-dc 3e000000.dc8000Nano: Adding to iommu group 4
[ 3343.385252] vs-bt1120 3e010000.bt1120: Adding to iommu group 5
[ 3343.387555] horizon-lsio-pinctrl 34180000.lsio_iomuxc: set pin = 14 direction to input
[ 3343.387567] horizon-lsio-pinctrl 34180000.lsio_iomuxc: map pin14 to gpio[0] - 14
[ 3343.387635] panel-jc-050hd134 3e060000.mipi_dsi0.0: supply power not found, using dummy regulator
[ 3343.391241] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e080000.vs-sif (ops sif_component_ops [vs_drm])
[ 3343.391529] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e000000.dc8000Nano (ops dc_component_ops [vs_drm])
[ 3343.391692] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e010000.bt1120 (ops bt1120_component_ops [vs_drm])
[ 3343.391730] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e000000.disp_apb:bt1120_bridge (ops bt1120_bridge_component_ops [vs_drm])
[ 3343.391764] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e000000.disp_apb:bt1120_bridge_wb (ops bt1120_bridge_component_ops [vs_drm])
[ 3343.391816] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e060000.mipi_dsi0 (ops dsi_component_ops [vs_drm])
[ 3343.391917] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e000000.disp_apb:dsi-encoder (ops encoder_component_ops [vs_drm])
[ 3343.391976] vs-drm 3e000000.disp_apb:display-subsystem: bound 3e000000.disp_apb:hdmi-encoder (ops encoder_component_ops [vs_drm])
[ 3343.392815] [drm] Initialized vs-drm 1.0.0 20191101 for 3e000000.disp_apb:display-subsystem on minor 0
play-subsystem on minor 0
When [drm] Initialized vs-drm 1.0.0 20191101 for 3e000000.disp_apb:display-subsystem on minor 0 appears, the display driver has loaded successfully.
Test using the command: modetest -M vs-drm -a -s 73@31:720x1280 -P 33@31:720x1280@NV12.
The connected screen will light up, displaying a pattern as shown in the figure below:
Before using the TouchScreen, load the corresponding driver (e.g., gt9xx.ko). For detailed driver development, please refer to the touchscreen user manual and Driver Development Guide.
Example of driver loading:
root@buildroot:~$ modprobe gt9xx_core
[ 31.725453] Gt9xx driver installing..
[ 31.725836] goodix-ts 4-0014: GTP Driver Version: V2.8.1<2022/07/25>
[ 31.725846] goodix-ts 4-0014: GTP I2C Address: 0x14
[ 31.725858] goodix-ts 4-0014: Unset touchscreen-max-id, use default
[ 31.725867] goodix-ts 4-0014: Unset touchscreen-max-w, use default
[ 31.725872] goodix-ts 4-0014: Unset touchscreen-max-p, use default
[ 31.725879] goodix-ts 4-0014: touch input parameters is [id x y w p]<16 720 1280 1024 1024>
[ 31.725892] goodix-ts 4-0014: int-sync enabled
[ 31.725897] goodix-ts 4-0014: driver-send-cfg enabled
[ 31.725954] goodix-ts 4-0014: Looking up vdd_ana-supply from device tree
[ 31.725963] goodix-ts 4-0014: Looking up vdd_ana-supply property in node /soc/a55_apb0/i2c@340f0000/gt9xx@14 failed
[ 31.725994] goodix-ts 4-0014: supply vdd_ana not found, using dummy regulator
[ 31.733294] goodix-ts 4-0014: Looking up vcc_i2c-supply from device tree
[ 31.733304] goodix-ts 4-0014: Looking up vcc_i2c-supply property in node /soc/a55_apb0/i2c@340f0000/gt9xx@14 failed
[ 31.733353] goodix-ts 4-0014: supply vcc_i2c not found, using dummy regulator
[ 31.740584] goodix-ts 4-0014: Success request irq-gpio
[ 31.740606] goodix-ts 4-0014: Success request rst-gpio
[ 31.740615] goodix-ts 4-0014: Guitar reset
[ 31.770464] do irq down
[ 31.833945] goodix-ts 4-0014: I2C Addr is 14
[ 31.834979] goodix-ts 4-0014: IC Version: 911_1060
[ 31.837180] goodix-ts 4-0014: Config group0 used,length: 186
[ 31.839372] goodix-ts 4-0014: Driver send config
[ 31.872342] goodix-ts 4-0014: Use slot report protocol
[ 31.872888] input: goodix-ts as /devices/virtual/input/input1
[ 31.873593] goodix-ts 4-0014: INT num 77, trigger type:2
[ 31.873991] goodix-ts 4-0014: create proc entry gt9xx_config success
[ 31.874016] goodix-ts 4-0014: Alloc memory size:3070.
[ 31.874023] goodix-ts 4-0014: I2C function: without pre and end cmd!
[ 31.874032] goodix-ts 4-0014: Create proc entry success!
After successful driver loading, a device node /dev/input/event1 will be created for user-space programs.
Testing Usage:
Use the tc_test program to test touchscreen functionality. When touching the screen, events, types, status codes, and coordinates will be captured.
# ./tc_test /dev/input/event1
Monitoring input events on /dev/input/event1
[/dev/input/event1] event(0): type:3; code: 47; value: 0; realx: 0; realy: 0
[/dev/input/event1] event(1): type:3; code: 57; value: 16; realx: 0; realy: 0
[/dev/input/event1] event(2): type:3; code: 53; value:248; realx:248; realy: 0
[/dev/input/event1] event(3): type:3; code: 54; value:1007; realx:248; realy:1007
[/dev/input/event1] event(4): type:3; code: 48; value: 13; realx:248; realy:1007
[/dev/input/event1] event(5): type:3; code: 58; value: 13; realx:248; realy:1007
Test Code:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <linux/input.h>
static int handle_event(int fd, const char *device_name)
{
struct input_event ev[64];
int button = 0, realx = 0, realy = 0, i, rd;
rd = read(fd, ev, sizeof(struct input_event) * 64);
if (rd < (int)sizeof(struct input_event)) return 0;
for (i = 0; i < rd / (int)sizeof(struct input_event); i++)
{
if (EV_ABS == ev[i].type)
{
if (ev[i].code == 53) {
realx = ev[i].value;
} else if (ev[i].code == 54) {
realy = ev[i].value;
}
}
printf("[%s] event(%d): type:%d; code:%3d; value:%3d; realx:%3d; realy:%3d\n",
device_name, i, ev[i].type, ev[i].code, ev[i].value, realx, realy);
}
return 1;
}
int main(int argc, char *argv[])
{
if (argc < 2) {
printf("Usage: %s <event device path>\n", argv[0]);
return -1;
}
const char *device_path = argv[1];
int fd = open(device_path, O_RDONLY);
if (fd < 0) {
printf("Failed to open input device: %s\n", device_path);
return -1;
}
printf("Monitoring input events on %s\n", device_path);
while (handle_event(fd, device_path));
close(fd);
return 0;
}
2.2.3.10. Independent I2C Interface
The development board supports one independent I2C interface, corresponding to Interface 25. This interface is primarily designed to work with a MIPI CSI expansion board to split the MIPI CSI0&1 interface (Interface 20) into two separate MIPI CSI0 and MIPI CSI1 interfaces. It can also serve as a standalone I2C interface for connecting peripherals.
Pinout is as follows:
| No. | Name | Attribute | Description |
|---|---|---|---|
| 1 | GND | Signal ground | Ground |
| 2 | RESET | 1.8V single-ended output | Board resets module, active low |
| 3 | I2C1_SCL | Default 3.3V single-ended signal | I2C clock line |
| 4 | I2C1_SDA | Default 3.3V single-ended signal | I2C data line |
| 5 | CSI1 Trigger | 1.8V single-ended input | Used for Camera Sensor triggering when expanding MIPI CSI1 interface |
| 6 | VDD33 | 3.3V, 200mA | Module power supply |
2.2.3.11. Wi-Fi Antenna
In terms of wireless network design, the development board supports two configuration methods: onboard antenna and external antenna. The default is the onboard antenna, and the antenna channel can be switched through GPIO control.
#Antenna control initialization
echo 489 > /sys/class/gpio/export
echo 351 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio489/direction
echo out > /sys/class/gpio/gpio351/direction
#Switch to onboard antenna
echo 1 > /sys/class/gpio/gpio489/value
echo 0 > /sys/class/gpio/gpio351/value
#Switch to external antenna
echo 0 > /sys/class/gpio/gpio489/value
echo 1 > /sys/class/gpio/gpio351/value
2.2.3.12. Wi-Fi / Bluetooth
Using Wi-Fi
The development board integrates an FCS960K 2.4G/5.0G dual-mode Wi-Fi / Bluetooth module, supporting IEEE802.11a/b/g/n/ac/ax WLAN and Bluetooth 5.1 functions. The Wi-Fi driver is automatically loaded upon system startup.
root@buildroot:~$ ifconfig wlan0
wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 40:9c:a7:70:98:cc txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Users need to manually configure the SSID and obtain an IP address by modifying configuration files, as follows:
# Enter userdata directory to avoid file write errors in system directories
cd /userdata/
# Modify the command with your Wi-Fi SSID and password ("WIFI_SSID", "WIFI_PASSWD")
wpa_passphrase "WIFI_SSID" "WIFI_PASSWD" >> ./wpa_supplicant.conf
sleep 1
wpa_supplicant -D nl80211 -i wlan0 -c ./wpa_supplicant.conf -B
sleep 1
udhcpc -i wlan0 &
After configuration, run ping 8.8.8.8 to confirm network connectivity. Normal log output is as follows:
root@buildroot:~$ cd /userdata/
root@buildroot:/userdata$ wpa_passphrase WiFi-Test 12345678 >> ./wpa_supplicant.conf
root@buildroot:/userdata$ wpa_supplicant -D nl80211 -i wlan0 -c ./wpa_supplicant.conf -B
Successfully initialized wpa_supplicant
[10093.447698] [BB][halbb_la_bb_set_smp_rate] smp_rate_tmp=7, la_smp_rate_log=160 M
root@buildroot:/userdata$ udhcpc -i wlan0 &
[1] 1309
udhcpc: started, v1.35.0
root@buildroot:/userdata$ udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.137.252, server 192.168.137.1
udhcpc: lease of 192.168.137.252 obtained from 192.168.137.1, lease time 604800
deleting routers
adding dns 192.168.137.1
[1]+ Done udhcpc -i wlan0
root@buildroot:/userdata$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.137.252 netmask 255.255.255.0 broadcast 192.168.137.255
ether 40:9c:a7:70:98:cc txqueuelen 1000 (Ethernet)
RX packets 117 bytes 15326 (14.9 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 63 bytes 5056 (4.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@buildroot:/userdata$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=52 time=82.124 ms
64 bytes from 8.8.8.8: seq=1 ttl=52 time=106.029 ms
64 bytes from 8.8.8.8: seq=2 ttl=52 time=129.993 ms
^ C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 82.124/106.048/129.993 ms
root@buildroot:/userdata$
Wi-Fi STA and AP Mode Switching
Run /etc/init.d/wifi_init.sh ap to switch to AP mode, and run /etc/init.d/wifi_init.sh sta to switch to STA mode.
root@buildroot:~# /etc/init.d/wifi_init.sh ap
Initialize wlan0 to ap mode
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
Finish initialize wlan0 to ap mode
dnsmasq: started, version 2.86 cachesize 150
root@buildroot:~# dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-cryptohash no-DNSSEC loop-detect inotify dumpfile
dnsmasq: warning: no upstream servers configured
dnsmasq-dhcp: DHCP, IP range 192.168.5.2 -- 192.168.5.254, lease time 12h
dnsmasq: read /etc/hosts - 2 addresses
root@buildroot:~# /etc/init.d/wifi_init.sh sta
Initialize wlan0 to station mode
Finish initialize wlan0 to station mode
Using Bluetooth
Run /etc/init.d/bt_init.sh to complete Bluetooth initialization.
Run bluetoothctl to enter the interactive Bluetooth configuration interface. If device information similar to the image below appears, it indicates that the Bluetooth has been recognized. Then use the show command to view Bluetooth information, paying attention to the powered and discoverable status.
Run power on to enable Bluetooth, as shown in the image below:
To make the Bluetooth discoverable by nearby devices, run discoverable on to enable the discoverable property, as shown below:
At this point, scanning for Bluetooth using a phone or computer will reveal a device named BlueZ 5.64 (the version number in the name may vary depending on the BlueZ version, for example, it could also be BlueZ 5.79):
Next, test Bluetooth’s active scanning feature. Enter scan on in the bluetoothctl interactive interface to enable active scanning. It will periodically print nearby devices. As shown, my phone has already been detected. Use scan off to stop scanning and summarize the detected Bluetooth devices:
Then proceed with pairing with other Bluetooth devices:
Pairing command: pair [targetMAC]. After entering this command, type yes when prompted, and confirm pairing on the target Bluetooth device.
After successful pairing, use trust [targetMAC] to enable automatic connection next time.
Use l2ping to test network connectivity.
2.2.3.13. TF Card
The development board supports one TF card interface (Connector 26), with maximum support for SDR104 mode. Supported file system formats include FAT32 (VFAT), EXFAT, ext2, ext3, and ext4.
After inserting a TF card, the kernel logs below indicate successful recognition:
[ 9809.931894] mmc1: new HSSDHC card at address 1234
[ 9809.933740] mmcblk1: mmc1:1234 SA16G 14.5 GiB
[ 9809.940060] mmcblk1: p1
Note: Depending on the specific model and partitioning of the TF card, actual log output may vary slightly.
If the file system format on the TF card partition is not FAT32 (VFAT), ext2, ext3, or ext4, use the following commands to format the TF card partition:
# Format as FAT32 (VFAT)
mkfs.vfat /dev/mmcblk2p1
# Format as ext4
mkfs.ext4 /dev/mmcblk2p1
# Format as ext3
mkfs.ext3 /dev/mmcblk2p1
# Format as ext2
mkfs.ext2 /dev/mmcblk2p1
2.2.3.14. 40-Pin Interface
The development board provides one 40-pin interface (Connector 24), for easy expansion of peripheral interfaces. Pin definitions and supported multiplexing functions are shown below:
All IO pins on the 40-pin interface default to the 3.3V voltage domain. The voltage domain can be switched between 3.3V and 1.8V by adjusting resistors R903 and R902.
Warning: U-Boot code must be updated accordingly when switching voltage domains. Failure to do so may result in a mismatch between software configuration and actual power supply, potentially causing chip damage.
Connection Example:
Below is a hardware reference connection diagram for an Audio Driver HAT:
2.2.3.15. RTC
The development board uses an external RTC circuit and an external battery to maintain system time after power-off. The RTC battery connector (Connector 8) is defined as follows:
Connector Type: JST_1X2P_PITCH1
| No. | Name | Description |
|---|---|---|
| 1 | VRTC | Battery positive, 3.3V |
| 2,3,4 | GND | Battery negative, ground reference |
Note: The X5 EVB V2P0 board does not have an external RTC; it only includes the RTC built into the X5 SOC. After booting, check the boot log to confirm the related messages from the X5 SOC’s internal RTC:
root@buildroot:~# dmesg | grep rtc
[ 0.571115] dw-rtc 31010000.rtc: prescaler set to: 24000000
[ 0.571451] dw-rtc 31010000.rtc: char device (253:0)
[ 0.571463] dw-rtc 31010000.rtc: registered as rtc0
[ 0.571479] dw-rtc 31010000.rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)
From the log, the RTC built into the X5 SOC is registered as rtc0. You can use the following commands to test the RTC:
# Write time to rtc0
date -s "2025/01/01 08:00:00" # Set system time
hwclock -w # Write system time to RTC
hwclock -r # Read RTC time to verify successful write
date -s "2024/01/01 17:08:00" # Set system time to a different value
hwclock -s # Update system time from RTC
date # Check if RTC synchronization was successful
If an external RTC battery is connected, after booting, run the following commands to test whether RTC time can be synchronized:
date # Check current system time after reboot
hwclock -s # Synchronize RTC time to system
date # Check current system time to verify successful RTC sync
2.2.3.16. ADC Interface
Connector 11 is the ADC (Analog-to-Digital Converter) interface on the development board. It provides five pins labeled ADC[3-7], used to connect analog signal sources and convert analog signals into digital signals for system processing. Users can read corresponding system files to obtain the converted ADC values.
Input Voltage Range: The supported input voltage range for the ADC is 0.1~1.7V. Users must ensure that the input signal voltage stays within this range to avoid signal distortion or ADC damage.
Reading ADC Values
Read the system files /sys/bus/iio/devices/iio:device0/in_voltage3_raw to /sys/bus/iio/devices/iio:device0/in_voltage7_raw to obtain raw ADC values from channels ADC[3-7]. For example, to read the value from ADC3, use the following command:
root@buildroot:~$ cat /sys/bus/iio/devices/iio:device0/in_voltage3_raw
1020
This command outputs the raw digital value converted from channel ADC3. Users can read values from ADC[3-7] by replacing in_voltage3_raw in the command with the corresponding in_voltageX_raw (where X ranges from 3 to 7).
2.2.3.17. Other Interfaces
Power Switch
Controls power-on and power-off of the board. Corresponds to Connector 23.
Reset Switch
Resets the system by pulling down the chip’s RSTN signal. Corresponds to Connector 6.
Wake-up Switch
Used to wake up the system from Sleep mode via an external wake-up source. Corresponds to Connector 7.
JTAG Debug Interface
Used with tools such as DS5 for chip debugging. Corresponds to Connector 14. The connector is not soldered by default on the development board and must be manually soldered before use.
2.2.3.18. Notes
X5 EVB V2P0 includes two versions of firmware: Secure and Non-secure. Users need to confirm the hardware type according to the chip silk screen before selecting the corresponding firmware. Firmware cannot be mixed across types. Flashing the wrong version will result in failure to start.
The difference between Secure and Non-secure
The basis for distinction lies in whether the chip has burned the key Hash (eFuse layer):
D-Robotics CFG (Secure): The D-Robotics key Hash has been burned, and customer-defined keys are not supported.
Customized CFG (Non-secure): Does not contain any key Hash, customers can burn custom Key
Secure chips must be programmed with Secure firmware, and Non-secure chips must be programmed with Non-secure firmware. The default compiled products of X5 SDK are Secure firmware.
Identifying Hardware Version via Chip Silk Screen
The 5th and 6th digits in the chip silk screen indicate the eFuse configuration type:
| Chip silk screen | Main frequency | eFuse configuration | Firmware type |
|---|---|---|---|
| X5HC00ICSTMA | 1.8 GHz | D-Robotics CFG | Secure |
| X5HC10ICSTMA | 1.8 GHz | Customized CFG | Non-secure |
| X5MC00ICSTMA | 1.5 GHz | D-Robotics CFG | Secure |
| X5MC10ICSTMA | 1.5 GHz | Customized CFG | Non-secure |
Distinguishing rules: The 5th and 6th digits are 00 → D-Robotics CFG (Secure), the 5th and 6th digits are 10 → Customized CFG (Non-secure).
For information about Non-secure firmware, refer to Non-secure firmware.