For 0.5mm pitch, use a matching FPC flat cable; insert horizontally to avoid bending pins. 2.54mm pitch is the standard Dupont connector interface, compatible with the most common breadboard jumper wires. The 1.25mm fan connector requires a matching terminal cable; Dupont cables cannot be used directly.
The 3.8mm Phoenix terminal on the K9 is convenient for industrial wiring.
Using the K7 as an example, modify kernel-6.1/arch/arm64/boot/dts/rockchip/rk3576-kickpi-k7.dtsi and change dr_mode from "otg" to "host".
In OTG (On‑The‑Go) mode, the USB port can dynamically switch between Host and Device roles based on the ID pin state. In Host mode, the port is fixed as a host, allowing you to connect USB peripherals such as flash drives, mice, and keyboards directly.
Locate the dr_mode property under the USB node in the device tree → change it to "host" → rebuild the kernel/resource tree → flash the boot or resource partition for the change to take effect — no need for a full flash.
After flashing and booting, plug in a USB device and run lsusb or dmesg | grep usb to confirm successful enumeration.
Q3: How do I control the fan based on temperature?¶
Read the CPU temperature: cat /sys/class/thermal/thermal_zone*/temp
Turn the fan on: echo 1 > /sys/class/leds/fan/brightness
Turn the fan off: echo 0 > /sys/class/leds/fan/brightness
Q4: USB‑to‑serial adapters conflict with the 4G module device numbers on AW platforms?¶
CH34X devices register as ttyUSB0 first, while the 4G module registers as ttyUSB1 through ttyUSB3. Solutions: plug in the USB‑to‑serial adapter after power‑on, or modify the device numbers in the dial‑up script.
Both USB‑to‑serial chips (CH340/CH341) and the 4G module use the USB‑to‑serial driver. The system assigns ttyUSB device numbers in the order of enumeration, which can cause previously configured device numbers to shift.
Disconnect the USB‑to‑serial adapter → power on the board fully → wait for the 4G module to register (about 30 seconds) → then plug in the USB‑to‑serial adapter. The CH34X will then be assigned the last available device number.
Alternatively, create a udev rule in /etc/udev/rules.d/ to create a fixed symlink based on the USB device's VID/PID, e.g., SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyCH340". This makes the device number independent of enumeration order.
An external CAN transceiver is required. The CAN function is not enabled on the default pins; you need to modify the device tree configuration. The K4B Lite version does not support CAN (requires soldering additional components).
The CAN pins on the board output CAN TX/RX signals (TTL level). You need an external CAN transceiver (such as SN65HVD230 or TJA1050) to convert them to CAN_H / CAN_L differential signals for connection to the CAN bus network.
Enable the CAN controller node in the device tree, e.g., &can0 { status = "okay"; pinctrl-0 = <&can0_pins>; };, and verify that the pin multiplexing (mux) configuration is correct. Typically, you need to switch the corresponding GPIO from UART or GPIO function to CAN function.
After the configuration takes effect, reboot the system and run ip link set can0 up type can bitrate 500000 to bring up the CAN interface. Use candump can0 to monitor bus traffic and cansend can0 123#DEADBEAF to send test frames.
Check whether the blue LED on the board is blinking. The fan is enabled by default after power‑on, but it only spins after the kernel has booted. If the LED does not blink, the system is not running properly.
Verify that the connection is secure. Use a multimeter to check for 5V on the fan connector. If no voltage is present, the board hardware may be faulty.
Run cat /sys/class/leds/fan/brightness. If the value is 0, the fan is in the off state.
If all the above checks are normal and the issue persists, flash the latest firmware from our cloud storage and test again. If the problem remains, the fan hardware is likely faulty.
Q7: The image from the single MIPI camera on the K8 (RK3588) is dark?¶
The default image is configured for dual MIPI cameras. With a single MIPI camera, the ISP loads incorrectly, resulting in a dark image. To use a single MIPI camera, you need to comment out the corresponding camera node in the device tree. Refer to Camera for instructions on rebuilding the SDK to generate a single‑camera image.
The K8 default device tree configures two MIPI CSI channels (csi2_dphy0 and csi2_dphy1). The ISP (Image Signal Processor) expects two inputs. With only one camera connected, the ISP's AEC/AGC algorithm processes the abnormal data from the unused channel incorrectly, resulting in underexposed images.
Edit kernel-6.1/arch/arm64/boot/dts/rockchip/rk3588-kickpi-k8.dtsi, comment out the &csi2_dphy1 node and any associated nodes like &i2c7 for the unused camera, rebuild the boot partition, and flash it.
After the modification, use v4l2-ctl --list-devices to verify that only one camera device node appears. Test the brightness and clarity with gst-launch-1.0 v4l2src device=/dev/video0 ! videoconvert ! fbdevsink.
Use i2cdetect -l to list the system's I2C buses, and i2cdetect -y <bus_num> to scan for device addresses to confirm correct hardware connections. Verify that the pull‑up resistors on the I2C device are soldered (some boards require external 4.7kΩ pull‑ups). Measure the SCL/SDA signal levels to ensure they are normal (3.3V).
Each device on an I2C bus needs a unique address. Use i2cdetect -y <bus> to see all occupied addresses on the bus. If the expected device address does not appear (shown as --), the device is not responding.
Use an oscilloscope to check the SCL and SDA signal waveforms. A healthy I2C signal should have clean rising edges with no glitches; the square wave amplitude should be close to 3.3V (low level near 0V). An excessively large pull‑up resistor can slow down the signal rise time and affect communication.
Once the device responds (shown as UU or its address by i2cdetect), you can use i2cget -y <bus> <addr> <reg> to read a specific register to verify that communication is working correctly.