In high-performance embedded systems, PCIe can not only be used to connect traditional peripherals such as NVMe SSDs and network cards, but also be used for high-speed communication between SoCs. When one RK3588 is used as a PCIe Root Complex and the other is configured as a PCIe Endpoint, the PCIe link can be used to establish a high-speed data channel between the two processors.

Based on OK3588-C platform, the software and hardware configuration process of RK3588 PCIe Endpoint function is arranged, and the identification, link negotiation and DMA test methods of RC and EP are described with the actual test screenshots.

1. Test Scenario and Critical Constraints

Test Topology

In this test, two RK3588 cards are directly connected: one is used as the PCIe RC end, and the other is used as the PCIe EP end. The test data version is "OK3588-C & OK3588-C21 _ Linux 5.10.209 _ User Data _ R2".

Reference Clock Limitation

When the RK3588 operates as a PCIe Endpoint, it does not support the SRNS (Separate Refclk Independent Spread) non-common-reference-clock scheme. Therefore, the Endpoint must use a common PCIe reference clock provided by the Root Complex (RC). In this test, the Endpoint uses the 100 MHz reference clock provided by the RC.

2. EP-side Software Configuration

In the RK3588 Linux 5.10.209 source code, basic support for the PCIe Endpoint function is already in place. The software-side configuration mainly involves setting up the device tree, Kernel defconfig, BAR space, and HugePage.

Device Tree: Switching to Endpoint Mode

Configure the PCIe controller node to operate in the standard Rockchip Endpoint mode and bind the reserved-memory region for BAR mapping. Key configuration example is as follows:

&pcie3x4 {
compatible = "rockchip,rk3588-pcie-std-ep";
memory-region = <&bar0_region>, <&bar2_region>;
memory-region-names = "bar0", "bar2";
reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
rockchip,ep-power-independent;
vpcie3v3-supply = <&vcc3v3_pcie30>;
status = "okay";
};

The compatible attribute determines that the controller works in PCIe Endpoint mode, and the memory-region is used to specify the reserved memory used by the BAR mapping at the EP side.

Reserve BAR Mapping Space

reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
bar0_region: bar0-region@3c000000 {
reg = <0x0 0x3c000000 0x0 0x00400000>;
};
bar2_region: bar2-region@40000000 {
reg = <0x0 0x40000000 0x0 0x04000000>;
};
};

• BAR0 reserves 4 MB of space.

• BAR2 reserves 64 MB of space.

  These spaces are used for address mapping and subsequent DMA data access between RC and EP. The actual product should be adjusted according to the data window, DMA buffer and memory planning of the application.

Kernel Defconfig Configuration

CONFIG_PCIE_DW_ROCKCHIP_EP=y
CONFIG_HUGETLBFS=y
CONFIG_PCIE_FUNC_RKEP=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_HUGETLB_PAGE=y

Among them, CONFIG_PCIE_DW_ROCKCHIP_EP is used to enable Rockchip DesignWare PCIe Endpoint controller support; CONFIG_PCIE_FUNC_RKEP is used to enable the Rockchip PCIe EP function. The HugeTLB related options are used for subsequent large contiguous memory and DMA testing.

BAR Parameter Configuration

The test plan also requires adjusting the Resizable BAR related configurations in the Rockchip PCIe EP driver based on the layout of BAR0, BAR2, and BAR4. The corresponding source code is located at:

drivers/pci/controller/dwc/pcie-dw-ep-rockchip.c

In the original test plan, the configurations related to BAR0, BAR2, and BAR4 were updated to match the parameters of the test space. Special attention is required: When the BAR space size changes, the related configurations in the Linux kernel, device tree, and U-Boot must remain consistent.

HugePage Configuration

To facilitate PCIe large-block data transfer testing, this plan uses the HugePage method recommended by Rockchip to prepare contiguous memory. Add the following to the bootargs:

default_hugepagesz=32M hugepagesz=32M hugepages=16

This means the default HugePage size is 32 MB, with a total of 16 HugePages reserved. This configuration primarily serves the test Demo and DMA data buffering. For mass production projects, it should be re-planned according to the actual memory capacity and application requirements.

3. EP-side Hardware Clock Modification

The PCIe high-speed link has high requirements for reference clock stability and topology. Since the RK3588 EP does not support the non-common-reference-clock scheme, this test configures the EP to directly use the 100 MHz PCIe reference clock output from the RC, while simultaneously disconnecting the original reference clock path on the EP board.

Figure 1 Schematic Diagram Related to the PCIe Reference Clock (Original Test Data Screenshot)

Figure 2 Hardware Modification Location for the EP Board Reference Clock (Photo of Original Test Data)

4. RC-side Software Configuration

The RC side still operates in PCIe Host mode, but it needs to enable the Rockchip RKEP function and HugePage support to recognize the EP device and complete subsequent testing.

Enable the RKEP Function

CONFIG_PCIE_FUNC_RKEP=y

Enable the HugeTLBFS

CONFIG_HUGETLBFS=y

Configure HugePage

default_hugepagesz=32M hugepagesz=32M hugepages=16

At this point, the basic software configuration for both the RC and EP sides is complete, allowing entry into the hardware connection and functional testing phase.

5. Hardware Connection and Power-up

The PCIe Endpoint does not support hot-plug. During testing, the PCIe connection between the RC and EP should be established first, followed by powering on the system, to avoid plugging or unplugging the EP link while the device is already running.

Figure 3 Diagram of the Connection Relationship between RC and EP Boards (Original Test Data Screenshot)

Figure 4 Actual Connection Status of RC/EP (Original Test Data Photo)

6. RC-side Functional Verification

Checking RKEP Driver and Device Identification

dmesg | grep rkep

When both software and hardware configurations are correct, you should see logs indicating successful MSI interrupt requests, VID/DID information, and RKEP object details.

pcie-rkep 0000:01:00.0: success to request msi irq
pcie-rkep 0000:01:00.0: vid=1d87
pcie-rkep 0000:01:00.0: did=356a
pcie-rkep 0000:01:00.0: obj_info magic=524b4550, ver=100

Check device nodes

ls /dev/pcie-rkep-0000\:01\:00.0

View the link rate and number of channel

cat /sys/bus/pci/devices/0000\:01\:00.0/current_link_speed
cat /sys/bus/pci/devices/0000\:01\:00.0/current_link_width

In this test, the link negotiation result is 8.0 GT/s with a Link Width of 4, establishing a PCIe Gen3 ×4 link.

Figure 5: RC-side RKEP Identification, Device Node, and PCIe Gen3 ×4 Link Verification (Original Test Data Screenshot)

7. EP-side Status Verification

After the EP side boots normally, you can check the Endpoint device node:

ls /dev/pcie_ep

Figure 6: EP-side /dev/pcie_ep Device Node (Original Test Data Screenshot)

Once both the RC and EP sides are correctly identified, you can proceed to further PCIe read/write and DMA performance testing.

8. Compiling and Running the Speed Test Demo

Rockchip provides test demos for the PCIe Endpoint standard card. Since the original test data was compiled in a Linux environment, you need to first copy the resource package to the development environment, extract it, and then modify the cross-compilation toolchain path in build.sh.

Rockchip_PCIE_EP_Stardard_Card_20250916/build/linux/build.sh

Figure 7: build.sh Cross-Compilation Toolchain Path Configuration (Original Test Data Screenshot)

After modifying the toolchain path, execute:

./build.sh

Figure 8: PCIe Test Demo Compilation Process (Original Test Data Screenshot)

This test uses the pcie_speed_test speed measurement demo. The compilation output and program location can be referenced in the figure below.

Figure 9: pcie_speed_test Speed Test Program (Original Test Data Screenshot)

For more detailed parameters and usage instructions, refer to the README in the resource package:

Rockchip_PCIE_EP_Stardard_Card_20250218/examples/pcie_speed_test/README.md

Figure 10: pcie_speed_test README Usage Instructions (Original Test Data Screenshot)

9. Actual Testing of EP-DMA and RC-DMA

EP-DMA Mode

EP-DMA is the default testing method, and generally no modification to the DMA selection configuration in the driver or test program is required. Run the speed test program on the RC side and EP side separately to observe the link working status and data transfer results.

Figure 11: Speed Test Output on the RC Side in EP-DMA Mode (Original Test Data Screenshot)

Figure 12: Speed Test Output on the EP Side in EP-DMA Mode (Original Test Data Screenshot)

RC-DMA Mode

To switch to RC-DMA, the original test solution only requires modifying the RC-side source file in the test application; no modifications to the PCIe driver source code are needed.

Figure 13: Modification Location for Enabling RC-DMA in the Test Application (Original Test Data Screenshot)

After modifying the application and recompiling, you can perform read/write tests in RC-DMA mode on both the RC side and EP side separately.

Figure 14: Speed Test Output on the RC Side in RC-DMA Mode (Original Test Data Screenshot)

Figure 15: Speed Test Output on the EP Side in RC-DMA Mode (Original Test Data Screenshot)

Since test throughput may be affected by various factors such as memory, DMA direction, data block size, software version, and test demo parameters, this document retains the original test output screenshots and does not treat single-test values as fixed platform performance metrics. For actual projects, it is recommended to conduct independent validation based on the target business workload.

Summary of Key Configuration Points

1. The Linux 5.10.209 source code already provides basic support for the RK3588 PCIe Endpoint, but device tree and kernel configuration adaptations are still required.

2. Configure the PCIe controller to operate in Endpoint mode by setting rockchip,rk3588-pcie-std-ep, and reserve memory for mapping spaces such as BAR0 and BAR2.

3. Enable the following kernel configurations: CONFIG_PCIE_DW_ROCKCHIP_EP, CONFIG_PCIE_FUNC_RKEP, and configurations related to HugeTLB.

4. The BAR space, HugePage settings, kernel parameters, and U-Boot parameters should be planned in a coordinated manner to avoid inconsistencies in address space or image configuration.

5. The RK3588 EP does not support SRNS (Separate Reference No Spread) non-homologous reference clocks. The EP must use the 100 MHz homologous reference clock provided by the RC.

6. PCIe EP does not support hot-plug. Ensure the RC/EP connection and clock are confirmed first, then power on the devices according to the test procedure.

7. On the RC side, verify the link status by checking dmesg, device nodes, current_link_speed, and current_link_width.

8. In this test, a PCIe Gen3 ×4 link was successfully established, and both functional verification and speed tests were completed for EP-DMA and RC-DMA modes

The configurations above are based on the specified OK3588-C Linux 5.10.209 test environment. Note that different SDK versions, board versions, and hardware designs may have variations. For official projects, it is recommended to perform verification in conjunction with the corresponding version of the source code, schematics, and Rockchip PCIe EP documentation.

Milan, Italy – October 21, 2026 — Meet Forlinx Embedded at Meliá Milano for NXP Tech Day Milan 2026.

NXP Tech Days is a global training program bringing together hands-on workshops, expert-led sessions, and real-world insights across embedded systems, connectivity, and security.

Forlinx Embedded will participate in NXP Tech Day Milan 2026. As an NXP Gold Partner, we will showcase our NXP-based solutions for applications across Edge AI, industrial control, and automotive.

Join us at our dedicated demo table to experience live demonstrations, explore NXP-powered embedded solutions, and discuss your next embedded project with the Forlinx Embedded team.

Explore Our Live Demonstrations

i.MX 95 + Ara 240 AI Accelerator — Multimodal AI

Experience a multimodal AI demonstration powered by the NXP i.MX 95 and an AI accelerator, highlighting high-performance edge computing for intelligent applications.

i.MX 93 — LVGL HMI

Explore an i.MX 93-based HMI solution with LVGL, demonstrating responsive graphics and an efficient interface for embedded applications.

i.MX 94 — Bring-up & Display Solution

See an i.MX 94-based display solution in action, showcasing platform bring-up and display capabilities for embedded applications.

München, Germany – November 10–13, 2026 — Forlinx Embedded will participate in electronica 2026, one of the world's leading trade fairs for the electronics industry, taking place at the Trade Fair Center at Messe München.

Come visit us at Hall-C5 Booth 331 and discover our latest System-on-Modules (SoMs), development boards, embedded control units (FCUs), and application-oriented embedded solutions. From high-performance Edge AI platforms to industrial and IoT applications, Forlinx Embedded is here to help accelerate your project to market while ensuring reliability and long-term product support.

What to Expect at electronica 2026

Ultra-Robust Platform Launch

• SoMs & SBCs based on Qualcomm Dragonwing™ IQ8 & IQ9

Edge AI in Action

• Multimodal AI & Digital Human
• Multi-channel Real-time Recognition

A Broad Embedded Product Portfolio

• SoMs, development boards, and FCUs based on leading processor platforms from NXP, Rockchip, Texas Instruments, and Allwinner

Whether you are updating an existing design or planning your next-generation project, we look forward to meeting you in electronica and exploring how Forlinx can support your next embedded project!

Taking the SPI3 Adaptation of OKMX9352-C Development Board as an Example

In certain industrial control, data acquisition, gateway, and multi-port network device applications, when the number of native Ethernet interfaces of the processor is insufficient to meet the requirements, additional network interfaces can be expanded via the SPI interface. This article, based on the OKMX9352-C development board and the Linux 6.1.36 system, introduces the adaptation process of using the W5500 module to expand a 100M Ethernet port through SPI3. The main steps include kernel driver configuration, device tree modification, hardware connections, driver compilation and loading, and network communication testing.

Figure 1: W5500 Network Module Used in Testing

1. Testing Plan

This adaptation was carried out primarily in the following environments:

• OKMX9352-C Development Board

• Linux 6.1.36

• LPSPI3 Interface

• W5500 Network Module

  OKMX9352-C
  │
  │ SPI3
  ├── SCS
  ├── MISO
  ├── MOSI
  ├── SCLK
  ├── INT
  └── RST
  │
  ↓
  W5500
  │
  ↓
  Ethernet

On the Linux system side, it is necessary to configure the WIZnet-related drivers and add a W5500 node in the device tree.

2. Enabling Linux Kernel Drivers

First, enable WIZnet-related driver support in the Linux Kernel. Navigate to the kernel configuration path:

  Device Drivers
  └── Network device support
      └── Ethernet driver support

Find and enable the following configurations:

  [*] WIZnet devices
  <M> WIZnet W5100 Ethernet support
  <M> WIZnet W5100/W5200/W5500 Ethernet support for SPI mode

In this instance, the relevant functions are compiled as modules. Although the actual hardware used is the W5500, the corresponding driver module name generated by the Linux kernel is:

  w5100.ko
  w5100-spi.ko

3. Modifying the Device Tree

This implementation uses LPSPI3 on the OKMX9352-C to connect to the W5500. Add the W5500 device under the LPSPI3 node. The reference configuration is as follows:

  &lpspi3 {
  fsl,spi-num-chipselects = <1>;
  pinctrl-names = "default", "sleep";
  pinctrl-0 = <&pinctrl_lpspi3>;
  pinctrl-1 = <&pinctrl_lpspi3>;
  cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
  status = "okay";
  
  ethernet: w5500@0 {
  compatible = "wiznet,w5500";
  reg = <0>;
  status = "okay";
  pinctrl-names = "default";
  pinctrl-0 = <&pinctrl_w5500>;
  interrupt-parent = <&gpio2>;
  interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
  spi-max-frequency = <15000000>;
  };
  };

Key configuration items include:

compatible = "wiznet,w5500": Specifies that the current SPI device is a W5500.

reg = <0: Corresponds to the SPI chip select.

interrupts = <5 IRQ_TYPE_EDGE_FALLING>: Configures the interrupt trigger mode for the W5500.

spi-max-frequency = <15000000>: The SPI maximum frequency for this test is set to 15 MHz.

4. Configuring SPI Pin Multiplexing

After completing the device node configuration, it is also necessary to configure the pin multiplexing for SPI3. The reference configuration is as follows:

  pinctrl_lpspi3: lpspi3grp {
  fsl,pins = <
  MX93_PAD_GPIO_IO08__GPIO2_IO08 0x3fe
  MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe
  MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe
  MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe
  >;
  };

At the same time, configure the INT and RST pins on the W5500:

  pinctrl_w5500: w5500grp {
  fsl,pins = <
  MX93_PAD_GPIO_IO04__GPIO2_IO04 0x31e // INT
  MX93_PAD_GPIO_IO05__GPIO2_IO05 0x31e // RST
  >;
  };

5. Hardware Connection

The wiring connections between the W5500 module and the OKMX9352-C are as follows:

Level Note: The W5500 logic level is 3.3V. If the SoC’s corresponding SPI pins are at 1.8V, they should not be directly connected. A level conversion circuit must be included in the hardware design.

6. Compiling the Kernel and Drivers

After the Kernel configuration and device tree modifications, recompile the kernel in the OKMX93 Linux SDK:

./build.sh kernel

Upon successful compilation, the main files that need to be updated for this test include:

  OK-MX93-C.dtb
  w5100.ko
  w5100-spi.ko

The development board update method referenced in the test materials is as follows:

  cp /run/media/boot-mmcblk1p1/OK-MX93-C.dtb /run/media/Boot-mmcblk0p1/
  cp /run/media/boot-mmcblk1p1/w5100.ko ./
  cp /run/media/boot-mmcblk1p1/w5100-spi.ko ./

7. Loading the W5500 Driver

After completing the device tree replacement and booting the system, load the W5500 driver modules sequentially:

  insmod w5100.ko
  insmod w5100-spi.ko

After the modules are loaded, execute:

ifconfig -a

If the device tree, SPI communication, and drivers are functioning correctly, you will see a new network interface added to the system. In this test, it is identified as eth2.

eth2: flags=<UP, BROADCAST, RUNNING,MULTICAST,DYNAMIC> mtu 1500

If the network card is not yet active, you can run the following command:

ifconfig eth2 up

8. Configuring IP and Testing Network Communication

After the driver is successfully loaded, configure an IP address for the W5500 network interface:

ifconfig eth2 172.20.2.167

Then perform a Ping test with the specified network card:

ping -I eth2 172.20.2.166

The initial test results indicated that all four data packets were successfully received, demonstrating a packet loss rate of 0 percent. This confirms that the SPI communication, the W5500 driver, the eth2 network interface, and the IP communication link were all established successfully.

  4 packets transmitted, 4 received, 0% packet loss
  rtt min/avg/max/mdev = 0.076/0.089/0.127/0.021 ms

9. Adaptation Process Overview

  Confirm SPI interface and voltage levels
  ↓
  Enable Linux WIZnet driver
  ↓
  Modify LPSPI3 device tree
  ↓
  Configure CS / MISO / MOSI / SCLK
  ↓
  Configure INT / RST
  ↓
  Recompile Kernel and DTB
  ↓
  Update device tree and load driver
  ↓
  System recognizes eth2
  ↓
  Configure IP and perform Ping test
  ↓
  Network communication functioning normally

10. Key Issues to Focus on During Debugging

First, confirm interface voltage levels

W5500 operates at 3.3V logic levels. If the corresponding SoC SPI bank uses 1.8V, a level-shifting circuit must be added.

Driver name is not w5500.ko

The Linux kernel modules for W5500 SPI mode are w5100.ko and w5100-spi.ko.

Pay attention to SPI chip select configuration

In this project, LPSPI3_PCS0 is connected to the SCS of W5500, and configured in the device tree using cs-gpios.

Pay attention to interrupt configuration

The INT pin of W5500 is connected to GPIO_IO04. The hardware connection must match the interrupt description in the device tree.

Confirm whether the network device is created

After loading the driver, use ifconfig -a to verify that eth2 appears before proceeding to IP configuration and ping testing.

11. Summary

This document, based on the OKMX9352-C + Linux 6.1.36 platform, completes the adaptation of expanding an Ethernet interface via LPSPI3 connection to a W5500 module.

The entire process includes:
Kernel driver configuration
Device tree modifications
SPI and interrupt pin configuration
Kernel and DTB compilation
Driver loading
Network communication testing

During testing, after driver loading, the system successfully recognized the newly added eth2 network card. The network card could be brought up normally and performed IP configuration and ping communication with 0% packet loss, indicating that the basic functionality of the SPI-expanded W5500 network interface solution has been validated.

For applications with limited native Ethernet interfaces that require additional network ports, this solution serves as a reference for expanding 100 Mbps Ethernet interfaces via SPI on the OKMX93xx platform.

This article demonstrates how to run the FAI-ARA240-M ai accelerator module on the Forlinx OK-MX9596-C development board. The demonstration will use the yolov8n-gstreamer-ara2 model provided by NXP as an example.

Hardware Preparation

The hardware prepared for this test includes:

• OK-MX9596-C Development Board

• FAI-ARA240-M ai accelerator + M.2 adapter board

During testing, the ARA240 ai accelerator and M.2 adapter board should be inserted into the PCIe 3.0 slot of the OK-MX9596-C development board.

The final setup is shown in the diagram below:

1. Powering Up and Startup

Connect the development board to a 12V power supply. Then, connect the DEBUG port on the OK-MX9596-C carrier board to a computer using a Type-C data cable. Afterward, four additional serial port devices can be seen in the computer’s Device Manager.

Open Serial Port A (e.g., COM48) for debugging. Configure the serial terminal with the following settings:

• Baud rate: 115200

• Data Bits: 8

• Stop Bits: 1

• No parity bit

• No-flow control

Once it has successfully logged in to the serial terminal, use the following command to check whether the computing power card module has been recognised.

root@ok-mx95-c:~# lspci

See the following output:

0001:01:00.0 Processing accelerators: Device 1e58:0002 (rev 02)

At this point, it indicates that the development board has successfully recognized the ai accelerator module. However, so far, only the PCIe device has been detected, and the ai accelerator cannot yet be used normally. Please further configure the software environment to enable the OK-MX9596-C development board to properly operate the ARA240 ai accelerator.

Environment Deployment

The following software packages are required. These files can be obtained from the official NXP website and are all official open-source packages.

• rt-sdk-ara2.deb.

• yolov8n-gstreamer-ara2.deb

Before proceeding with the deployment, please first configure the development board’s network settings to enable access to the external network, as this will involve downloading files over the internet later on:

// Set the IP address and subnet mask root@ok-mx95-c:~# ifconfig eth1 10.10.19.216 netmask 255.255.255.0 
// Set the default gateway root@ok-mx95-c:~# route add default gw 10.10.19.254 
// Configure DNS root@ok-mx95-c:~# echo "nameserver 222.222.202.202" > /etc/resolv.conf 
// Test external network connectivity root@ok-mx95-c:~# ping www.baidu.com -c 3
PING www.a.shifen.com (124.237.178.212) 56(84) bytes of data.
64 bytes from 124.237.178.212: icmp_seq=1 ttl=54 time=1.77 ms
64 bytes from 124.237.178.212: icmp_seq=2 ttl=54 time=1.56 ms
64 bytes from 124.237.178.212: icmp_seq=3 ttl=54 time=1.65 ms
--- www.a.shifen.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2014ms
rtt min/avg/max/mdev = 1.561/1.658/1.765/0.083 ms

Deploy rt-sdk-ara2

Copy the rt-sdk-ara2.deb file to the development board’s file system. There are many ways to copy files, such as via a TF card, USB or SCP; here, upload them to the development board’s file system via an SFTP server.

Once the copying is complete, use the following command to install the package:

root@ok-mx95-c:~# dpkg -i rt-sdk-ara2.deb

As shown below, this indicates that the installation was successful and that the rt-sdk-ara2.service service has been created.

Once the installation is complete, a “kinara” directory will be created in the home directory, containing a “driver” subdirectory which holds various driver and module files.

Please not that the operation of “rt-sdk-ara2.service” depends on the successful loading of the driver modules mentioned above. However, as the uiodma.ko file provided in the official installation package is not compatible with the OK-MX9596-C’s current kernel version, it cannot be loaded directly by the system.

Please extract these files and place them in the OK-MX9596-C development environment, then compile them separately within the relevant kernel source code. Once compilation is complete, copy them back to the corresponding directory in the development board’s file system, where you will find the following files:

Afterwards, restart the development board; if you see the following boot messages, this indicates that the deployment was successful.

Use the following command to check the service status and background processes.

root@ok-mx95-c:~# dpkg -i rt-sdk-ara2.deb
root@ok-mx95-c:~# ps -eaf|grep proxy

Deploying yolov8n-gstreamer-ara2

Copy the “yolov8n-gstreamer-ara2.deb” file to the development board’s file system. There are many ways to copy files, such as via a TF card, USB or SCP; here, upload them to the development board’s file system via an SFTP server.

Once the copying is complete, use the following command to install the package:

root@ok-mx95-c:~# dpkg -i yolov8n-gstreamer-ara2.deb

As shown below, this indicates that the installation was successful.

Once the installation is complete, run the following command to download the YOLOv8n model.

root@ok-mx95-c:~# run_model_download.sh

Install the software by following the steps below：

• The software environment deployment is now complete, and AI model testing can proceed.

4. Demonstration

The model demonstrated here is yolov8n, a vision model. For this demo, use Forlinx 10.1-inch LVDS screen as the display module.

The model demonstrated here is yolov8n, a vision model. This demonstration uses Forlinx’s 10.1-inch LVDS screen as the display module.

Single-Stream Display

First, preview one of the original videos using GStreamer with the following command:

root@ok-mx95-c:~# gst-launch-1.0 -v filesrc location=/usr/share/test_video/video_0.mp4 ! h264parse ! v4l2h264dec ! waylandsink

Then use the following command to run the YOLOv8n test demo, specifying single-channel display.

root@ok-mx95-c:~# run_yolov8n_ara2 -s 1

Multi-Stream Display

• Four-Stream Display

First, look at the preview of the four original video feeds. The command is as follows:

root@ok-mx95-c:~# gst-launch-1.0 \
compositor name=comp \
sink_0::xpos=0 sink_0::ypos=0 \
sink_1::xpos=640 sink_1::ypos=0 \
sink_2::xpos=0 sink_2::ypos=400 \
sink_3::xpos=640 sink_3::ypos=400 \
! waylandsink \
filesrc location=/usr/share/test_video/video_0.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=640,height=400 ! comp.sink_0 \
filesrc location=/usr/share/test_video/video_1.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=640,height=400 ! comp.sink_1 \
filesrc location=/usr/share/test_video/video_2.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=640,height=400 ! comp.sink_2 \
filesrc location=/usr/share/test_video/video_3.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=640,height=400 ! comp.sink_3

Then use the following command to run the YOLOv8n test demo, specifying single-channel display.

root@ok-mx95-c:~# run_yolov8n_ara2 -s 4

• Eight-Stream Display

First, preview the original eight video streams with the following command:

root@ok-mx95-c:~# gst-launch-1.0 \
compositor name=comp \
sink_0::xpos=0 sink_0::ypos=0 \
sink_1::xpos=320 sink_1::ypos=0 \
sink_2::xpos=640 sink_2::ypos=0 \
sink_3::xpos=960 sink_3::ypos=0 \
sink_4::xpos=0 sink_4::ypos=400 \
sink_5::xpos=320 sink_5::ypos=400 \
sink_6::xpos=640 sink_6::ypos=400 \
sink_7::xpos=960 sink_7::ypos=400 \
! waylandsink \
filesrc location=/usr/share/test_video/video_0.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_0 \
filesrc location=/usr/share/test_video/video_1.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_1 \
filesrc location=/usr/share/test_video/video_2.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_2 \
filesrc location=/usr/share/test_video/video_3.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_3 \
filesrc location=/usr/share/test_video/video_4.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_4 \
filesrc location=/usr/share/test_video/video_5.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_5 \
filesrc location=/usr/share/test_video/video_6.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_6 \
filesrc location=/usr/share/test_video/video_7.mp4 ! h264parse ! v4l2h264dec ! videoscale ! video/x-raw,width=320,height=400 ! comp.sink_7

Then use the following command to run the YOLOv8n test demo, specifying eight-stream display.

root@ok-mx95-c:~# run_yolov8n_ara2 -s 8

This completes the entire process of running the FAI-ARA240-M ai accelerator on the OK-MX9596-C development board.

Forlinx Embedded and Rockchip jointly launch the FET1126BJ-C SoM, powered by the RV1126B processor. It features a board-to-board connector design, specifically developed for vision edge computing applications such as smart security and industrial inspection. It facilitates plug-and-play debugging during the R&D phase and enables quick maintenance of equipment in later stages.

The Forlinx Embedded FET1126BJ-C System on Module (SoM) features a 3 TOPS Neural Processing Unit (NPU) that supports mixed-precision inference with INT8 and INT4. This enables efficient execution of models like YOLOv5/v8 and ResNet for real-time tasks such as object detection and facial recognition on-device, enhancing response times and privacy without relying on the cloud.

The FET1126BJ-C features multi-camera input and a robust ISP image signal processor, providing clear and stable video output even in challenging lighting conditions, thus ensuring high-quality input for algorithms.

The FET1126BJ-C features AOA (Always On Audio) and AOV (Always On Video) standby modes, significantly lowering standby power consumption to the milliwatt range. This feature is specifically designed for applications with stringent battery life requirements, such as mobile inspection robots and battery-powered wireless monitoring devices.

The Forlinx Embedded FET1126BJ-C SoM features an LPDDR4 memory design, offering lower power consumption and a wider operating temperature range. Compared with the standard DDR4 temperature range of 0 °C to +70 °C, commercial-grade LPDDR4 chips can operate within an ambient temperature range of –20 °C to +85 °C, making them suitable for a wide variety of complex operating conditions.

The development board exposes all functional pins, offering a comprehensive suite of interface resources, including USB 3.0, MIPI DSI/CSI, HDMI, Gigabit Ethernet, UART, SPI, I2C, and a 40-pin GPIO header, facilitating flexible peripheral expansion and supports a wide range of development scenarios, such as embedded vision, edge computing, and AIoT applications.

The Forlinx Embedded OK1126BJ-C development board features a standard 40-pin GPIO connector, making it easy to connect to a wide range of external hardware, lowering the barrier to entry for development and accelerating the implementation of AI projects.

Forlinx Embedded offers comprehensive SDK support, covering Linux systems, drivers, middleware and AI toolchains, and comes pre-installed with mainstream frameworks such as TensorFlow Lite and PyTorch Mobile to accelerate model deployment. Whether you are an algorithm engineer or an embedded developer, you can quickly build prototypes and shorten time-to-market.

For industrial-grade applications requiring the deployment of vision AI computing power at the edge, the FET1126BJ-C SoM provides reliable underlying hardware support. Furthermore, to meet various physical design requirements, Forlinx offers the FET1126B-S SoM in a castellated-hole package, designed to meet development needs in compact spaces and high-vibration environments, thereby providing greater flexibility in hardware configuration for projects.

In industrial automation and high-speed data acquisition, ARM-FPGA co-design is common, but their communication interfaces face a trade-off: SPI is too slow (~10 Mbps), while PCIe is overkill with high complexity and cost.

Forlinx Embedded addresses this with a cost-effective solution using Rockchip’s DSMC (Double Data Rate Serial Memory Controller) bus. Test results show stable read/write bandwidth exceeding 300 MB/s, offering a new approach to industrial communication bottlenecks.

1. Test Platform: ARM+FPGA Integrated Evaluation Board

Forlinx Embedded has independently developed an FPGA+ARM integrated test board to precisely assess the performance of ARM-FPGA communication interfaces while eliminating signal degradation and throughput loss typically caused by traditional wiring methods.

It supports four SoMs (RK3572, RK3576, RK3568, RK3506) and seamlessly integrates FPGA cores from vendors like Xilinx, Anlogic, and Gowin, offering a stable, reliable hardware base for heterogeneous computing performance validation.

Supported interconnect interfaces per platform are as follows:

2. DSMC Communication Architecture and Testing Solution

This test utilizes the Forlinx Embedded development board to verify the communication performance between the FET3572-C SoM and the FPGA via the DSMC bus.

2.1 Basic Test Environment

• Development Environment: Windows 10/11 64-bit; VMware 15 with Ubuntu 22.04 (Please refer to the Forlinx official website RK3572 development environment setup guide).

• System Version: U-Boot-2025.04, Linux Kernel 6.12.58, Buildroot 2025.02.7

• Hardware Platform: FET3572x-C_FPGA_Test V1.0 Industrial Development Board

• Architecture Mode: RK3572 acts as the DSMC host, and the FPGA acts as the DSMC slave.

2.2 Bandwidth Test Results

2.3 ARM-Side Implementation Logic

On the ARM side, a Linux application initiates read/write requests via the /dev/dsmc/cs0 device node. The DSMC driver in the kernel receives the command and invokes the CPU_DMA engine. The DMA_MMP module then facilitates direct data movement between DDR memory and the DSMC_IO hardware interface, eliminating CPU involvement in data copying and ensuring high throughput and low latency.
The testing program can perform read/write verification by configuring parameters such as packet size and loop count, and outputs the bit error rate and measured transmission rate.

2.4 FPGA-Side Implementation Logic

The FPGA side implements the Local Bus Slave function:

• Data Reception from ARM: Data is sampled via IOBUF and IDDR before being stored in DRAM.
• Data Transmission to ARM: Data from DRAM is output to the DSMC bus via ODDR and IOBUF for data return.

2.5 System Architecture Diagram

The overall architecture consists of two layers: the ARM side and the FPGA side.

ARM Side: The path from user-space application to the underlying hardware interface sequentially includes the Linux application, device node, driver layer, DMA engine, and DSMC hardware I/O.

FPGA Side: Correspondingly implements data sampling, storage, and return logic.

High-speed interaction is achieved between the two ends via the DSMC bus.

3. Test Demonstration: Stable Transfer, Zero Bit Error

This test is conducted using the dsmc_mmap_test tool, which allows flexible configuration of parameters such as transmission mode, loop count, payload length, and clock frequency. The core parameters are described as follows:

Execute:./dsmc_mmap_test -c 1000 -l 65528 -v -p
-o, --op. operation: rw (write+read+verify, default), wo (write only), ro (read only)
-c, --cycle.transfer count
-l, --length. payload bytes per transfer (12-byte preamble added automatically
-G, --gen_mode. data pattern 0=random 1=sequential
-v, --verbose. dump write/read data
-P, --perf. print performance (MiB/s) summary
-f, --freq. set DSMC IO clock freq in Hz (e.g. 100000000)

This test selected a payload size of 65,528 bytes (to avoid potential overflow issues at 65,536 bytes) and performed 100-cycle and 1000-cycle read/write verification tests, with results as follows:

100-Cycle Read/Write Test

Test Command: ./dsmc_mmap_test -c 100 -l 65528 -v -P
Transfer Mode: Read/Write with Verification
Test Result: 100 cycles completed successfully; 0 failures, 0 bit errors; Bit Error Rate: 0.0000%
Performance: Average Write Speed: 303.10 MiB/s, Average Read Speed: 305.59 MiB/s

1000-Cycle Read/Write Test

Test Command: ./dsmc_mmap_test -c 1000 -l 65528 -v -P
Transfer Mode: Read/Write with Verification
Test Result: 1000 cycles completed successfully; 0 failures, 0 bit errors; Bit Error Rate: 0.0000%
Performance: Average Write Speed: 303.53 MiB/s, Average Read Speed: 304.91 MiB/s

Both test sets demonstrate that the DSMC bus delivers stable performance in long-duration, high-volume data transfer scenarios. Read/write speeds consistently remain at the 300 MB/s level throughout testing, with a sustained bit error rate of 0. This fully meets the demands of industrial applications for high-speed, reliable communication.

The DSMC bus achieves near-PCIe level transmission performance with moderate development cost and hardware requirements, making it perfectly suited for medium-to-high-speed industrial interconnection scenarios. The Forlinx Embedded FET3572-C SoMs have completed comprehensive DSMC interface adaptation and validation, enabling customers to accelerate the development of heterogeneous computing products such as industrial PLCs, multi-axis motion control systems, and high-speed data acquisition solutions.

With the rise of smart manufacturing and digital transformation, businesses are seeking enhanced performance in edge computing, improved AI vision applications, and better compatibility with industry-specific algorithms. To meet this trend, Forlinx Embedded proudly presents the FCU3101 Edge AI Computing Box. Specifically engineered for industrial and commercial scenarios, it integrates high-performance computing, rich I/O interfaces, and a powerful software ecosystem, delivering multi-dimensional support for intelligent device upgrades and enabling rapid project deployment and implementation.

1. Native 3 TOPS AI Computing | Concurrent Multi-Channel Vision Processing

The large-scale deployment of AI vision relies on stable and ample computing power. Traditional edge devices often struggle with latency, stuttering, and algorithm scheduling conflicts during multi-channel video analysis, falling short in high-concurrency scenarios.

The Forlinx Embedded FCU3101 Edge Computing Box, powered by the Rockchip RV1126B platform, delivers 3 TOPS of native INT8 AI computing performance. Its heterogeneous architecture offloads AI workloads to a dedicated NPU, freeing up CPU resources. Capable of parallel processing for multiple HD video streams and simultaneous execution of diverse algorithms, it provides a high-stability, low-latency edge AI solution for industrial inspection, smart security, retail vision, and beyond.

2. In-House AI Algorithms – Significantly Reduces Project Deployment Time

Equipped with Forlinx Embedded’s full set of self-developed and optimized AI algorithm suites, covering over ten common applications such as personnel behavior detection, fire/smoke recognition, helmet detection, and reflective vest identification. Customers can skip the time-consuming process of training and tuning algorithms from scratch, enabling rapid deployment as soon as the device is installed. This effectively meets the urgent timelines of fast-paced projects.

3. Dual-Specification Environmental Adaptability – Covering Industrial and Commercial Scenarios

Industrial-grade: Operating temperature range of -40℃ to 85℃, suitable for harsh environments such as factory production lines, metallurgical workshops, and mining sites.
Commercial-grade: Operating temperature range of 0℃ to 70℃, ideal for scenarios like campus security, retail footfall analytics, and parking lot management.
This design simplifies selection, enhances deployment flexibility, and ensures reliable performance across diverse application environments.

4. Comprehensive Interface Configuration – One-Stop Integration of Multiple Peripherals

The FCU3101 features a diverse selection of peripheral interfaces, including dual Ethernet ports, multiple serial ports, I/O input/output interfaces, an HDMI display interface, USB ports, as well as TF card and SIM card slots with antenna interfaces. It easily connects to various on-site peripherals, such as IP cameras, displays, PLCs, audio amplifiers, and alarm devices—eliminating the need for additional expansions or adapters. This seamless integration across a wide range of industrial applications significantly reduces the time required for on-site installation and commissioning.

5. Integrated Chassis Design – Full Compliance Assurance

Featuring a compact, integrated hardware architecture, the device is small in size yet highly adaptable. It supports multiple deployment methods such as cabinet embedding, wall mounting, pole installation, and embedded placement on production lines, making it suitable even for tight spaces. It features a cohesive, family-style industrial aesthetic with a front-facing LED light strip that users can customize for different colors and flashing patterns. This allows for clear visual communication of operational statuses, alerts, and faults, effectively combining standardized industrial design with practical on-site maintenance needs.

The device fully complies with authoritative certifications including CE (Electromagnetic Compatibility), FCC (Radio Frequency), and RoHS (Hazardous Substance Control). It has also undergone comprehensive industrial environment reliability tests before leaving the factory — such as wide-temperature, vibration, and dust resistance tests — ensuring its hardware stability under rigorous validation. This enables it to meet the compliance and bidding requirements for various commercial and industrial projects around the world.

6. Multi-scenario Deployment – Empowering Industry Intelligence Upgrades

Leveraging mature AI vision processing capabilities and an edge computing architecture, the FCU3101 is widely adaptable to various industry scenarios:

• Campus AI Surveillance: Enables real-time identification and alerting of personnel, vehicles, and abnormal events in factories, communities, industrial parks, and more, enhancing campus security management efficiency.
• Smart Manufacturing: Supports defect detection on production lines, material counting, and operational compliance management, driving the digital and intelligent transformation of production processes.
• Robotic Arm Collaboration: Works with industrial robotic arms to perform vision-based positioning and workpiece recognition, facilitating flexible production setups.

The launch of the FCU3101 edge AI computing terminal further enriches Forlinx Embedded’s product lineup in the AI edge computing domain, offering a lightweight, cost-effective hardware solution for AI implementation in industrial and security applications. Looking forward, Forlinx Embedded will continue to deepen innovation in the integration of embedded technology with AI and edge computing, delivering more products and solutions tailored to real-world industry needs.

Compared to round-the-clock visual intelligent monitoring, traditional field-based power line monitoring solutions suffer from the following critical shortcomings:

(1) Inefficient Manual Inspection, Insufficient Coverage

Manual inspections are infrequent, costly, and can take days or even weeks for long-distance lines. Inspections completely stall under harsh weather conditions, making it difficult to handle faults and accidents promptly.

(2) Pure Sensor Devices Only Measure Data, Cannot Restore the Scene

Hardware devices like GPS and inclinometers can achieve millimeter-level deformation monitoring. However, upon alarm, they only output numerical data, unable to visually restore the scene or distinguish the cause of faults.

(3) Conventional Video Surveillance Has Night Vision Blind Spots and Limited Field of View

Standard cameras perform poorly at night. High-power supplementary lighting consumes too much energy and is unsuitable for off-grid power supply in remote areas. Furthermore, fixed-angle cameras have significant blind spots, making it difficult for a single device to cover the entire area.

In summary, traditional monitoring methods have respective shortcomings: manual inspection ''can see but cannot measure accurately'', pure sensors ''can measure accurately but cannot see'', and conventional cameras ''can see but struggle with darkness and have blind spots''. For the ''last kilometer'' of monitoring high-voltage lines in remote areas, there has always been a lack of an all-weather, blind-spot-free, and intelligent visual monitoring solution.

Addressing the multiple shortcomings of traditional monitoring methods, Forlinx Embedded has developed a Panoramic Visual Integrated Monitoring Solution based on the OK1126BJ-S development board. This solution offers a comprehensive breakthrough from multiple dimensions: night vision imaging, full-area coverage, intelligent recognition, and low-power endurance.

1. Achieving Clear Nighttime Field Imaging

Nighttime is the peak period for transmission line security incidents: mountain fires often spread late at night, illegal excavation and mechanical construction damage mostly occur in the early morning, and unauthorized personnel intrusion often happens in dark environments. Night vision capability directly determines the practical value of remote monitoring equipment.

The Starlight-level Sensor solution utilizes a 0.01lux image sensor, suitable for extremely low-light environments like starry nights (starlight illumination ≈0.01lux, full moon only ≈0.2lux). Without additional lighting, it outputs 1080P full-color HD video, enabling all-weather covert monitoring.

Leveraging the Starlight-level Sensor + AI-ISP Intelligent Image Processing Engine, it significantly optimizes imaging in low-light conditions:

AI Intelligent Pixel-level Noise Reduction (AIBNR)

Unlike traditional fixed-parameter 3DNR noise reduction algorithms, AI-ISP uses NPU deep learning models for frame-by-frame processing, effectively suppressing noise in dark areas while completely preserving texture details in bright areas. Even in 0.01lux extreme darkness, the image remains clean, transparent, and object outlines are sharp.

AI Dynamic Defogging Algorithm

Mountainous transmission lines often experience fog, rain, and snow. The system can real-time identify haze concentration and dynamically adjust defogging intensity. Combined with anti-shake technology, video remains clear without blurring or trailing even when the tower sways slightly in strong winds.

Hardware Architecture Advantage: AI-ISP has a dedicated independent processing unit. Image optimization does not consume main NPU computing power. Night vision image processing and backend AI recognition run synchronously without competing for resources.

Forlinx Embedded SC285SL+OK1126BJ-S Development Board Night Vision Demo:

Comparative tests show: under the same no-light environment, this solution’s 1080P@60FPS Starlight module produces clean, sharp images. Ordinary consumer-grade smartphone 1080P@30FPS cameras show dense noise and lost details. This fully validates the superiority of the Starlight Panoramic Visual Integrated Monitoring Solution in remote low-illumination scenarios.

2. 360° Stereoscopic Vision, Full-Area Blind-Spot-Free Monitoring

A single lens has a limited field of view. This solution employs a four-channel 1080P@30FPS AHD camera stereoscopic vision array. Each channel is paired with a 150° wide-angle lens. Through seamless algorithmic stitching, it achieves a horizontal 360° panoramic view, presenting the complete tower and power line scene on a single screen.

The device automatically generates panoramic snapshots every 15 minutes. After overlaying device watermarks and GPS monitoring data, they are automatically uploaded to the grid management platform, ensuring no observation blind spots above/below the tower or in the surrounding power line. Equipped with mature multi-channel synchronous capture, precise image registration, and intelligent pixel fusion algorithms, the panoramic stitched video has smooth transitions, with no obvious color differences, ghosting, or misalignment at lens junctions, truly achieving comprehensive stereoscopic coverage of remote towers.

Forlinx Embedded Panoramic Stitching Demo:

3. Edge AI Intelligent Vision: From Seeing to Understanding

The solution natively integrates AI human shape detection algorithms, capable of real-time framing of intruding personnel for basic anomaly alerts. It also reserves sufficient edge-side AI computing power, supporting customized recognition model development based on power grid scenarios. The entire pipeline is open and adaptable to various monitoring needs:3

Custom Intelligent Detection Algorithms

Models can be deployed as needed: mountain fire identification (smoke, open flame early warning), external force damage identification (construction machinery/vehicles approaching the tower base), line defect identification (broken strands, damaged insulators), floating foreign object identification (plastic, tarpaulin hanging on lines), etc. Supports customer-developed model fine-tuning or rapid iteration based on general recognition models, adapting to differentiated monitoring scenarios like transmission, mining, and water conservancy.

Custom Data Collection Strategies

Image capture frequency, alarm trigger conditions, and upload data types are all flexibly configurable. Supports the complete business chain of cloud model training and edge-side real-time inference.

Custom Alarm & Linkage Logic

AI inference is completed locally on the edge device; alarm response does not rely on network transmission. Alarm thresholds, recording triggers, image wake-up uploads, and other linkage strategies are freely configurable. Panoramic views and AI alarm information are linked for push notifications, forming a complete hazard handling loop.

Different monitoring scenarios have significantly different risk types: power lines focus on preventing mountain fires and construction damage; slopes/mines prioritize landslides and personnel intrusion; water conservancy points focus on floating debris and abnormal water levels. The open customization architecture ensures algorithm autonomy, rapid scenario adaptation, and continuous functional iteration. Whether customers develop their own algorithms (Forlinx Embedded provides underlying computing power and technical development support) or opt for one-stop custom development (full-process delivery: data collection, model training, edge deployment), the solution is flexible. Using the hardware platform as the foundation, it allows industry-specific algorithms to have room for autonomous development.

4. Accompanying Implementation Recognition Effects

4.1 Intelligent Mountain Fire Detection

Accurately frames dense smoke/open flame areas and outputs confidence levels, enabling warnings in the early stages of fire.

4.2 Insulator Defect Identification

Automatically identifies the status of multiple insulator groups on the tower, marking abnormal points.

4.3 Line Foreign Object Identification

Accurately locates floating debris like hanging plastic/tarpaulin and promptly pushes alarms.

5. AOV Low-Power Field Test, Off-Grid Self-Sustaining for 90 Days

Remote monitoring sites lack grid power. Equipment endurance is the core prerequisite for long-term stable operation. The entire solution significantly reduces overall power consumption through AOV (Always-On Video) technology, making it suitable for solar-powered scenarios

Platform Power Consumption Field Test Data:

Endurance Calculation (Example: 18W Solar Panel + 32Ah Battery)

• Sleep Standby Mode (0.1W): Theoretical endurance over 90 days.
• Per-second Polling Detection Mode (0.19W): Theoretical endurance ~50 days.
• Continuous AI Recognition Full Load (1.6W): Can run uninterrupted for ~6 days.

Paired with an 18W solar photovoltaic panel for continuous daytime charging, the device remains stable on standby even during dozens of consecutive rainy days. AOV Core Logic achieves ''Wake-on-Demand'': Normally operates at an extremely low 0.1W standby. Once the camera captures a moving target, the device instantly wakes up and operates at full computing power to complete recognition and recording. This makes power-intensive functions like 24/7 starlight night vision, scheduled panoramic snapshots, and real-time AI recognition feasible in off-grid remote environments.

AOV Effect Demo:

6. Development Board Industrial-Grade Strength

Industrial Temperature Range, Stable Operation

Industrial-grade hardware design, operates uninterrupted in -40°C to 85°C environments, suitable for plateaus and extremely cold mountainous areas.

High Anti-Corrosion Protection

Passes 96-hour salt spray test, suitable for long-term stable deployment in coastal high-corrosion areas.

Disconnection & Resume Transmission Fault Tolerance

When the 4G network is interrupted, videos and snapshots are cached locally. All data is automatically retransmitted upon network recovery, achieving zero-loss storage.

Summary

This high-voltage line Starlight Panoramic Visual Monitoring Solution, developed based on RV1126B, precisely matches the core needs of unmanned inspection for transmission corridors. It integrates five core capabilities: Starlight Night Vision for all-weather clarity, Four-Channel Panoramic for complete coverage, Edge AI for intelligent understanding, GPS Sensing for precise measurement, and AOV Low-Power for long-term endurance A single hardware unit integrates multiple monitoring capabilities, providing 7×24 uninterrupted protection for transmission line safety.

The solution is adaptable to various remote monitoring scenarios such as transmission corridors, slope geology, open-pit mines, and water conservancy pipelines, creating an integrated visual monitoring solution for intelligent inspection of high-voltage lines. If you need the complete technical white paper or wish to customize a dedicated industry monitoring solution, please feel free to contact us anytime.

Quick Verification

For customers who want to quickly verify the functionality, a test kernel and deployment method are provided here. (For testing purposes only; subsequent development still requires self-compilation.)

The outer MIPI port of the development board corresponds to the device node /dev/video23.

The inner MIPI port of the development board corresponds to the device node /dev/video31.

Refer to the user manual for step-by-step kernel image flashing. You can directly click the link below to jump to the relevant section:

6.1.3 OTG Step-by-step Flashing Test

Place the IQ file ov13855_CMK-OT2016-FV1_default.json in the /etc/iqfiles directory of the development board’s filesystem.

The kernel image boot.img and IQ file ov13855_CMK-OT2016-FV1_default.json can be obtained from the attachments.

1.Kernel configuration

Ensure the kernel includes the following configurations. If they are missing, add them:

Kernel configuration file path: kernel/arch/arm64/configs/OK1126B-S-linux_defconfig

  CONFIG_VIDEO_OV13855=y
  CONFIG_VIDEO_DW9763=y
  CONFIG_VIDEO_TECHPOINT=y

Copy the diff file from the attachments to the SDK’s kernel directory.

Then, execute the following command in the SDK’s kernel directory to apply the corresponding patch:

patch -p1 < ov13855_tp2855.diff

Recompile the kernel image and flash it to the development board.

Refer to the user manual for step-by-step kernel image flashing. You can directly click the link below to jump to the relevant section:

6.1.3 OTG Step-by-step Flashing Test

2. Filesystem

The attachment provides the IQ file for OV13855: ov13855_CMK-OT2016-FV1_default.json.

Place this file in the /etc/iqfiles directory of the development board’s filesystem and check if the rkaiq process is running:

  root@OK1126B-buildroot:~# ps -ef | grep rkaiq
  root 1042 1 0 Jan24 ? 00:00:00 /bin/sh -c /usr/bin/rkaiq_3A_server 2>&1 | logger -t rkaiq_3A
  root 1044 1042 0 Jan24 ? 00:00:01 /usr/bin/rkaiq_3A_server
  root 1045 1042 0 Jan24 ? 00:00:00 logger -t rkaiq_3A
  root 1923 1075 0 00:23 ttyFIQ0 00:00:00 grep --color=auto rkaiq

If the process is not running, you need to start the rkaiq process.

root@OK1126B-buildroot:~# /etc/init.d/S40rkaiq_3A start

Note: When executing the following statements, the OV13855 camera must be connected to the 4-lane MIPI-CSI interface on the outer side of the development board (P9), otherwise the process will not be visible.

3. Camera Testing

Check the device node:

v4l2-ctl --list-devices

After running the command, the output should include the following segment:

  rkisp_mainpath (platform:rkisp-vir0):
  /dev/video23
  /dev/video24
  /dev/video25
  /dev/video26
  /dev/video27
  /dev/video30
  /dev/media3
  
  rkisp_mainpath (platform:rkisp-vir1):
  /dev/video31
  /dev/video32
  /dev/video33
  /dev/video34
  /dev/video35
  /dev/video38
  /dev/media4

Among them, /dev/video23 and /dev/video31 represent the external camera (P9) and the internal camera (P8) respectively.

The following steps use /dev/video23 as an example.

Check Supported Formats and Resolutions

v4l2-ctl --list-formats-ext -d /dev/video23

Camera Preview

gst-launch-1.0 v4l2src device=/dev/video23 ! video/x-raw, format=NV12, width=640, height=480, framerate=30/1 ! waylandsink

Camera Capture

gst-launch-1.0 v4l2src device=/dev/video23 num-buffers=1 ! video/x-raw,format=NV12,width=640,height=480 ! mppjpegenc ! filesink location=pic.jpg

Check whether pic.jpg is generated. You can copy it to a PC for viewing.

Record H.264 Video

gst-launch-1.0 v4l2src device=/dev/video23 num-buffers=100 ! video/x-raw,format=NV12, width=640,height=480 ! tee name=t ! queue ! mpph264enc ! queue ! h264parse ! qtmux ! filesink location=13855_h264.mp4 t. ! queue ! waylandsink

Play H.264 Video

gst-launch-1.0 filesrc location=13855_h264.mp4 ! qtdemux ! queue ! h264parse ! mppvideodec ! waylandsink

4. Attachments Download

Please click the link below to acquire the kernel image, IQ configuration file, and diff patch required for the OV13855 camera module verification:

Download OK1126B-S OV13855 Test Attachments (boot.img, ov13855_CMK-OT2016-FV1_default.json, ov13855_tp2855.diff)

1. On-Site Challenge: The Problem of Data Silos in Aging Facilities

In the field of industrial digitalization implementation, a large number of legacy industrial devices such as PLCs, meters, and sensors continue to operate on the Modbus protocol—data exists on the device side but is separated from cloud platforms, MQTT buses, and supervisory control systems by a ''protocol barrier,'' making it difficult for data to flow smoothly.

Traditional protocol conversion solutions often require specialized personnel to write custom collection programs or commission integrators for project-based development. Not only do these approaches have long deployment cycles and high investment costs, but adjustments to protocol mapping rules also require repeating the entire process of development, debugging, and deployment. This lack of flexibility has become a bottleneck in the digital transformation of many legacy devices.

Leveraging the Forlinx Embedded FCU1501 embedded control unit, protocol conversion can now be accomplished through a low-code approach that involves only ''dragging nodes and arranging connections'' visually.

2. The FCU1501 Features a Built-In Node-RED Protocol Conversion Engine

Node-RED is a widely recognized low-code orchestration tool in the field of Industrial IoT, extensively used in scenarios such as protocol conversion, edge data collection, and cloud integration. It is one of the core solutions adopted by many leading industrial gateway manufacturers to address the challenge of ''connecting legacy devices to networks.''

The Forlinx Embedded FCU1501 embedded control unit deeply integrates the capabilities of Node-RED into its system, eliminating the need for users to set up additional environments. It enables lightweight industrial protocol conversion right out of the box, with core capabilities including:

• Native Support for Mainstream Protocols: Industrial protocols such as Modbus TCP/RTU are ready to use, allowing direct connection to PLCs, smart meters, sensors, and other devices for rapid foundational data collection.
• Visual Drag-and-Drop Orchestration: No code writing is required for data collection; business logic can be defined simply by dragging nodes and connecting lines. On-site engineering personnel, even without specialized programming knowledge, can quickly adapt and make flexible adjustments.
• Free Conversion Between Multiple Protocols: Supports one-click conversion of collected Modbus data into standard protocols like MQTT/HTTP, enabling seamless integration with cloud platforms, SCADA systems, and enterprise data platforms.
• Local Real-Time Visualization: Features a built-in Dashboard function, allowing real-time data to be viewed via a local webpage without waiting for cloud uploads. This makes on-site debugging more efficient.
• Offline One-Click Deployment: The entire solution supports offline deployment, eliminating the need for a public internet connection or the presence of specialized IT personnel on-site. Environment setup and business configuration can be completed in just tens of seconds.
• Practical Test Validation: Stable and Seamless, Fully Low-Code Implementation
• We conducted a practical test using simulated meters (outputting real-time temperature, humidity, and pressure data) connected to the FCU1501 embedded control unit. The entire process required no manual coding: device data was collected via the Modbus protocol into the gateway, protocol rules were converted, data was published in real-time to an MQTT service, and simultaneously displayed on a local visualization panel.

The pointers on the temperature, humidity, and pressure dashboards swung in real-time, with data refreshed every 2 seconds. The entire process was free of lag and packet loss, demonstrating stable and smooth performance.

Additionally, the device supports real-time logging and reporting of operational data, enabling quick identification of equipment status and anomalies, significantly reducing the difficulty of on-site maintenance.

Adapting to Multiple Scenarios to Support Low-Cost Implementation of Industrial Digitalization

The low-code protocol conversion capability of the FCU1501 embedded control unit can be widely applied across various industrial and IoT scenarios:

• Digital Transformation of Legacy Production Lines: Achieves low-cost, rapid cloud integration of PLC and meter data, shortening the transformation cycle.

• Building Automation System Integration: Unifies data access for multi-system equipment such as HVAC, lighting, and access control.

• Distributed Site Data Collection: Completes edge-side data collection and preprocessing, reducing cloud bandwidth pressure.

• Remote Equipment Maintenance: Supports remote monitoring of equipment status and data preprocessing for predictive maintenance.

As an embedded control unit designed for industrial scenarios, the Forlinx Embedded FCU1501 breaks down the technical barriers of protocol conversion through a low-code approach, making industrial device connectivity and data flow simpler and more efficient. It provides a cost-effective edge-side solution for the implementation of industrial digitalization.

1. Solution Overview

Deploying Flutter applications in embedded Linux systems built with Buildroot typically relies on two mature open-source solutions, each tailored for different display scenarios and development needs:

Solution 1: flutter-elinux (Sony's Open-Source Solution)

This embedded Linux Flutter toolchain, officially maintained by Sony, supports both DRM/GBM direct rendering and compatibility with multiple display backends such as Wayland and X11. It offers broader adaptability across various scenarios.

Solution 2: flutter-pi (Lightweight Embedder)

A lightweight Flutter engine host program, implemented solely via low-level DRM/GBM interfaces for rendering. It requires no desktop environment dependencies, consumes fewer resources, and is better suited for pure embedded scenarios.

2. Comparison of Mainstream Solutions and Architectural Overview

2.1 Differences Between flutter-pi and flutter-embedded-linux:

2.2 Flutter-pi Runtime Architecture:

┌──────────────────────────┐
│FlutterApp(Dart) │→libapp.so(AOT compilation)
├──────────────────────────┤
│libflutter_engine.so│→Rendering engine+DartVM
├──────────────────────────┤
│flutter-pi(embedder)│→DRM/GBM Direct rendering
├──────────────────────────┤
│Mali-G52GPU+DRM/KMS │
├──────────────────────────┤
│BuildrootLinux(ARM64)│
└──────────────────────────┘

2.3 flutter-pi Rendering Pipeline

1 Flutter →OpenGLES command→libGLESv2.so→Mali-G52GPU→GBMbuffer→DRM→HDMI

3. Buildroot Native Flutter Package System

Starting with Buildroot 2024.02, the official release now includes a complete set of Flutter-related software packages. There's no need for additional porting; simply enabling the corresponding configuration in defconfig completes the compilation and integration.

The package directory is located under buildroot/package/, with the following structure:

buildroot/package/
├── flutter-engine/ # # Flutter Engine, compiled from source (gclient + GN + ninja)
│ ├── Config.in
│ ├── flutter-engine.mk
│ ├── gen-tarball # gclient Script to synchronize source code via gclient and package it
│ └── dot-gclient # gclient Configuration file
├── flutter-sdk-bin/ # Flutter SDK (host tools)
│ ├── Config.in.host
│ ├── flutter-sdk-bin.hash
│ └── flutter-sdk-bin.mk
├── flutter-pi/ # ardera 的 DRM-GBM embedder
│ ├── Config.in
│ ├── flutter-pi.hash
│ ├── flutter-pi.mk
│ └── 0001-user_input-touch-Fallback-to-10-slots.patch
├── flutter-embedded-linux/ # Sony 的 Wayland/X11/GBM embedder
│ ├── Config.in
│ ├── flutter-embedded-linux.hash
│ └── flutter-embedded-linux.mk
├── flutter-packages/ # Official Example App
│ ├── Config.in
│ ├── flutter-packages.hash
│ └── flutter-packages.mk

4. Hands-On Adaptation of flutter-pi (Using RK3568 Platform as an Example)

The following demonstrates the adaptation process for flutter-pi based on the RK3568 6.1.118 SDK environment. The adaptation logic for flutter-embedded-linux is similar; choose one of the two as needed.

Note: flutter-pi uses DRM for direct rendering and does not rely on the Weston desktop environment. After selecting this solution, Weston can be disabled in the system to further reduce resource usage.

Adding Flutter Configuration to defconfig:

Add the following content to the configuration file: buildroot/configs/rockchip_ok3568_defconfig:

# Flutter embedder - flutter-pi (DRM-GBM direct rendering)
BR2_PACKAGE_FLUTTER_PI=y
BR2_PACKAGE_FLUTTER_PI_CHARSET_CONVERTER_PLUGIN=y
BR2_PACKAGE_FLUTTER_PI_RAW_KEYBOARD_PLUGIN=y
BR2_PACKAGE_FLUTTER_PI_TEXT_INPUT_PLUGIN=y
# Flutter example apps for testing （Total six examples）
BR2_PACKAGE_FLUTTER_PACKAGES=y
BR2_PACKAGE_FLUTTER_ADAPTIVE_SCAFFOLD_EXAMPLE=y
BR2_PACKAGE_FLUTTER_ANIMATIONS_EXAMPLE=y
BR2_PACKAGE_FLUTTER_GO_ROUTER_EXAMPLE=y
BR2_PACKAGE_FLUTTER_IMAGE_EXAMPLE=y
BR2_PACKAGE_FLUTTER_MARKDOWN_EXAMPLE=y
BR2_PACKAGE_FLUTTER_RFW_LOCAL_EXAMPLE=y

Explanation of each configuration function:

Once configured, you can proceed with the standard Buildroot compilation process.

5. Key Compilation Output Artifacts Explained

After the Buildroot compilation is complete, the core Flutter components will be deployed to the corresponding paths on the target system. The details are as follows:

6. Flutter cross-compilation Toolchain Built Using Buildroot

6.1 Toolchain List

6.2 Three-Step Method for Cross-Compilation

Step 1: flutter build bundle host/share/flutter/sdk/bin/flutter
Dart source code + pub dependencies——> kernel_blob.bin + flutter_assets
(lib/main.dart)
Step 2: frontend_server_aot host/.../dart-sdk/bin/snapshots/frontend_server_aot.dart.snapshot
kernel_blob.bin ——> app.dill (AOT compatible kernel)
Operating method: dartaotruntime frontend_server_aot.dart.snapshot
--sdk-root flutter_patched_sdk/ --target=flutter --aot --tfa
--packages .dart_tool/package_config.json
--output-dill app.dill lib/main.dart
Step 3: flutter_gen_snapshot host/bin/flutter_gen_snapshot
app.dill ——> libapp.so (ELF, ARM aarch64)
Operating method: flutter_gen_snapshot --deterministic
--snapshot_kind=app-aot-elf --elf=libapp.so app.dill

6.3 Key point: Flutter_gen_snapshot is a Cross-compiler

file flutter_gen_snapshot
→ ELF x86-64 ← run on x64
The resulting libapp.so:
→ ELF ARM aarch64 ← run on ARM64

This was generated from the source code when compiling the Flutter engine using Buildroot; it utilises an internal ARM64 simulator to directly generate ARM64 instructions on an x64 system.

7. Analysis of Solution Advantages and Disadvantages

7.1 Solution Advantages

GPU Hardware Acceleration, Excellent Rendering Performance

The Flutter engine is natively and deeply adapted for OpenGL ES / Vulkan graphics APIs, designed to achieve 60fps or even 120fps smooth animations. The embedded embedder creates a graphics context via EGL and GBM, directly calls the GPU for rendering, and ultimately outputs the image via DRM/KMS. Complex scaling, rotation, 3D flips, and particle effects can all run smoothly.

Compared to Web/Electron solutions on the RK3568 platform, Direct-to-DRM Flutter eliminates browser overhead, offering interface responsiveness and animation detail close to the smartphone experience.

High Development Efficiency, Mature Ecosystem

Supports Hot Reload, allowing developers to see changes in less than a second after code modification, significantly shortening the lengthy cross-compilation and flashing cycles of traditional embedded development. Can directly reuse the vast ecosystem of Dart plugins from the mobile domain.

Declarative UI, Modern Interface Development Experience

Compared to imperative frameworks like Qt Widgets or C-based LVGL, Flutter's declarative UI paradigm (similar to React/Vue) aligns better with modern front-end development habits, enabling rapid implementation of complex animations and sophisticated commercial interfaces with stronger visual appeal.

High Cross-Platform Consistency

Renders pixel-by-pixel using its own engine, ensuring nearly identical visual performance across embedded boards, mobile apps, web, and desktop with the same codebase, significantly reducing multi-platform adaptation costs.

7.2 Solution Limitations

High System Resource Consumption (Higher Hardware Threshold): Flutter's Runtime (Dart VM + C++ engine) is relatively large. Even a simple HelloWorld application may require tens of megabytes of memory and disk space. It cannot run on MCUs (microcontrollers). It typically requires a Cortex-A series processor, at least 256MB/512MB of available RAM, and hardware GPU support.

Slower Startup Time: Compared to C/C++ native applications (e.g., LVGL or optimized Qt) that can start in a few hundred milliseconds, Flutter requires initialization of the Dart VM and loading of the rendering engine during cold start, which often takes 1-2 seconds or more. This necessitates additional optimization in scenarios demanding “instant-on display” (e.g., automotive rear-view cameras).

Official Embedded Support is Still Maturing: Although Linux desktop is a first-class citizen officially, community support and chip vendors largely drive the adaptation layer for “pure embedded Linux without a desktop environment” embedders (e.g., flutter-pi). Access to hardware decoding and external interfaces (GPIO, I2C) may not be as out-of-the-box as with Qt on certain specific hardware.

7.3 Effect Demonstration

The above details the complete adaptation solution and practical steps for Flutter in a Buildroot environment. From solution selection and kernel configuration to troubleshooting and cross-compilation, the entire workflow can be directly implemented and reused. If your project requires smooth graphical interactions on an embedded Linux platform, this can serve as a solid foundation for quick prototyping and validation.

Adapting MIPI CSI cameras on Rockchip platforms typically requires coordinated efforts across multiple components: Sensor driver validation, I²C communication, MIPI D-PHY/CSI-2 link setup, RKCIF, RKISP, IQ file configuration, and V4L2/GStreamer application-layer verification. This article uses the RK3588 platform as the primary example, combining actual device tree code, debugging commands, and common issues to outline a reusable camera adaptation workflow.

1. Why Camera Adaptation Requires More Than Just the Device Tree

In practical projects, whether a camera “outputs images normally” depends not on a single node but on the entire Camera Pipeline. A typical pipeline includes:

  Sensor Driver / I²C Communication
  ↓
  MIPI D-PHY / CSI-2 Receiver
  ↓
  RKCIF (Video Capture)
  ↓
  RKISP (RAW Image Processing, Optional)
  ↓
  RKAIQ / IQ Parameters
  ↓
  V4L2, GStreamer, or Android Camera HAL

Errors in any of these stages may lead to issues such as:

• Camera not being detected

• No video node generated

• Image capture failure

• Color abnormalities

  Multi-camera synchronization failures Therefore, before starting adaptation, it is crucial to verify documentation and plan the pipeline thoroughly before proceeding with device tree and driver modifications.

2. Preliminary Research: Check if the Sensor Has Existing Adaptation Foundations

When working with a new sensor, first verify whether Rockchip or the current SDK already supports it. Existing drivers and IQ files can significantly reduce adaptation effort.

2.1 Locating the Sensor Driver in the Kernel Source

MIPI CSI cameras are typically configured via I²C register writes. Start by searching in the following directories:

  drivers/media/
  drivers/media/i2c/

For example, to locate drivers for OV13850 or OV13855:

  find drivers/media -iname "*ov13850*"
  grep -R "ov13850" drivers/media/
  
  find drivers/media -iname "*ov13855*"
  grep -R "ov13855" drivers/media/

If a driver exists, update the device tree configuration; otherwise, you need to port or develop a new driver based on the sensor's datasheet and existing Rockchip sensor templates.

2.2 Checking Platform Support List and Historical Projects

If the driver is not found directly in the kernel, check Rockchip’s camera support list, internal project records, or issue tracking systems. Such resources typically provide: Such resources typically provide:

• Whether the sensor has been debugged on the target SoC.

• Compatible driver and kernel versions.

• Availability of IQ/JSON files.

• Reference device tree configurations and known limitations.

If no relevant records exist in official or internal documentation, search in open-source communities like GitHub. However, third-party drivers often require re-evaluating register interfaces, V4L2 subdevice APIs, kernel API changes, and RK Camera Framework compatibility—they cannot be assumed directly usable.

3. Confirming Data Format: Must the Sensor Pass Through RKISP?

Whether RKISP is required depends primarily on the sensor’s output data format. Before adaptation, confirm via datasheet, driver register tables, or existing solutions whether the output is RAW, RGB, or YUV.

3.1 RAW Sensor

If the sensor outputs RAW Bayer data, it generally requires RKISP for processing such as:

• Demosaicing

• Auto Exposure (AE)

• Auto White Balance (AWB)

• Auto Focus (AF)

• Noise reduction

• Color correction Typical pipeline:

RAW Sensor → MIPI D-PHY → MIPI CSI2 → RKCIF → RKISP → Video Node

In such cases, besides the driver and device tree, IQ files matching the sensor, lens, and RKAIQ version are mandatory.

3.2 YUV Sensor or Video Decoder Chip

If the device itself already outputs YUV data—for example, certain YUV sensors, AV video decoder chips or bridge chips—it is possible to capture the YUV data directly from the RKCIF node without passing through the RKISP:

YUV Sensor / Decoder → MIPI CSI2 → RKCIF → Video Node

Note: Bypassing RKISP does not mean skipping MIPI D-PHY, CSI-2, and RKCIF configurations—only RAW image processing and IQ parameter stages are omitted.

4. Key Parameters to Confirm from the Sensor Datasheet

4.1 External Input Clock

Most MIPI CSI sensors use a 24 MHz external reference clock, but this is not universal. For example, TP2855 specifies “Single 27MHz clock operation,” meaning it requires a 27 MHz clock input.

Ensure clock-frequency in the device tree or CRU clock output matches both the chip requirements and driver register configurations.

4.2 MIPI Lane Count

Confirm whether the sensor supports 1, 2, or 4 lanes (or multiple combinations). The data-lanes in the device tree must match:

• The actual lanes connected in the hardware schematic.

• The lane count configured in the sensor’s registers.

• The mode used by the D-PHY and CSI-2 controller.

Example for 2 lanes:

data-lanes = <1 2>;

4.3 Maximum Resolution, Frame Rate, and Bandwidth

Confirm the chip’s maximum resolution, frame rate, and bit depth. For instance, TP2855 supports multiple HD-TVI/analog HD video decoding channels and outputs via a MIPI CSI-2 compliant transmitter, supporting up to 4 lanes.

For instance, TP2855 supports multiple HD-TVI/analog HD video decoding channels and outputs via a MIPI CSI-2 compliant transmitter, supporting up to 4 lanes.

4.4 I²C Address and Hardware Pull-up/Pull-down

Some sensors or decoder chips support multiple I²C slave addresses via address selection pins, enabling multiple identical devices on the same I²C bus. Example: TP2855

The combination of SAD0 and SAD1 pin levels determines multiple I²C addresses.

Figure 1: Example of I²C address selection via SAD0/SAD1 pull-up/pull-down.

In Linux device trees, the reg field typically uses the 7-bit I²C address. During debugging, distinguish between the 7-bit address in datasheets and the 8-bit address (which includes R/W bits).

  cam1_ov13850: cam1_ov13850@10 {
  reg = <0x10>;
  };

5. ISP Architecture for Different Rockchip Platforms

Different SoCs may use varying ISP architectures and Camera Frameworks. Refer to the SDK docs directory for platform-specific Camera/ISP driver guides. Common platform-ISP mappings:

Taking the RK3588 as an example, you should focus on referring to the corresponding version of the Rockchip Camera Driver Guide to confirm the D-PHY, CSI2, VICAP/RKCIF, ISP virtual node, and multi-camera resource allocation methods. Different SoCs may have variations in device tree node naming and connection methods; directly copying configurations across platforms is not recommended.

6. RK3588 Multi-Camera Resource and Link Planning

Before configuring the device tree, you should first clarify which D-PHY group, CSI2 controller, RKCIF, and ISP virtual node each camera path uses. The schematic for RK3588 multi-camera support in the source materials is as follows.

Figure 2: RK3588 Multi-Sensor Hardware Resource and Software Link Schematic

6.1 D-PHY Full Mode and Split Mode

The D-PHY resources on the RK3588 can be configured in Full Mode or Split Mode based on the camera’s Lane count. Full Mode is typically used for a single 4-Lane camera.

Split Mode allows the same PHY group to be split into two 2-Lane paths.

Block Diagram Description

Figure 3: RK3588 D-PHY Full/Split Mode Description

Figure 4: RK3588 Multi-Camera Configuration Notes

When configuring, pay attention to the following principles:

• Full Mode and its corresponding Split Mode cannot be enabled simultaneously.

• Each physical PHY should be connected to a matching CSI2 controller.

• Each MIPI CSI2 output should continue to be connected to an independent RKCIF/VICAP node.

• When multiple RAW cameras feed into the ISP, appropriate ISP virtual nodes must be allocated for each link.

• The data-lanes property in the device tree must be consistent with the Full/Split mode and the actual hardware connections.

6.2 RKCIF/VICAP and ISP Connection Methods

On the RK3588, camera data typically enters VICAP/RKCIF first and is then connected to the ISP via interfaces like sditf. The connection methods can be divided into:

• Direct Mode: VICAP data is sent directly to the ISP without passing through DDR, resulting in lower latency. However, this is usually suitable for linear mode and is not ideal for HDR.

• DDR Mode: RKCIF first writes data to DDR, and then the ISP reads it. This mode is suitable for scenarios requiring buffering or HDR.

If only one ISP virtual node is configured, it is typically used in linear mode. If multiple related virtual nodes are configured, you need to combine this with the sensor’s HDR output method and the driver documentation.

6.3 Hardware Interface Example

Figure 5: Multi-Camera Interface Hardware Connection Example

7. Device Tree Configuration: Building a Complete Media Pipeline

The following uses the OV13850 on the RK3588 platform as an example, preserving the main device tree configurations from the source materials. In actual projects, modifications should be made based on the board schematic, kernel driver, and camera model, including the I²C bus, GPIO, clocks, Lane count, and node numbering.

Note: The code below is intended to demonstrate the complete link and key configuration items. The compatible strings, GPIO polarity, clock names, and node numbers must align with the actual BSP and driver.

7.1 External Fixed Clocks and RKCIF Base Nodes

  / {
  ext_cam_clk: external-camera-clock {
  compatible = "fixed-clock";
  clock-frequency = <24000000>;
  clock-output-names = "CLK_CAMERA_24MHZ";
  #clock-cells = <0>;
  };
  };
  
  &rkcif {
  status = "okay";
  };
  
  &rkcif_mmu {
  status = "okay";
  };

ext_cam_clk defines a fixed 24 MHz clock. The sensor node references it through the clocks and clock-names properties. rkcif and rkcif_mmu enable the camera capture module and its corresponding IOMMU, respectively.

7.2 Enabling MIPI DCPHY, ISP, and ISP MMU

  &mipi_dcphy0 {
  status = "okay";
  };
  
  &rkisp0 {
  status = "okay";
  };
  
  &isp0_mmu {
  status = "okay";
  };

mipi_dcphy0 corresponds to the physical layer resource used by the camera. rkisp0 and isp0_mmu are used for RAW image processing. If the sensor outputs YUV directly and does not require ISP processing, the ISP-related connections can be omitted according to the actual link, but the RKCIF configuration must still be set up normally.

7.3 I²C Bus, Lens Driver, and Sensor Node

  &i2c3 {
  status = "okay";
  clock-frequency = <400000>;
  
  vm149c_0: vm149c@0c {
  compatible = "silicon touch,vm149c";
  status = "okay";
  reg = <0x0c>;
  rockchip,camera-module-index = <0>;
  rockchip,camera-module-facing = "back";
  };
  
  cam1_ov13850: cam1_ov13850@10 {
  compatible = "ovti,ov13850";
  status = "okay";
  reg = <0x10>;
  
  clocks = <&ext_cam_clk>;
  clock-names = "xvclk";
  
  pwdn-gpios = <&extio EXTIO_GPIO_P01 GPIO_ACTIVE_HIGH>;
  reset-gpios = <&extio EXTIO_GPIO_P00 GPIO_ACTIVE_HIGH>;
  
  rockchip,camera-module-index = <0>;
  rockchip,camera-module-facing = "back";
  rockchip,camera-module-name = "forlinx";
  rockchip,camera-module-lens-name = "default";
  lens-focus = <&vm149c_0>;
  
  port {
  cam1_ov13850_out: endpoint {
  remote-endpoint = <&mipi_in_0_ucam1>;
  data-lanes = <1 2>;
  };
  };
  };
  };

Key Configuration Items Explanation:

• reg: The 7-bit I²C address of the sensor.

• clocks / clock-names: The sensor’s external input clock. The name must match the one used by devm_clk_get() in the driver.

• pwdn-gpios / reset-gpios: Power-down and reset control. The GPIO polarity must be verified against the schematic and the driver’s timing requirements.

• rockchip,camera-module-index: Camera module index. This value must not be arbitrarily duplicated when multiple cameras are used.

• camera-module-name / lens-name: Used not only for module information but also to match the IQ (Image Quality) file name.

• data-lanes: Indicates the enabled MIPI data lanes (in this example, two lanes).

• remote-endpoint: Used to connect the sensor’s output port to the D-PHY input port.

7.4 DCPHY Input/Output Ports

  &csi2_dcphy0 {
  status = "okay";
  
  ports {
  #address-cells = <1>;
  #size-cells = <0>;
  
  port@0 {
  reg = <0>;
  #address-cells = <1>;
  #size-cells = <0>;
  
  mipi_in_0_ucam1: endpoint@1 {
  reg = <1>;
  remote-endpoint = <&cam1_ov13850_out>;
  data-lanes = <1 2>;
  };
  };
  
  port@1 {
  reg = <1>;
  #address-cells = <1>;
  #size-cells = <0>;
  
  csidcphy0_out: endpoint@0 {
  reg = <0>;
  remote-endpoint = <&mipi0_csi2_input>;
  };
  };
  };
  };

Port@0 on the DCPHY is used as an input and is connected to the sensor; port@1 is used as an output and is connected to the MIPI CSI2 controller. The data lanes on both the Sensor and DCPHY sides should be aligned.

7.5 MIPI CSI2 Controller

  &mipi0_csi2 {
  status = "okay";
  
  ports {
  #address-cells = <1>;
  #size-cells = <0>;
  
  port@0 {
  reg = <0>;
  #address-cells = <1>;
  #size-cells = <0>;
  
  mipi0_csi2_input: endpoint@1 {
  reg = <1>;
  remote-endpoint = <&csidcphy0_out>;
  };
  };
  
  port@1 {
  reg = <1>;
  #address-cells = <1>;
  #size-cells = <0>;
  
  mipi0_csi2_output: endpoint@0 {
  reg = <0>;
  remote-endpoint = <&cif_mipi_lvds0>;
  };
  };
  };
  };

The input of the MIPI CSI2 node is connected to the DCPHY, whilst the output is connected to the RKCIF MIPI/LVDS acquisition node.

7.6 RKCIF to ISP Virtual Node

  &rkcif_mipi_lvds {
  status = "okay";
  
  port {
  cif_mipi_lvds0: endpoint {
  remote-endpoint = <&mipi0_csi2_output>;
  };
  };
  };
  
  &rkcif_mipi_lvds_sditf {
  status = "okay";
  
  port {
  mipi_lvds_sditf: endpoint {
  remote-endpoint = <&isp0_vir0>;
  };
  };
  };
  
  &rkisp0_vir0 {
  status = "okay";
  
  port {
  #address-cells = <1>;
  #size-cells = <0>;
  
  isp0_vir0: endpoint@0 {
  reg = <0>;
  remote-endpoint = <&mipi_lvds_sditf>;
  };
  };
  };

rkcif_mipi_lvds receives the MIPI CSI2 output; rkcif_mipi_lvds_sditf feeds the acquired data into the ISP; rkisp0_vir0 corresponds to a virtual channel of the ISP. In multi-camera configurations, appropriate RKCIF and ISP virtual nodes must be allocated to the different links.

7.7 Checking Whether the Endpoints Are Connected in Pairs

The “remote-endpoint” entries in the device tree must appear in pairs. For example:

  cam1_ov13850_out ↔︎ mipi_in_0_ucam1
  csidcphy0_out ↔︎ mipi0_csi2_input
  mipi0_csi2_output ↔︎ cif_mipi_lvds0
  mipi_lvds_sditf ↔︎ isp0_vir0

If the name of any endpoint pair is incorrect, the node is not enabled, or it is connected to a mismatched controller, the Media Controller topology may become incomplete, ultimately leading to the failure of video node generation or capture.

8. RK3588 Camera Clock Output Configuration

In addition to fixed clock nodes, the RK3588 can also output camera clocks through the CRU and corresponding GPIO multiplexing functions. The source material lists multiple sets of available MIPI camera clock outputs.

Figure 6 RK3588 Camera Clock Output Pins and Optional Frequencies

8.1 Pinctrl Configuration Example

  /* arch/arm64/boot/dts/rockchip/rk3588s-pinctrl.dtsi */
  
  mipi {
  /omit-if-no-ref/
  mipim0_camera0_clk: mipim0-camera0-clk {
  rockchip,pins =
  /* mipim0_camera0_clk */
  <4 RK_PB1 1 &pcfg_pull_none>;
  };
  
  /omit-if-no-ref/
  mipim0_camera1_clk: mipim0-camera1-clk {
  rockchip,pins =
  /* mipim0_camera1_clk */
  <1 RK_PB6 2 &pcfg_pull_none>;
  };
  
  /omit-if-no-ref/
  mipim0_camera2_clk: mipim0-camera2-clk {
  rockchip,pins =
  /* mipim0_camera2_clk */
  <1 RK_PB7 2 &pcfg_pull_none>;
  };
  
  /omit-if-no-ref/
  mipim0_camera3_clk: mipim0-camera3-clk {
  rockchip,pins =
  /* mipim0_camera3_clk */
  <1 RK_PD6 2 &pcfg_pull_none>;
  };
  
  /omit-if-no-ref/
  mipim0_camera4_clk: mipim0-camera4-clk {
  rockchip,pins =
  /* mipim0_camera4_clk */
  <1 RK_PD7 2 &pcfg_pull_none>;
  };
  };

8.2 Sensor Node Referencing CRU Clock

  clocks = <&cru CLK_MIPI_CAMARAOUT_M1>;
  clock-names = "xvclk";
  
  pinctrl-names = "default";
  pinctrl-0 = <&mipim0_camera1_clk>;

The value of clock-names must exactly match the definition in the driver. Even if multiple sensors use 24 MHz, the clock name retrieved by the driver may differ.

9. ISP IQ Files and the RKAIQ Service

Once RAW sensor data enters the RKISP, image quality and 3A functionalities depend on a matching IQ file. If the device tree configuration is correct but the IQ file is missing or version mismatched, the following phenomena may occur: only RAW capture is possible, abnormal colors, abnormal exposure, or even failure of multiple ISP virtual nodes to work simultaneously.

9.1 IQ File Naming Convention

The common IQ file path in the filesystem is:

/etc/iqfiles/

The IQ filename is typically composed of the sensor model, camera-module-name, and camera-module-lens-name. The corresponding OV13850 IQ file can be named:

  rockchip,camera-module-name = "forlinx";
  rockchip,camera-module-lens-name = "default";

The corresponding OV13850 IQ file can be named:

ov13850_forlinx_default.json

Only when the name matches the module information can the RKAIQ automatically load the correct configuration file.

9.2 Checking rkaiq_3A_server

ps -ef | grep 3A

Normally, a process similar to the following should be visible:

  /usr/bin/rkaiq_3A_server
  logger -t rkaiq_3A

If rkaiq_3A_server is not running properly, check the IQ filename, file format, RKAIQ library version, device tree module information, and whether the ISP node is complete.

9.3 Querying the RKAIQ Library Version

strings /usr/lib/librkaiq.so | grep -w AIQ

The output will show version information similar to AIQ v6.0x8.0. IQ file structures may differ across RKAIQ library versions; old version JSON files may not be directly usable with a new SDK.

For instance, IQ files for the same sensor may have compatibility differences between platforms like Linux 5.10.66, Linux 5.10.209, or Linux 6.1, requiring the use of the default IQ file from the corresponding version for regeneration or debugging.

10. Obtaining and Adjusting IQ Files

10.1 Finding IQ Files in the SDK

Search primarily in the following directory:

external/camera_engine_rkaiq/iqfiles/

If the SDK does not contain files for the target sensor, you can further consult Rockchip’s support list, other projects, or IQ resources under the same RKAIQ version.

10.2 Using RKISP Tuner

Rockchip provides the RKISP Tuner tool for configuring and adjusting IQ parameters. Before use, confirm the following:

• Target SoC platform.

• RKAIQ Library Version.

• Default IQ file for the corresponding version.

• Sensor operating mode, resolution, and frame rate.

Figure 7 RKISP Tuner Platform and Version Selection Interface

If the version is selected incorrectly, even if the JSON can be read, issues such as incompatible parameter items, service startup failure, or abnormal image effects may occur.

10.3 Limitations of Manual JSON Modification

In the absence of Tuner or a corresponding default IQ file, you can directly edit the JSON, but this method is only suitable for verifying a small number of parameters. If the root cause is version mismatch, comparing against a properly loadable IQ file and migrating parameters item-by-item is required, which is labor-intensive and not recommended as a regular solution.

Typical symptom: Under the same device tree configuration, when calling different virtual nodes of the same RKISP, the first node captures successfully, but the second node reports an error. This type of issue may not be a device tree connection error but rather RKAIQ not functioning properly or missing a matching IQ file.

Figure 8 RK3562 Multi-Camera Link and RKAIQ Configuration Issue Example

11. Common V4L2 and Media Controller Debugging Commands

11.1 Listing All Video Devices

v4l2-ctl --list-devices

Used to confirm registered camera, RKCIF, and ISP video nodes in the system.

11.2 Listing Formats, Resolutions, and Frame Rates Supported by a Node

v4l2-ctl --list-formats-ext -d /dev/video33

If the target format or resolution does not appear in the enumeration results, continue checking the sensor driver mode table, RKCIF/ISP output formats, and Android HAL enumeration requirements.

11.3 Viewing Media Pipeline

media-ctl -p -d /dev/media0

This command prints the entities, pads, and link relationships between Sensor, D-PHY, CSI2, RKCIF, and ISP. It is one of the most important tools for troubleshooting endpoint configuration issues.

11.4 Viewing Each Video Node Name

grep -H '' /sys/class/video4linux/video*/name

Since /dev/videoX numbers can change with configuration, do not judge node purpose solely by number; also check the node name in sysfs.

11.5 Capturing a Single NV12 Frame

  v4l2-ctl -d /dev/video0 \
  --set-fmt-video=width=1920,height=1080,pixelformat=NV12 \
  --stream-mmap=3 \
  --stream-skip=3 \
  --stream-to=./cif.yuv \
  --stream-count=1 \
  --stream-poll

Parameter description:

• --set-fmt-video: Sets width, height, and pixel format.

• --stream-mmap=3: Uses MMAP method to request buffers.

• --stream-skip=3: Skips the first 3 frames to reduce impact from unstable frames during startup.

• --stream-to: Saves data to a file.

• --stream-count=1: Captures 1 frame.

12. Using GStreamer for Fixed-Point Preview

In a graphical system, GStreamer can be used to output a V4L2 node’s signal to the screen.

12.1 Wayland render-rectangle Method

  gst-launch-1.0 v4l2src device=/dev/video0 ! \
  video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
  waylandsink async=false "render-rectangle=<0,0,500,300>"

The four parameters of render-rectangle are: window origin X coordinate, origin Y coordinate, window width, and window height. This example displays a 500×300 preview window in the top-left corner of the screen.

12.2 Using Window Position Parameters

  gst-launch-1.0 v4l2src device=/dev/video0 ! \
  video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! \
  waylandsink window-width=500 window-height=300 \
  window-x=0 window-y=0 async=false

Parameter support may vary across different system images and plugin versions; test accordingly based on the actual environment.

13. Differences Between Buildroot, Ubuntu, and Android Systems

13.1 Buildroot

The Buildroot system is typically more suitable for low-level debugging, allowing separate kernel compilation and image updates. For older RK3588 Linux 5.10.66 kernels, RKCIF nodes might not work correctly with V4L2 capture commands. The source material provides a fix example for the selection logic.

  diff --git a/drivers/media/platform/rockchip/cif/capture.c b/drivers/media/platform/rockchip/cif/capture.c
  index ce479ff27..c0236fc28 100644
  --- a/drivers/media/platform/rockchip/cif/capture.c
  +++ b/drivers/media/platform/rockchip/cif/capture.c
  @@ -5181,9 +5181,7 @@ static int rkcif_g_selection(struct file *file,
  s->r.width = stream->pixm.width;
  s->r.height = stream->pixm.height;
  }
  - }
  -
  - if (s->target == V4L2_SEL_TGT_CROP) {
  + } else if (s->target == V4L2_SEL_TGT_CROP) {
  if (stream->crop_mask & (CROP_SRC_USR_MASK |
  CROP_SRC_SENSOR_MASK)) {
  s->r = stream->crop[CROP_SRC_ACT];
  } else {
  @@ -5192,6 +5190,8 @@ static int rkcif_g_selection(struct file *file,
  s->r.width = stream->pixm.width;
  s->r.height = stream->pixm.height;
  }
  + } else {
  + goto err;
  }
  
  return ret;

This patch adjusts the judgment logic of rkcif_g_selection() for different selection targets. Higher kernel versions typically already include similar fixes, so before actual use, the current BSP code should be compared to avoid redundant modifications.

13.2 Ubuntu

Ubuntu systems require attention to the differences between the X11 and Wayland display frameworks. Taking the RK3588 Ubuntu 22 environment as an example, if using the Wayland desktop for preview, the following steps are generally required:

1. Set the screen to single display mode.

2. Log in with a regular desktop account.

3. Set the DISPLAY environment variable in the terminal.

4. Run the GStreamer preview command.

export DISPLAY=:0

If the environment variable, desktop session, or display framework is mismatched, issues such as windows failing to display or color abnormalities may occur.

13.3 Android Camera HAL

Android not only requires the underlying V4L2 node to be available but also demands that the enumeration methods for resolution and frame rate are correctly recognized by the Camera HAL. In older driver versions, it may be necessary to change continuous enumeration to discrete enumeration. Example code from the source material is as follows:

  diff --git a/kernel/drivers/media/platform/rockchip/cif/capture.c b/kernel/drivers/media/platform/rockchip/cif/capture.c
  index 6c0aa7d8b3..62f89e5b89 100644
  --- a/kernel/drivers/media/platform/rockchip/cif/capture.c
  +++ b/kernel/drivers/media/platform/rockchip/cif/capture.c
  @@ -3452,10 +3452,16 @@ static int rkcif_try_fmt_vid_cap_mplane(struct file *file, void *fh,
  return 0;
  }
  
  +#define USB_CAMERA_TEST
  +
  static int rkcif_enum_framesizes(struct file *file, void *prov,
  struct v4l2_frmsizeenum *fsize)
  {
  +#ifdef USB_CAMERA_TEST
  + struct v4l2_frmsize_discrete *d = &fsize->discrete;
  +#else
  struct v4l2_frmsize_stepwise *s = &fsize->stepwise;
  +#endif
  struct rkcif_stream *stream = video_drvdata(file);
  struct rkcif_device *dev = stream->cifdev;
  struct v4l2_rect input_rect;
  @@ -3474,6 +3480,11 @@ static int rkcif_enum_framesizes(struct file *file, void *prov,
  get_input_fmt(dev->terminal_sensor.sd,
  &input_rect, stream->id, &vc);
  
  +#ifdef USB_CAMERA_TEST
  + fsize->type = V4L2_FRMSIZE_TYPE_DISCRETE;
  + d->width = input_rect.width;
  + d->height = input_rect.height;
  +#else
  fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
  s->min_width = CIF_MIN_WIDTH;
  s->min_height = CIF_MIN_HEIGHT;
  s->max_width = input_rect.width;
  s->max_height = input_rect.height;
  s->step_width = OUTPUT_STEP_WISE;
  s->step_height = OUTPUT_STEP_WISE;
  -
  +#endif
  return 0;
  }
  
  @@ -3512,6 +3523,11 @@ static int rkcif_enum_frameintervals(struct file *file, void *fh,
  fi.interval.denominator = 30;
  }
  
  +#ifdef USB_CAMERA_TEST
  + fival->type = V4L2_FRMIVAL_TYPE_DISCRETE;
  + fival->discrete.numerator = fi.interval.numerator;
  + fival->discrete.denominator = fi.interval.denominator;
  +#else
  fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
  fival->stepwise.step.numerator = 1;
  fival->stepwise.step.denominator = 1;
  fival->stepwise.max.numerator = 1;
  fival->stepwise.max.denominator = 1;
  fival->stepwise.min.numerator = fi.interval.numerator;
  fival->stepwise.min.denominator = fi.interval.denominator;
  -
  +#endif
  return 0;
  }

This modification allows RKCIF to report the current input resolution and frame rate as discrete values, making them easier for the Android Camera HAL to recognize.

In newer kernels and Android BSPs, Rockchip has migrated such compatibility logic to device tree properties. For example, in RK3576 Linux 6.1.75 Android 14, you can add the following under the RKCIF node:

  &rkcif {
  status = "okay";
  rockchip,android-usb-camerahal-enable;
  };

Therefore, before modifying the driver, check whether the current BSP already supports this device tree property.

14. Common Issues and Troubleshooting Sequence

For camera issues, it is recommended to troubleshoot in the following order:

  Hardware Power Supply and Clock → I²C → Driver Probe → Media Pipeline → RKCIF Image Capture → ISP/RKAIQ → Application Display.

14.1 Confirming Hardware Prerequisites

• Ensure all power supply voltages for the Sensor are correct.

• Verify default levels and release sequence for PWDN and RESET.

• Verify default levels and release sequence for PWDN and RESET.

• Check MIPI Lane order, count, and impedance design against the schematic.

• Check MIPI Lane order, count, and impedance design against the schematic.

14.2 Confirming Driver and Media Pipeline

  dmesg | grep -i camera
  dmesg | grep -i sensor
  dmesg | grep -i ov13850
  
  media-ctl -p -d /dev/media0
  v4l2-ctl --list-devices

If the Sensor has probed but the Media topology lacks a complete link from the Sensor to RKCIF/ISP, prioritize checking the device tree endpoint rather than modifying the application directly.

14.3 RKCIF vs. ISP Issues

If RAW/YUV data can be captured from the RKCIF node but the ISP output node is abnormal, the issue typically lies with the ISP virtual node, IQ file, or RKAIQ service. If RKCIF itself cannot capture images, return to troubleshooting the Sensor, D-PHY, CSI2, and kernel driver layers.

15. Recommendations for Adaptation Work

• Prefer Sensors already supported by Rockchip with existing driver and IQ files in the current BSP.

• Before formally modifying code, map out the complete pipeline: Sensor → PHY → CSI2 → RKCIF → ISP.

• After modifying the device tree, validate the underlying layer using media-ctl and v4l2-ctl before relying on upper-layer applications.

• For multi-camera setups, plan D-PHY Full/Split, Lane count, and ISP virtual nodes in advance.

• Ensure IQ files match the Sensor, lens, operating mode, and RKAIQ version.

• Before copying patches or JSON files across kernel versions, confirm whether the current BSP already includes the corresponding features.

Conclusion

Adapting MIPI CSI cameras on Rockchip platforms essentially involves establishing a complete imaging pipeline from the hardware Sensor to the application layer. The device tree describes the connections between hardware modules. The Sensor driver initializes the device and outputs the correct data stream. RKCIF handles image capture.RKISP and RKAIQ manage RAW image processing and 3A. V4L2, GStreamer, or Android Camera HAL are used for final validation and application. During debugging, the most effective approach is not to repeatedly modify the device tree through trial and error, but to verify the pipeline step by step:

• Confirm power supply, clock, and I²C.

• Validate Sensor probe and Media Pipeline.

• Verify RKCIF raw data.

  Inspect ISP, IQ files, and upper-layer display. This layered method significantly improves the efficiency of camera adaptation and multi-camera issue localization.

Appendix: Quick Reference of Common Commands

  # List video devices
  v4l2-ctl --list-devices
  
  # List formats supported by a node
  v4l2-ctl --list-formats-ext -d /dev/video33
  
  # View Media topology
  media-ctl -p -d /dev/media0
  
  # List video node names
  grep -H '' /sys/class/video4linux/video*/name
  
  # Check 3A service
  ps -ef | grep 3A
  
  # Query RKAIQ library version
  strings /usr/lib/librkaiq.so | grep -w AIQ
  
  # Set Ubuntu display environment
  export DISPLAY=:0

1. Screen Selection

Take OK3568-C as example: The OK3568-C supports five mainstream display interfaces by default: MIPI, EDP, RGB, LVDS and HDMI,which are all pre-configured by default, and users can switch between them during the U-Boot phase.

At start-up, press Ctrl+C to enter the U-Boot command line:

  Hit key to stop autoboot('CTRL+C'): 0
  ---------------------------------------------
  0:Exit to console
  1:Reboot
  2:Display type
  ---------------------------------------------

Press 2 to enter the display type selection screen:

  ---------------------------------------------
  hdmi==>hdmi mipi_edp==>mipi lvds_rgb=>lvds
  Select display
  0:Exit
  1:hdmi display hdmi
  2:mipi_edp display mipi
  3:lvds_rgb display lvds
  ---------------------------------------------

• 1 corresponds to the HDMI screen display
• 2 corresponds to MIPI and EDP displays; the default display is MIPI
• 3 corresponds to LVDS and RGB displays; the default display is LVDS

At this point, we can enter a number to switch the screen display; for example, we can enter 2

  Writing to mmc(0)... done
  ---------------------------------------------
  hdmi==>hdmi mipi_edp==>edp lvds_rgb=>lvds
  Select display
  0:Exit
  1:hdmi display hdmi
  2:mipi_edp display edp
  3:lvds_rgb display lvds
  ---------------------------------------------

At this point, the display changes from ''mipi_edp display mipi'' to ''mipi_edp display edp'', indicating that the switch from MIPI to EDP has been completed. If you enter 2 again, you can turn off the display:

  Writing to mmc(0)... done
  ---------------------------------------------
  hdmi==>hdmi mipi_edp==>off lvds_rgb=>lvds
  Select display
  0:Exit
  1:hdmi display hdmi
  2:mipi_edp display off
  3:lvds_rgb display lvds
  ---------------------------------------------

The same applies to the HDMI and LVDS_RGB options.

If you wish to retain the current settings, enter 0 to exit the screen selection menu, then enter 1 to restart.

  Writing to mmc(0)... done
  ---------------------------------------------
  hdmi==>hdmi mipi_edp==>mipi lvds_rgb=>off
  Select display
  0:Exit
  1:hdmi display hdmi
  2:mipi_edp display mipi
  3:lvds_rgb display off
  --------------------------------------------- 
/*Enter 0 exit*/ ---------------------------------------------
  0:Exit to console
  1:Reboot
  2:Display type
  --------------------------------------------- 
/*Press 1 to restart*/ DDR V1.18 f366f69a7d typ 23/07/17-15:48:58
  In
  LP4/4x derate en, other dram:2x trefi
  SRX
  ddrconfig:15
  DDR4, 324MHz
  BW=32 Col=10 Bk=4 BG=2 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
  tdqss: cs0 dqs0: 120ps, dqs1: 72ps, dqs2: -48ps, dqs3: -24ps,

The configuration will take effect after a restart.

2. Adjust the screen settings

Reference Document:

User documentation source code /docs/cn/Common/DISPLAY/Rockchip_DRM_Panel_Porting_Guide

Display Parameters

Display parameter acquisition and modification

These display parameters have corresponding entries in the device tree framework. After obtaining the parameters according to their sources, filling them into the appropriate locations completes the display setup.

Below describes the locations for entering parameters for different interfaces and important considerations when dealing with various interfaces.

2.1 RGB Interface

2.1.1 Modifying the device tree

The device tree file path corresponding to OK3568-C:

OK3568_Linux_fs/kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi

Open the device tree file, locate the ''rgb-panel'' node, and modify the display parameters in accordance with the relevant screen manual. The following are the default display parameters in the source code:

  rgb-panel {
  compatible = "simple-panel";
  backlight = <&lvds_backlight>;
  power-supply = <&vcc3v3_lcd2_n>;
  bus-format = <MEDIA_BUS_FMT_RGB888_1X7X4_SPWG>;
  
  display-timings {
  native-mode = <&timing1>;
  
  timing1: timing1 {
  clock-frequency = <51200000>;
  hactive = <1024>;
  vactive = <600>;
  hfront-porch = <160>;
  hback-porch = <320>;
  hsync-len = <1>;
  vback-porch = <35>;
  vfront-porch = <12>;
  vsync-len = <1>;
  hsync-active = <0>;
  vsync-active = <0>;
  de-active = <1>;
  pixelclk-active = <1>;
  };
  };

Once you have modified the device tree, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing. (Click on the blue text to follow the link)

2.1.2 RGB Signal Format Switching:

The RGB signal formats are defined in the kernel source file ''kernel/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c''; the available formats are RGB565, RGB666 and RGB888.

  static const struct drm_bus_format_enum_list drm_bus_format_enum_list[] = {
  { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
  { MEDIA_BUS_FMT_RGB565_1X16, "RGB565_1X16" },
  { MEDIA_BUS_FMT_RGB666_1X18, "RGB666_1X18" },
  ......
  { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, "RGB888_1X7X4_SPWG" },
  { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, "RGB888_1X7X4_JEIDA" },
  ......
  };

The above content shows an excerpt from the code.

Once you have modified the source code, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing. (Click on the blue text to follow the link)

2.1.3 Viewing Screen Settings

After updating the image, you can run the following command in the command line to view the display parameters:

  root@OK3568-buildroot:~# cat /sys/kernel/debug/dri/0/summary
  Video Port2: ACTIVE
  Connector: 
DPI-1 bus_format[1011]: 
RGB888_1X7X4_SPWG overlay_mode[0] output_mode[0] color_space[0], eotf:0 
Display mode: 1024x600p52
    clk[51200] real_clk[51200] type[48] flag[a]
    H: 1024 1184 1185 1505
    V: 600 612 613 648 Smart0-win0: ACTIVE
  win_id: 0
  format: XR24 little-endian (0x34325258) SDR[0] color_space[0] glb_alpha[0xff]
  rotate: xmirror: 0 ymirror: 0 rotate_90: 0 rotate_270: 0
  csc: y2r[0] r2y[0] csc mode[0]
  zpos: 0
  src: pos[0, 0] rect[1024 x 600]
  dst: pos[0, 0] rect[1024 x 600]
  buf[0]: addr: 0x000000007e2b8000 pitch: 4096 offset: 0

Connector: DPI-1: The screen node is named DPI-1;

bus_format[1011]: RGB888_1X7X4_SPWG: The RGB format uses RGB888_1X7X4_SPWG.

Display mode: 1024x600p52: Screen resolution is 1024x600;

clk[51200]: The display clock is 51.2 MHz;

• Here is a specific explanation of the H and V parameters.

  hfp（Horizontal front shoulder） = hsync_start - hdisplay = 1184 - 1024 = 160
  hsync（Horizontal synchronisation）= hsync_end - hsync_start = 1185 - 1184 = 1
  hbp（Horizontal rear shoulder） = htotal - hsync_end = 1505 - 1185 = 320

  vfp（Vertical front shoulder） = vsync_start - vdisplay = 640 - 600 = 40
  vsync（Vertical synchronisation）= vsync_end - vsync_start = 644 - 640 = 4
  vbp（Vertical rear shoulder） = vtotal - vsync_end = 684 - 644 = 40

2.1.4 RGB Interface

List of Parallel RGB Interface Formats for the RK3568

2.2 LVDS Interface

2.2.1 Modifying the device tree

The device tree file path corresponding to OK3568-C:

OK3568_Linux_fs/kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi

Open the device tree file, locate the ''panel'' node, and modify the display parameters in accordance with the relevant screen manual. The following are the default display parameters in the source code:

  panel {
  compatible = "simple-panel";
  backlight = <&lvds_backlight>;
  power-supply = <&vcc3v3_lcd2_n>;
  enable-delay-ms = <60>;
  prepare-delay-ms = <60>;
  unprepare-delay-ms = <60>;
  disable-delay-ms = <60>;
  bus-format = <MEDIA_BUS_FMT_RGB888_1X7X4_SPWG>;
  width-mm = <152>;
  height-mm = <91>;
  
  display-timings {
  native-mode = <&timing0>;
  
  timing0: timing0 {
  clock-frequency = <71000000>;
  hactive = <1280>;
  vactive = <800>;
  hback-porch = <10>;
  hfront-porch = <140>;
  vback-porch = <1>;
  vfront-porch = <2>;
  hsync-len = <10>;
  vsync-len = <20>;
  hsync-active = <0>;
  vsync-active = <1>;
  de-active = <1>;
  pixelclk-active = <0>;
  };
  };

Once you have modified the device tree, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilationand 6.System Flashing. (Click on the blue text to follow the link)

2.2.2 LVDS Signal Format Switching:

The LVDS signal format is defined in the kernel source file ''kernel/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c''.

  static const struct drm_bus_format_enum_list drm_bus_format_enum_list[] = {
  ......
  { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, "RGB666_1X7X3_SPWG" },
  ......
  { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, "RGB888_1X7X4_SPWG" },
  { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, "RGB888_1X7X4_JEIDA" },
  ......
  };

In the specifications, ''1X7X3'' refers to three pairs of data cables; these are generally known as screens with a ''single six'' or ''double six'' signal format;

In the specifications, ''1X7X4'' refers to four pairs of data cables; this is generally known as a screen with a ''single-eight'' or ''double-eight'' signal format.

Once you have modified the source code, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing. (Click on the blue text to follow the link)

2.2.3 Switching Between Single- and dual-channel LVDS Signals

Modify the &lvds node in the device tree located at kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi. By default, lvds is single-channel; adding the ''dual-channel;'' statement changes it to dual-channel:

  &lvds { 
dual-channel; status = "disabled";
  phys = <&video_phy0>;
  phy-names = "phy";
  
  ports {
  port@1 {
  reg = <1>;
  
  lvds_out_panel: endpoint {
  remote-endpoint = <&panel_in_lvds>;
  };
  };
  };
  };

Once you have modified the device tree, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing.

2.2.4 Viewing Screen Settings

After updating the image, you can run the following command in the command line to view the display parameters:

  root@OK3568-buildroot:~# cat /sys/kernel/debug/dri/0/summary
  Video Port2: ACTIVE
  Connector: 
LVDS-1 bus_format[1011]: 
RGB888_1X7X4_SPWG overlay_mode[0] output_mode[0] color_space[0], eotf:0 
Display mode: 1280x800p60
    clk[71000] real_clk[71000] type[48] flag[6]
    H: 1280 1420 1430 1440
    V: 800 802 822 823 Smart0-win0: ACTIVE
  win_id: 0
  format: XR24 little-endian (0x34325258) SDR[0] color_space[0] glb_alpha[0xff]
  rotate: xmirror: 0 ymirror: 0 rotate_90: 0 rotate_270: 0
  csc: y2r[0] r2y[0] csc mode[0]
  zpos: 0
  src: pos[0, 0] rect[1280 x 800]
  dst: pos[0, 0] rect[1280 x 800]
  buf[0]: addr: 0x000000007e830000 pitch: 5120 offset: 0

Connector: LVDS-1: The screen node is named LVDS-1;

bus_format[1011]: RGB888_1X7X4_SPWG: The LVDS format uses RGB888_1X7X4_SPWG.

Display mode: 1280x800p60: Screen resolution is 1280x800p60;

clk[71000]: The display clock is 71 MHz;

• Here is a specific explanation of the H and V parameters.

  hfp（Horizontal front shoulder） = hsync_start - hdisplay = 1420 - 1280 = 140
  hsync（Horizontal synchronisation）= hsync_end - hsync_start = 1430 - 1420 = 10
  hbp（Horizontal rear shoulder） = htotal - hsync_end = 1440 - 1430 = 10

  vfp（Vertical front shoulder） = vsync_start - vdisplay = 802 - 800 = 40
  vsync（Vertical synchronisation）= vsync_end - vsync_start = 822 - 802 = 20
  vbp（Vertical rear shoulder） = vtotal - vsync_end = 823 - 822 = 40

2.3 MIPI Interface

2.3.1 Modifying the device tree

The device tree file path corresponding to OK3568-C:

OK3568_Linux_fs/kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi

Open the device tree file, locate the ''& dsi1'' node, and modify the display parameters in accordance with the relevant screen manual. The following are the default display parameters in the source code:

  &dsi1 {
  status = "disabled";
  //rockchip,lane-rate = <1000>;
  dsi1_panel: panel@0 {
  status = "okay";
  compatible = "simple-panel-dsi";
  reg = <0>;
  reset-delay-ms = <60>;
  enable-delay-ms = <60>;
  prepare-delay-ms = <60>;
  unprepare-delay-ms = <60>;
  disable-delay-ms = <60>;
  dsi,flags = <(MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET)>;
  dsi,format = <MIPI_DSI_FMT_RGB888>;
  dsi,lanes = <4>;
  panel-init-sequence = [
  ];
  
  panel-exit-sequence = [
  ];
  
  panel-width-mm = <68>;
  panel-height-mm = <121>;
  backlight = <&dsi1_backlight>;
  enable-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>;
  
  display-timings {
  native-mode = <&panel7_1024x600>;
  panel7_1024x600: timings {
  hback-porch = <40>;
  hfront-porch = <40>;
  hactive = <1024>;
  hsync-len = <48>;
  vback-porch = <40>;
  vfront-porch = <40>;
  vactive = <600>;
  vsync-len = <4>;
  clock-frequency = <43000000>;
  vsync-active = <0>;
  hsync-active = <0>;
  de-active = <0>;
  pixelclk-active = <0>;
  };

Once you have modified the device tree, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing. (Click on the blue text to follow the link)

2.3.2 MIPI Initialization Sequence

2.3.2.1 MIPI Initialization Sequence Acquisition

Screen manufacturers generally provide an initialization sequence for MIPI screens, similar to the example below.

We need to convert this sequence into the format reserved in Rockchip’s display subsystem.

2.3.2.2 Initialization Sequence Conversion Rules

Here is an explanation of the first sequence.

39 00 04 ff 98 81 03

There are the following three types of commands:

e.g.: 05 78 01 11

Indicates a delay of 0x78=120ms before issuing command 11.

You can achieve the effect shown in the image below using VS Code or Notepad++; the shortcut is Shift+Alt+mouse click.

2.3.3 Switching Between Single- and dual-channel MIPI Signals

Locate the &dsi1 node in the device tree at kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi

dsi,lanes = 4 A value greater than 4 for this attribute in the device tree indicates dual-channel mode for the MIPI signal; this can be modified directly to match the display’s lane requirements.

  &dsi1 {
  status = "disabled";
  //rockchip,lane-rate = <1000>;
  dsi1_panel: panel@0 {
  status = "okay";
  compatible = "simple-panel-dsi";
  reg = <0>;
  reset-delay-ms = <60>;
  enable-delay-ms = <60>;
  prepare-delay-ms = <60>;
  unprepare-delay-ms = <60>;
  disable-delay-ms = <60>;
  dsi,flags = <(MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
  MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET)>;
  dsi,format = <MIPI_DSI_FMT_RGB888>; 
dsi,lanes = <4>; 

Note: During actual screen debugging, the provided screen documentation may not be entirely accurate. For example, when the screen displays abnormally (color distortion, misalignment), the normal approach is to adjust the pixel format and fine-tune the clock. Consider an alternative perspective: during initial debugging, if the screen’s clock frequency is uncertain or its range is unknown, but the display is basically functional, then the clock setting is likely approximately correct. If the screen is displaying incorrectly and adjusting the settings in the usual way does not produce a noticeable improvement, you may wish to adjust the screen’s frame rate—for example, reducing it from 60 fps to 30 fps, or to another frame rate. The main idea is to make a broad adjustment to the clock frequency.

2.4 HDMI and EDP

HDMI and eDP automatically retrieve the EDID, so there is no need to manually adjust the display settings.

2.4.1 Setting a Fixed Screen Resolution for HDMI

1. Select HDMI display during the U-Boot phase

2. Edit the driver file ''kernel/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c'', locate the function ''dw_hdmi_connector_get_modes'', and add ''edid = NULL;''

  static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
  {
  struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
  connector);
  struct hdr_static_metadata *metedata =
  &connector->hdr_sink_metadata.hdmi_type1;
  struct edid *edid;
  struct drm_display_mode *mode;
  struct drm_display_info *info = &connector->display_info;
  void *data = hdmi->plat_data->phy_data;
  int i, ret = 0;
  
  memset(metedata, 0, sizeof(*metedata));
  edid = dw_hdmi_get_edid(hdmi, connector); 
edid = NULL; if (edid) {
  int vic = 0;
  
  dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
  edid->width_cm, edid->height_cm);
  drm_connector_update_edid_property(connector, edid);
  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
  ret = drm_add_edid_modes(connector, edid);
  if (hdmi->plat_data->get_color_changed)
  hdmi->plat_data->get_yuv422_format(connector, edid);
  if (hdmi->plat_data->get_colorimetry)
  hdmi->plat_data->get_colorimetry(data, edid);
  
  list_for_each_entry(mode, &connector->probed_modes, head) {
  vic = drm_match_cea_mode(mode);
  
  if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_NONE) {
  if (vic >= 93 && vic <= 95)
  mode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
  else if (vic == 98)
  mode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
  }
  }
  ......

3. Continue editing the driver file ''kernel/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c''. Locate the ''dw_hdmi_default_modes[]'' array, which defines a number of resolutions. Check whether it contains the resolution you require; retain only the resolution you need and comment out the rest. If the required resolution is not found in this array, you can look for it in the file ''kernel/drivers/gpu/drm/drm_edid.c'' and then add it to ''dw-hdmi.c''. Here, we will use retaining the 1280x720 resolution as an example:

  static const struct drm_display_mode dw_hdmi_default_modes[] = {
  /* 4 - 1280x720@60Hz 16:9 */ 
{ DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
    1430, 1650, 0, 720, 725, 730, 750, 0,
    DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
    .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 16 - 1920x1080@60Hz 16:9 */
  /* { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
  */ .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
  /* 31 - 1920x1080@50Hz 16:9 */
  /* { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
  .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
  */ /* 19 - 1280x720@50Hz 16:9 */
  /* { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
  1760, 1980, 0, 720, 725, 730, 750, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
  .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
  */ /* 17 - 720x576@50Hz 4:3 */
  /* { DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 27000, 720, 732,
  796, 864, 0, 576, 581, 586, 625, 0,
  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
  .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
  */ /* 2 - 720x480@60Hz 4:3 */
  /* { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
  798, 858, 0, 480, 489, 495, 525, 0,
  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
  .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
  */};

4. Edit the device tree file ''kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi'' and add the following timing to the ''&route_hdmi'' section:

  &route_hdmi {
  status = "disabled";
  connect = <&vp0_out_hdmi>; 
force-output;
    
    force_timing {
    clock-frequency = <74250000>;
    hactive = <1280>;
    vactive = <720>;
    hback-porch = <220>;
    hfront-porch = <110>;
    vback-porch = <20>;
    vfront-porch = <5>;
    hsync-len = <40>;
    vsync-len = <5>;
    hsync-active = <1>;
    vsync-active = <1>;
    de-active = <0>;
    pixelclk-active = <0>;
    
    }; };

Note: The parameters in the device tree must match those in the driver’s ''default_modes''; otherwise, the logo will not display correctly.

Once you have modified the source code, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilation and 6.System Flashing. (Click on the blue text to follow the link)

2.4.2 Setting a Fixed Screen Resolution for EDP

Refer to document: rockchip_drm_integration_helper-zh.pdf

It can be found in the following path in the source code (this was found in the source code for Linux 4.19.206):

Modify the device tree file ''kernel/arch/arm64/boot/dts/rockchip/OK3568-C-common.dtsi'' to use the ''display-timings''structure, and directly enter the EDP display’s timing parameters into the DTS file (adjust the display parameters yourself according to the display manual):

  edp-panel {
  compatible = "simple-panel";
  prepare-delay-ms = <120>;
  enable-delay-ms = <120>;
  unprepare-delay-ms = <120>;
  disable-delay-ms = <120>;
  backlight = <&edp_backlight>;
  enable-gpios = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>; 
bus-format = <MEDIA_BUS_FMT_RGB888_1X24>;
    
    display-timings {
    native-mode = <&edp_timing1>;
    
    edp_timing1: timing1 {
    clock-frequency = <65000000>;
    hactive = <1024>;
    vactive = <768>;
    hback-porch = <160>;
    hfront-porch = <136>;
    vback-porch = <29>;
    vfront-porch = <6>;
    hsync-len = <24>;
    vsync-len = <3>;
    hsync-active = <0>;
    vsync-active = <1>;
    de-active = <1>;
    pixelclk-active = <0>;
    };
    };  port {
  panel_in_edp: endpoint {
  remote-endpoint = <&edp_out_panel>;
  };
  };
  };

Once you have modified the device tree, save the configuration, recompile the kernel to generate the boot.img image, and flash the image onto the board.

For specific instructions, please refer to the 4.Related Code Compilationand 6.System Flashing. (Click on the blue text to follow the link)

After the update, when selecting the screen to display ''edp'' during the U-Boot phase, the following output can be seen:

After starting up, you can see that the screen settings have taken effect:

In embedded product development, switching the main processor typically necessitates redesigning the carrier board, repeating prototype verification, and potentially facing risks from single-supplier dependency or discontinuation. These pain points not only extend development cycles but also significantly increase the hidden costs of product line iteration.

To address these challenges, Forlinx Embedded has introduced the UP4 Universal SoM Package Standard. By unifying hardware physical specifications and pin interfaces, UP4 establishes a compatible ecosystem across various chip platforms. With five SoMs ready for mass production and covering various architectures and compute tiers, the UP4 Standard offers a flexible, reliable, and hardware foundation secure for long-term supply chains in embedded device development.

What is UP4 Packaging?

UP4 stands for Universal Package. It is a standardized hardware architecture for SoMs introduced by Forlinx Embedded, featuring:

• Unified Dimensions: 40mm×40mm, suitable for compact internal layout

• Standardized Pins: LCC +LGA design, totaling 487 pins. The pin definitions and electrical layout are fully standardized.

• Cross-Compatibility: Different UP4 SoMs with various main controllers can be swapped on the same carrier board without requiring redesign, re-prototyping, or re-sampling.

UP4 Package Advantages:

Hardware Design Reusability to Improve R&D Efficiency

A single carrier board design can work with multiple SoMs that vary in performance levels. When you want to upgrade the computing power of a product or make improvements, you only need to replace the SoM. This approach eliminates the lengthy processes of redesigning, prototyping, and debugging the carrier board, which significantly reduces research and development costs as well as time to market.

Multi-Vendor Coverage for More Controllable Supply Chains

It covers three mainstream chip platforms: NXP, Rockchip, and Allwinner. In the event of a single chip supply shortage, it enables a rapid switch to an alternative solution within the same package with zero hardware modifications. This effectively hedges against risks of chip shortages and price hikes, ensuring stability in mass production.

Industrial-Grade Quality with Ultra-Long Supply Guarantees

All SoMs in the series have passed rigorous industrial environment testing, operating stably in a wide temperature range of -40°C to +85°C. Backed by original manufacturers’ long-term supply plans, they are guaranteed a 10 to 15-year stable supply cycle, perfectly matching the operational and maintenance needs of long-lifecycle products in industrial and automotive fields.

Comprehensive Development Support for Efficient Implementation

Each product is accompanied by a full suite of development materials, including carrier board schematics, underlying source code, compilation manuals, debugging examples, and more. Coupled with professional technical support, this lowers the barrier to software adaptation and helps customers bring products to market quickly.

Five Products for Comprehensive, Precise Scenario Coverage

Currently, the Forlinx Embedded UP4 series includes five established products that thoroughly meet the needs for lightweight control, edge AI, industrial HMI, and high-computing systems.

FET-MX9352-UP4 SoM

Core Configuration: Dual-core ARM Cortex-A55 + Cortex-M33 real-time core, integrated with a 0.5 TOPS NPU.

Key Features: Native support for TSN and CAN-FD industrial buses, with industrial-grade wide-temperature characteristics.

Target Scenarios: Vehicle gateways, industrial Ethernet devices, lightweight edge AI terminals.

FET3562J-UP4 SoM

Core Configuration: Quad-core ARM Cortex-A55 @ 2.0GHz with a built-in 1 TOPS NPU.

Key Features: Abundant peripheral interfaces and outstanding cost-effectiveness, optimized for BOM cost.

Target Scenarios: Industrial controllers, IoT gateways, edge data acquisition devices.

FET3568J-UP4 SoM

Core Configuration: High-performance platform with quad-core ARM Cortex-A55, supporting triple independent display and 4K encoding/decoding.

Key Features: Provides high-speed expansion interfaces like PCIe and SATA, delivering excellent multimedia and data throughput capabilities.

Target Scenarios: Industrial HMI, edge computing gateways, video surveillance, digital signage.

FET527N-UP4 SoM

Core Configuration: Octa-core ARM Cortex-A55 architecture, integrated with a 2 TOPS NPU and a powerful Graphics Processing Unit (GPU).

Key Features: Supports multi-channel 4K display and multi-task parallel processing, meeting high-performance edge computing requirements.

Target Scenarios: Industrial robots, high-end industrial PCs, smart cockpits.

FET536-UP4 SoM

Core Configuration: Heterogeneous architecture featuring Quad-core ARM Cortex-A55 + RISC-V security MCU, integrated with a 2 TOPS NPU.

Key Features: Incorporates hardware-level security encryption mechanisms and multiple industrial control interfaces, providing extremely high system real-time performance and security.

Target Scenarios: EV charging piles, rail transportation, control systems with high-security requirements.

From reducing costs through hardware reuse and mitigating supply chain risks via multi-vendor strategies to comprehensive product coverage across all scenarios, Forlinx Embedded’s UP4 Universal Package is providing a standardized and sustainable hardware solution for embedded device development. In the future, Forlinx Embedded will continue to expand the UP4 ecosystem, assisting global clients in building more competitive end-products with resilient supply chains.

Integrating a new SDIO Wi-Fi module into the Android system requires more than just kernel device recognition and driver loading. It involves a comprehensive process including firmware pre-provisioning, Vendor DLKM module packaging, Wi-Fi HAL configuration, wpa_supplicant startup parameter setup, and Android’s automatic recognition logic. Incomplete configuration at any step can lead to issues such as ''SDIO device detected but no wlan0 interface appears, '' ''driver module pre-provisioned but not auto-loaded, '' or ''Wi-Fi can be enabled but fails to connect. ''

This document outlines the complete adaptation process using the OK3576-C platform (Android 14, Linux 6.1.75) and the FCS950U module as a case study. The FCS950U corresponds to the UNISOC UWE5622 solution in this project, utilizing the SDIO hardware interface and employing sprdwl/unisoc-related Wi-Fi driver components.

• Target Platform: OK3576-C, Android 14, Linux 6.1.75

• Wireless Module: FCS950U (Corresponds to UWE5622)

• Hardware Interface: SDIO, 4-bit bus

• Core Tasks: Driver source code porting, Device Tree configuration, firmware & HAL integration, auto-loading setup, functional verification, and log analysis.

1. Wi-Fi Recognition and Loading Flow on Android Platform

On the Rockchip Android platform, the Wi-Fi module generally goes through four stages from power-up to becoming operational: ‘hardware scan’, ‘device identification’, ‘driver loading’ and ‘user-space service launch’. Understanding this flow is crucial for quickly pinpointing whether an issue lies at the hardware, kernel, or Android framework level.

1. Hardware Scan: The system powers the Wi-Fi module upon boot, and the SDIO controller automatically scans for devices on the bus.

2. Device Identification: When the user turns on Wi-Fi, the system reads uevent information from directories like /sys/bus/sdio, /sys/bus/usb, or PCI/PCIe device paths.

3. Driver Loading: The system extracts the device VID/PID or corresponding identifier from the uevent and loads the matching Wi-Fi kernel module (.ko).

4. Service Initialization: After Wi-Fi type identification, Android selects the appropriate wpa_supplicant parameters and Wi-Fi HAL based on the chipset, ultimately creating the wlan0 interface and initiating the connection process.

Therefore, during debugging, problems can be categorized into three layers:

• Layer 1: Can the SDIO bus scan and detect the device?

• Layer 2: Can the kernel driver and firmware load normally, and does the wlan0 interface get created?

• Layer 3: Do the Android Wi-Fi HAL, wpa_supplicant, and Framework correctly recognize and invoke the driver?

2. Driver Source Code Porting

2.1 Pre-provisioning FCS950U Driver Source Code

Copy the UNISOC driver directory from the FCS950U driver source package to the external/wifi_driver directory in the Android source tree. The source material path is as follows:

FCS950U\uwe562x-main\uwe562x-main\Code\Wi-Fi\drivers\unisoc
↓
Android Source Code Path: external/wifi_driver/unisoc

After source code pre-provisioning, the kernel build system will compile the corresponding WCN BSP, Wi-Fi, and Bluetooth modules from the external/wifi_driver directory.

2.2 Adapting cfg80211 Interface for Linux 6.1.75

Due to changes in cfg80211 interface parameters across different kernel versions, the original driver’s calls to cfg80211_ch_switch_notify() need adjustment to match the Linux 6.1.75 interface. The following two files were modified in this project:

File 1: cfg80211.c

diff --git a/external/wifi_driver/unisoc/unisocwifi/sc2355/cfg80211.c \
b/external/wifi_driver/unisoc/unisocwifi/sc2355/cfg80211.c
@@ -1298,9 +1298,9 @@ static int sprdwl_cfg80211_start_ap(struct wiphy *wiphy,
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(6, 0, 0)
- cfg80211_ch_switch_notify(vif->ndev, &chandef, 0);
+ cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#else
- cfg80211_ch_switch_notify(vif->ndev, &chandef);
+ cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#endif

This modification is located in the SoftAP channel switch notification flow and is used to adapt the function prototype of the current kernel.

File 2: cmdevt.c

diff --git a/external/wifi_driver/unisoc/unisocwifi/sc2355/cmdevt.c \
b/external/wifi_driver/unisoc/unisocwifi/sc2355/cmdevt.c
@@ -3592,9 +3592,9 @@ void sprdwl_event_chan_changed(struct sprdwl_vif *vif,
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0)
cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(6, 0, 0)
- cfg80211_ch_switch_notify(vif->ndev, &chandef, 0);
+ cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#else
- cfg80211_ch_switch_notify(vif->ndev, &chandef);
+ cfg80211_ch_switch_notify(vif->ndev, &chandef, 0, 0);
#endif

The corresponding section describes the cfg80211 notification flow after the firmware reports a channel change event. If the number of parameters does not match, a compilation error will typically occur directly during the build phase.

2.3 Google GKI-Related Configuration

Android 14 source code enables Google GKI-related mechanisms by default. Since GKI restricts external drivers from calling certain unexported kernel symbols—such as functions like kernel_read—Unisoc drivers provide the CONFIG_WCN_GKI macro to switch between compatible implementations.

• In external/wifi_driver/unisoc/unisocwcn/Kbuild, enable the CONFIG_WCN_GKI macro.

• In external/wifi_driver/unisoc/unisocwifi/Kbuild, check for the macro with the same name.

• When enabling the GKI-compatible path, turn off the READ_INI_FILP macro to avoid using restricted file-reading interfaces.

The project documentation indicates that even if the current project does not actually use a GKI kernel, enabling CONFIG_WCN_GKI did not affect compilation. However, during actual porting, it is still recommended to verify this based on the current kernel configuration and driver version.

2.4 Configuring the Main Control Platform, Chip Model, and Hardware Interface

The driver package supports multiple main control platforms and various Unisoc WCN chips. Before porting, confirm the following three key variables in external/wifi_driver/unisoc/Makefile:

Source code path: external/wifi_driver/unisoc/Makefile

# AP platform
# unisoc/qcom/rk/mtk/aw/aml
export COUSTOM_PLATFORM ?= rk
# UNISOC WCN chip ID
# umw2651/umw2652/umw2653
# uwe5621/uwe5622/uwe5623
export UNISOC_WCN_CHIP_ID ?= uwe5622
# UNISOC WCN hardware interface type
# sdio/usb/pcie
export UNISOC_WCN_HW_TYPE ?= sdio
EXTRA_CFLAGS += -Wno-unused-variable
EXTRA_CFLAGS += -D__linux__
obj-y += unisocwcn/
obj-y += unisocwifi/
obj-y += unisocbt/
ifeq ($(UNISOC_WCN_CHIP_ID), umw2652)
obj-y += unisocfm/
endif

Specifically, unisocwcn is responsible for the WCN low-level bus, firmware download and power management; unisocwifi is responsible for the Wi-Fi network interface; and unisocbt is responsible for Bluetooth-related functions.

2.5 Integrating the Unisoc Driver into external/wifi_driver Compilation

Source code path: external/wifi_driver/Makefile

diff --git a/external/wifi_driver/Makefile b/external/wifi_driver/Makefile
@@ -23,6 +23,10 @@ CONFIG_EA6621Q=y
export CONFIG_EA6621Q
obj-$(CONFIG_EA6621Q) += ea6621q/
+CONFIG_UNISOC=y
+export CONFIG_UNISOC
+obj-$(CONFIG_UNISOC) += unisoc/

After adding CONFIG_UNISOC, the relevant Wi-Fi/BT kernel modules will be built when compiling the kernel. When building the Android image, these modules will then be pre-installed into the vendor_dlkm.img. The corresponding directory in the running system is /vendor_dlkm/lib/modules.

3. Pre-installation Process of Wi-Fi Kernel Modules in Android 14

Android 14 places vendor kernel modules in the Vendor DLKM (Dynamically Loadable Kernel Modules) partition. Understanding the path from the compiled artifacts to vendor_dlkm.img helps troubleshoot issues like ''the driver is compiled but the .ko file is missing from the image. ''

3.1 Enabling the Vendor DLKM Image

# device/rockchip/common/build/rockchip/DynamicPartitions.mk
PRODUCT_BUILD_VENDOR_DLKM_IMAGE := true
TARGET_COPY_OUT_VENDOR_DLKM := vendor_dlkm
BOARD_VENDOR_DLKMIMAGE_FILE_SYSTEM_TYPE := $(ROCKCHIP_READ_ONLY_FILE_SYSTEM_TYPE)

Once BOARD_VENDOR_DLKMIMAGE_FILE_SYSTEM_TYPE has been defined, the Android build system will enable BOARD_USES_VENDOR_DLKMIMAGE and generate vendor_dlkm.img.

# build/make/core/board_config.mk
BOARD_USES_VENDOR_DLKMIMAGE :=
ifdef BOARD_PREBUILT_VENDOR_DLKMIMAGE
BOARD_USES_VENDOR_DLKMIMAGE := true
endif
ifdef BOARD_VENDOR_DLKMIMAGE_FILE_SYSTEM_TYPE
BOARD_USES_VENDOR_DLKMIMAGE := true
endif

3.2 Module Directory Compatibility Soft Links

After enabling the Vendor DLKM partition, the system creates a compatibility access path from /vendor/lib/modules to /vendor_dlkm/lib/modules. Applications and underlying components should prioritize using the module path defined by the Android build system.

# build/make/core/Makefile（key logic）
ifdef BOARD_USES_VENDOR_DLKMIMAGE
_vendor_dlkm_lib_modules_symlink := \
$(call create-partition-compat-symlink,\
$(TARGET_OUT_VENDOR)/lib/modules,\
/vendor_dlkm/lib/modules,\
vendor_dlkm.img)
INTERNAL_VENDORIMAGE_FILES += $(_vendor_dlkm_lib_modules_symlink)
ALL_DEFAULT_INSTALLED_MODULES += $(_vendor_dlkm_lib_modules_symlink)
endif

3.3 external/wifi_driver Entering BOARD_VENDOR_KERNEL_MODULES

# vendor/rockchip/common/wifi/wifi.mk
HAVE_EXT_WIFI_KO_FILE := $(shell test -d \
$(TOPDIR)external/wifi_driver/ && echo yes)
ifeq ($(HAVE_EXT_WIFI_KO_FILE),yes)
EXT_WIFI_KO_FILES := $(shell find \
$(TOPDIR)external/wifi_driver -name "*.ko" -type f)
BOARD_VENDOR_KERNEL_MODULES += \
$(foreach file, $(EXT_WIFI_KO_FILES), $(file))
# external/wifi_driver First, remove modules of the same name that may exist in the kernel directoryEXT_WIFI_DRIVER := $(shell find \
$(TOPDIR)external/wifi_driver -name "*.ko" -type f | \
awk -F "wifi_driver/" '{print $$2}' | awk -F "/" '{print $$1}')
$(shell for line in $(EXT_WIFI_DRIVER); do \
rm $(TOPDIR)$(PRODUCT_KERNEL_PATH)/drivers/net/wireless/rockchip_wlan/$$line/*.ko \
> /dev/null 2>&1; done)
$(shell for line in $(EXT_WIFI_DRIVER); do \
rm $(TOPDIR)$(PRODUCT_KERNEL_PATH)/drivers/net/wireless/rockchip_wlan/rkwifi/$$line/*.ko \
> /dev/null 2>&1; done)
endif

wifi.mk will search for all generated .ko files under external/wifi_driver and add them to BOARD_VENDOR_KERNEL_MODULES. Subsequently, the Android build system copies the modules into the Vendor DLKM image through processes such as build-image-kernel-modules and copy-many-files.

4. Hardware Connections and Device Tree Configuration

The FCS950U communicates with the host via 4-bit SDIO, while utilizing independent module enable, reset, and wake-up pins. During adaptation, it’s essential to simultaneously verify the SDIO bus, power sequencing, GPIO polarity, and the specific module variant.

4.1 SDIO Controller Configuration

&sdio {
max-frequency = <200000000>;
no-sd;
no-mmc;
bus-width = <4>;
disable-wp;
cap-sd-highspeed;
cap-sdio-irq;
keep-power-in-suspend;
mmc-pwrseq = <&sdio_pwrseq>;
non-removable;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc1m0_bus4
&sdmmc1m0_clk
&sdmmc1m0_cmd>;
sd-uhs-sdr104;
status = "okay";
};

Key Configuration Notes:

• bus-width = <4>: Uses a 4-bit SDIO data bus.

• non-removable: Indicates the module is an onboard device, not handled as a removable SD card.

• keep-power-in-suspend: Maintains power to the module during system suspend to support wake-up functionality.

• cap-sdio-irq: Declares controller support for SDIO interrupts.

• mmc-pwrseq: Binds to the module’s power-on/reset sequencing node.

• sd-uhs-sdr104: Enables SDR104 capability. Actual frequency and stability are still affected by PCB layout, module characteristics, and controller configuration.

4.2 Unisoc Marlin3 and Wi-Fi Device Node Configuration

sprd_marlin3: sprd-marlin3 {
compatible = "unisoc,marlin3";
sprd,btwf-file-name = "/vendor/etc/firmware/wcnmodem.bin";
sdhci-name = <&sdio>;
keep-power-on;
// adma-tx;
// adma-rx;
// blksz-512;
// sdio-irq-type = "data-irq";
// sdio-irq-gpio = "esmd3";
m2-wakeup-ap-gpios = <&gpio1 RK_PD4 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_LOW>;
enable-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
m2-to-ap-irq-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
status = "okay";
};
sprd-wlan {
compatible = "sprd,sc2355-wifi";
status = "okay";
};

4.3 SDIO Power Sequencing Node

sdio_pwrseq: sdio-pwrseq {
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
pinctrl-0 = <&wifi_poweren_gpio>;
post-power-on-delay-ms = <200>;
reset-gpios = <&gpio1 RK_PC7 GPIO_ACTIVE_LOW>;
status = "okay";
};

During project debugging, initially the reset pin was configured in the reset-gpios of the sprd_marlin3 node, and the system could not scan the SDIO card. Once the reset operation was reassigned to be performed by sdio-pwrseq, the module was recognised correctly. This phenomenon indicates that the timing stage of the reset operation affects SDIO enumeration.

As seen from the timing diagram, a reasonable sequential relationship must be maintained among VIO, VBAT, CHIP_EN, and RESET_N. Project experience shows that the interval between power-up of RESET and VIO/VBAT should not be too long; otherwise, the module may not have entered an enumerable state when the host controller begins scanning.

4.4 Differences in Wake-up Pins for FCS950U Different OC Models

Different OC models of the module may use different physical pins as WLAN_WAKE. FCS950UAAMD corresponds to WLAN_WAKE1 (Pin 6).
FCS950UABMD corresponds to WLAN_WAKE2 (Pin 13).

4.5 Verifying Whether the SDIO Device Has Been Enumerated

ok3576_c:/sys/bus/sdio/devices/mmc2:8800:1 # cat uevent
DRIVER=sdiohal
SDIO_CLASS=00
SDIO_ID=0000:0000
SDIO_REVISION=0.0
MODALIAS=sdio:c00v0000d0000

The SDIO_ID of the FCS950U in this project is 0000:0000. Subsequently, the Android auto-detection logic will use this identifier to match SPRDWL devices. Therefore, this ID needs to be added to supported_wifi_devices.

5. Android 14 System Integration

5.1 Preloading Wi-Fi Firmware and Board-Level Configuration Files

Copy the corresponding wcnmodem.bin and wifi_board_config.ini for the FCS950U from the driver package to the Rockchip common Wi-Fi firmware directory.

Source Directory:
FCS950U\uwe562x-main\uwe562x-main\Code\Wi-Fi\fw\FCS950U
Target Directory:
vendor/rockchip/common/wifi/firmware

Among these:
wcnmodem.bin is the WCN/CP2 firmware.
wifi_board_config.ini is used to load board-level radio frequency and Wi-Fi configurations. The sprd,btwf-file-name in the device tree must match the final firmware path in the image.

5.2 Adding Unisoc wpa_supplicant Startup Parameters

diff --git a/device/rockchip/common/wpa_config.txt \
b/device/rockchip/common/wpa_config.txt
@@ -48,3 +48,9 @@
+[sprdwl]
+/vendor/bin/hw/wpa_supplicant
+-O/data/vendor/wifi/wpa/sockets
+-puse_p2p_group_interface=1
+-g@android:wpa_wlan0

When the system identifies the sprdwl driver, it will use this configuration to launch wpa_supplicant. The parameters specify the control socket directory, P2P group interface policy, and global control interface, respectively.

5.3 Adding libwifi-hal-sprd to the public Wi-Fi HAL

diff --git a/hardware/rockchip/wifi/wifi_hal/common/Android.mk \
b/hardware/rockchip/wifi/wifi_hal/common/Android.mk
@@ -25,5 +25,6 @@ LOCAL_REQUIRED_MODULES := \
libwifi-hal-rtk \
libwifi-hal-bes \
libwifi-hal-aic \
- libwifi-hal-skw
+ libwifi-hal-skw \
+ libwifi-hal-sprd

This modification ensures that the Wi-Fi HAL dynamic library corresponding to Unisoc is generated and preloaded during product build.

5.4 Adding Android.mk for Unisoc Wi-Fi HAL

The source material requires creating a unisoc directory under the Rockchip Wi-Fi HAL’s vendor directory, adding Android.mk, and copying the wifihal source code from the driver package to the hardware directory. The core build configuration is as follows:

# Copyright (C) 2011 The Android Open Source Project
# Licensed under the Apache License, Version 2.0
LOCAL_PATH := hardware/unisoc/wlan/wifi_hal
include $(CLEAR_VARS)
LOCAL_CFLAGS := \
-Wall \
-Werror \
-Wno-format \
-Wno-reorder \
-Wno-unused-function \
-Wno-unused-parameter \
-Wno-unused-private-field \
-Wno-unused-variable
LOCAL_C_INCLUDES += \
external/libnl/include \
$(call include-path-for, libhardware_legacy)/hardware_legacy \
external/wpa_supplicant_8/src/drivers
LOCAL_HEADER_LIBRARIES := libutils_headers liblog_headers
LOCAL_SRC_FILES := \
wifi_hal.cpp \
rtt.cpp \
common.cpp \
cpp_bindings.cpp \
gscan.cpp \
link_layer_stats.cpp \
wifi_logger.cpp \
wifi_offload.cpp
LOCAL_SHARED_LIBRARIES := \
librkwifi-ctrl \
libcrypto \
libnl \
libutils \
libcutils \
liblog
LOCAL_MODULE := libwifi-hal-sprd
LOCAL_PROPRIETARY_MODULE := true
include $(BUILD_SHARED_LIBRARY)

5.5 Adding Automatic Wi-Fi Device Recognition

Uncomment the SPRDWL device in the Rockchip Wi-Fi control logic and use the ID 0000:0000 read from the SDIO uevent as the matching ID.

// frameworks/opt/net/wifi/libwifi_hal/rk_wifi_ctrl.cpp
static wifi_device supported_wifi_devices[] = {
{"AP6611S", "06CB:AABF"},
{"MVL88W8977", "02df:9145"},
{"NXP88W8987", "02df:9149"},
{"SPRDWL", "0000:0000"},
{"BES2600", "be57:2002"},
{"AIC8800", "5449:0145"},
{"AIC8800", "c8a1:0082"},
};

After the system reads the SDIO device ID, it can recognize the module as the SPRDWL type and proceed to the corresponding driver loading and HAL selection process.

5.6 Adding BSP Module Pre-loading Logic

// frameworks/opt/net/wifi/libwifi_hal/wifi_hal_common.cpp
#define SPRD_BSP_DRIVER_MODULE_PATH \
WIFI_MODULE_PATH "uwe5622_bsp_sdio.ko"
#define SPRDWL_DRIVER_MODULE_NAME "sprdwl"
int wifi_load_driver() {
...
if (strstr(wifi_ko_path, SPRDWL_DRIVER_MODULE_NAME)) {
insmod(SPRD_BSP_DRIVER_MODULE_PATH, "");
usleep(200000);
}
...
}

sprdwl_ng.ko relies on the underlying UWE5622 BSP and SDIO transmission capabilities. Therefore, before loading the main Wi-Fi driver, it is necessary to insert uwe5622_bsp_sdio.ko first and wait for module initialization.

5.7 Building Android Image

source build/envsetup.sh
lunch 6
./build.sh -UKAup

After compilation is complete, verify that the Kernel modules, vendor_dlkm.img, vendor.img, and related system images have been updated. Merely replacing boot.img or the kernel image may not synchronously update the HAL, firmware, and Vendor DLKM modules.

6. Driver and Function Verification

6.1 Checking SDIO Enumeration

console:/sys/bus/sdio/devices # ls
mmc2:8800:1

If the directory is empty, prioritize checking the SDIO controller, pin multiplexing, power supply, and the timing of RESET and CHIP_EN instead of continuing to troubleshoot the Android HAL.

6.2 Checking if Driver Modules are Preloaded

console:/ # ls /vendor_dlkm/lib/modules/
bcmdhd.ko
mlan.ko
moal.ko
modules.alias
modules.dep
modules.load
modules.softdep
r8168.ko
sprdbt_tty_sdio.ko
sprdwl_ng.ko
uwe5622_bsp_sdio.ko

This project requires at least uwe5622_bsp_sdio.ko and sprdwl_ng.ko. The Bluetooth function will also use sprdbt_tty_sdio.ko.

6.3 Checking Module Loading Dependencies

console:/sys/bus/sdio/devices # lsmod
Module Size Used by
sprdwl_ng 507904 0
sprdbt_tty_sdio 53248 0
uwe5622_bsp_sdio 286720 2 sprdwl_ng,sprdbt_tty_sdio
r8168 589824 0

The Used by field can confirm that both Wi-Fi and Bluetooth drivers depend on the underlying uwe5622_bsp_sdio module. If loading only sprdwl_ng fails, check whether the BSP module was loaded in advance and whether the dependency symbols are satisfied.

6.4 Checking the wlan0 Network Interface

console:/ # ifconfig wlan0
wlan0 Link encap:Ethernet
HWaddr ec:b5:0a:55:5a:6f
Driver unisoc_wifi
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

The appearance of wlan0 with the driver unisoc_wifi indicates that the kernel driver, firmware startup, and network interface creation have been completed. You can then proceed to Android Settings for scanning, connecting, and network verification.

7. Log Toggles and Problem Diagnosis

7.1 Enabling or Disabling WCN Driver Logs

# Turn OFF Wi-Fi/WCN driver logs
echo "bsplog=0" > /proc/mdbg/at_cmd
# Turn ON Wi-Fi/WCN driver logs
echo "bsplog=1" > /proc/mdbg/at_cmd

You can also modify the default log level in the driver source code.

// File path: external/wifi_driver/unisoc/unisocwcn/platform/wcn_procfs.c
// Default log level: INFO
u32 wcn_print_level = LOG_INFO;
// To keep only ERROR logs:
// u32 wcn_print_level = LOG_ERR;

During the development phase, it is recommended to retain the INFO level. For the product version, the log volume can be appropriately reduced to avoid continuous logging affecting performance or overwhelming other kernel logs.

7.2 Capturing CP2 Firmware Logs

# Enable cp2log
echo -e "at+armlog=1\r" > /proc/mdbg/at_cmd
# Save cp2log
cat /dev/slog_wcn0 > /sdcard/cp2log.txt &

You can also adjust the default behavior in the platform configuration header file:

// File path: unisocwcn/include/platform_config/rk_config.h
// true: Disable cp2log by default
// false: Enable cp2log by default
config_wcn_user = false;

7.3 Capturing Dmesg

The default kernel log buffer in Android might be small, causing old logs to be overwritten by new ones during issue reproduction. Before capturing, you can increase the ''Logger Buffer Sizes '' in Developer Options.

Figure 5: Logger Buffer Sizes in Android Developer Options

adb shell dmesg > D:\log\dmesg.txt

After capturing, you can prioritize filtering for keywords related to sprdwl, WCN, SDIO, and unisoc:

grep -Ei "sprdwl|wcn|sdio|unisoc|marlin" dmesg.txt

7.4 Key Phases of Successful Driver Load Logs

The complete log can be lengthy. You can assess the initialization progress according to the following phases.

Phase 1: Device Tree Parsing and Low-level Driver Probe

WCN BASE: marlin_init entry!
WCN BASE: marlin_probe: unisoc wcn driver build time: Mar 19 2025 06:11:16 (UTC)
WCN BASE: parse_wcn_globle_config entry
WCN BASE: marlin_probe: device node name: sprd-marlin3
WCN BASE: btwf firmware name:/vendor/etc/firmware/wcnmodem.bin
WCN SLP_MGR: slp_mgr_init ok!
WCN SDIO: adma enable tx:0, rx:0
WCN SDIO: sdiohal_init sdiohal driver init successful
WCN BASE: marlin_probe driver match successful!

Driver match successful indicates that the sprd-marlin3 node has matched with the WCN low-level driver.

Phase 2: Module Power-up and SDIO Scanning

WCN BASE: start_marlin [MARLIN_WIFI]
WCN BASE: the first power on start
WCN BASE: marlin_clk_enable successfully!
WCN BASE: marlin_digital_power_enable D1v2 1
WCN BASE: wifipa 3v3 1
WCN SDIO: sdiohal_scan_card
WCN SDIO: sdiohal_probe func num is 1!!!
WCN SDIO: sdiohal_probe: func->class=0, vendor=0x0000, device=0x0000
WCN SDIO: enable sdio func1 ok
WCN BASE: marlin_scan_finish!
WCN SDIO: sdiohal_probe scan card successful!

scan card successful is the key log for determining whether the SDIO link and power-up timing are normal.

Phase 3: Downloading wcnmodem.bin Firmware

WCN BASE: xtal_26m clock XO mode
WCN BASE: then marlin start to download
WCN BASE: marlin btwifi_download_firmware from /system/etc/firmware/ start!
WCN BASE: download count=29,len=0,trans_size=32768
WCN BASE: download count=29,len=32768,trans_size=32768
...
WCN BASE: download count=29,len=917504,trans_size=29616
WCN BASE: marlin btwifi_download_firmware successfully!
WCN BASE: marlin_start_run

Firmware download logs will print repeatedly in fixed fragment lengths. As long as download_firmware successfully appears at the end, it indicates the firmware file is accessible and the download is complete.

Phase 4: SDIO Parameter Synchronization and CP Startup

WCN BASE: sdio_config rx mode:[sdma]
WCN BASE: sdio_config blksize:[512]
WCN BASE: sdio_config bt_wake_host:[dis]
WCN BASE: sdio_config sdio_irq:[gpio1]
WCN BASE: marlin_send_sdio_config_to_cp sdio_config:0x31
WCN BASE: pre_btwifi_download_sdio check_cp_ready start
WCN BASE: check_cp_ready sync val:0xf0f0f0f2, prj_type val:0x0
...
WCN BASE: check_cp_ready sync val:0xf0f0f0ff, prj_type val:0x0
...
WCN BASE: then marlin download finished and run ok

Here, you can confirm the use of SDMA, 512-byte block size, and GPIO interrupts. Once the synchronization value enters the ready state, the CP firmware begins normal operation.

Phase 5: Reading Version, Loading INI, and Creating wlan0

WCN BASE: at cmd read:WCN_VER:Platform Version:MARLIN3_20A_W25.08.1
Project Version:sc2355_marlin3_lite_2in1~02-17-2025 10:47:43~
sc2355:Spreadtrum WLAN Version:
sc2355:Kernel:6.1.75-android14-11-g8942136b2744-ab11900366,
Driver:Marlin3,update:000e,reserved:
sc2355:get_wifi_config_param, chip id of marlin3 lite is 2,
open wifi_board_config.ini
sc2355:iface 'wlan0'(c4:a6:4e:c4:5c:12) type 2 added

Finally, the appearance of open wifi_board_config.ini and iface wlan0 added indicates that the main Wi-Fi driver has completed configuration and successfully created the network interface.

7.5 Capturing Android logcat

Android upper-layer logs can be used to analyze Wi-Fi toggling, scanning, connecting, P2P, and internet connectivity detection. After entering Developer Mode and raising the log level, capture logs in real-time via ADB:

adb logcat -v time > D:\log\logcat.txt

Start capturing, reproduce the issue, then press Ctrl+C to end Common keywords are as follows:

8. Typical Issues and Troubleshooting Approaches

8.1 No mmc2:8800:1 in the SDIO Directory

• Confirm the VIO and VBAT voltages for the FCS950U, as well as the power-up sequence.

• Verify the active levels and release timing for CHIP_EN and RESET_N.

• Check the pin multiplexing and hardware pull-up resistors for SDIO CMD, CLK, and DATA0~DATA3.

• Attempt using the sdio-pwrseq or performing the reset earlier in the U-Boot stage.

• Reduce max-frequency to investigate signal integrity issues.

8.2 SDIO Enumerated, but the System Does Not Automatically Load the Driver

• Read the uevent to confirm if the SDIO_ID is still 0000:0000.

• Check if SPRDWL and its corresponding ID have been added in rk_wifi_ctrl.cpp.

• Verify the existence of uwe5622_bsp_sdio.ko and sprdwl_ng.ko in /vendor_dlkm/lib/modules.

• Ensure wifi_hal_common.cpp loads the BSP module first.

• Check modules.dep and kernel symbol dependencies.

8.3 Driver Modules Loaded, but No wlan0 Interface

• Check if marlin btwifi_download_firmware successfully appears in the logs.

• Confirm the actual path, permissions, and integrity of the wcnmodem.bin file.

• Verify that wifi_board_config.ini is loaded correctly.

• Inspect if check_cp_ready ultimately enters the ready state.

• Enable bsplog and cp2log to examine errors on the WCN firmware side.

8.4 wlan0 Exists, but Wi-Fi is Abnormal in Android Settings

• Confirm that libwifi-hal-sprd has been built and is a dependency for the product.

• Ensure the wpa_config.txt file contains the [sprdwl] configuration.

• Check the consistency between the HAL source directory and LOCAL_PATH in the Android.mk file.

• Capture logcat and observe errors related to setWifiEnabled, wifi state, and wpa_supplicant.

• Check for SELinux denials, missing dynamic libraries, or service startup failures.

9. Conclusion and Key Points for Adaptation

Adapting the FCS950U SDIO Wi-Fi module on the OK3576 Android 14 platform does not revolve around modifying a single driver file in isolation. Instead, the core is to establish the complete chain from hardware power-up to the Android Framework:

FCS950U Power Supply and Reset Sequence
↓
SDIO Controller Enumeration and Device Tree Matching
↓
UWE5622 WCN BSP Module Loading
↓
wcnmodem.bin Firmware Download and CP Startup
↓
sprdwl_ng Creates wlan0
↓
Android Recognizes SPRDWL Device Type
↓
libwifi-hal-sprd and wpa_supplicant Startup
↓
Settings App: Scanning, Connection, Internet Access, and P2P Function Verification

During actual debugging, it is recommended to always follow the order of ''First the bus, then the driver, and finally Android '' for problem localization. If SDIO is not enumerated successfully, troubleshooting should not immediately jump to the HAL.If the wlan0 interface has not been created, network connection logs should not be the primary focus. By verifying each layer step-by-step using uevent, lsmod, dmesg, cp2log, and logcat, the time required for problem diagnosis can be significantly reduced.

This project also highlights two common risks:

• The timing of the RESET signal release directly affects SDIO enumeration.
• Naming discrepancies may exist between the module’s part number (OC), schematic net names, and device tree GPIOs. For wireless module adaptation, the hardware datasheet, physical component markings, schematics, and system logs must be cross-referenced. One should not rely solely on a single configuration example.

Appendix: Quick Checklist After Successful Adaptation

1. Solution Overview

AVS (Any View Stitching) Panoramic Stitching Technology: This technology integrates and stitches multiple camera feeds into a single complete image, achieving broader field-of-view coverage and all-angle video capture.

Core Principle of Panoramic Stitching:

The panoramic camera is treated as a unit sphere. Images captured by each lens are projected onto the spherical surface via an imaging model. Pixel-level fusion is applied to overlapping areas of multiple images to obtain a complete spherical image. Finally, 3D coordinate points on the spherical image are projected onto a 2D plane to obtain a flat image.

The RV1126B chip features a dedicated hardware stitching module, which handles image fusion directly in hardware, significantly reducing CPU and memory resource consumption, making it suitable for low-power edge vision applications.

The effectiveness of AVS panoramic stitching heavily relies on the camera calibration process, which is divided into two categories:

Intrinsic Calibration: Calibrates lens focal length, optical center, and distortion coefficients.

Extrinsic Calibration: Calibrates the relative installation positions between multiple cameras.

This article describes a 360° panoramic stitching solution based on the OK1126B-S development board + TP2815 4-channel analog-to-MIPI module, integrating four AHD cameras. A demonstration of real-world stitching results is provided at the end.

2. Software and Hardware Configuration List

Hardware Configuration:

• OK1126B-S development board ×1

• TP2815 4-channel analog to MIPI CSI module ×1

• LT9211 MIPI to LVDS module

• 4 AHD cameras

• Accessories: power supplies, data cables, etc.

Software Configuration:

• OS：Linux 6.1

• Dependency: Rockit multimedia framework

3. Hardware Connection Steps

Camera Assembly and Wiring:

Mount the 4 AHD cameras according to the calibration structure, and connect the signal cables to the TP2815 module in sequence. All cameras are powered by 12V.

TP2815 Module to Development Board Connection:

Power the TP2815 module via a Type-C interface with 5V. Use a unidirectional FPC ribbon cable to connect the module’s MIPI CSI channel to the P9 interface of the OK1126B-S development board. Refer to the schematic for hardware pin definitions.

Development Board Peripheral Connections:

Connect the OK1126B-S development board to the 5V main power supply. Use a Type-C cable to connect the board to a computer for serial debugging and system flashing. Connect the development board to a 10.1-inch LVDS screen via the LT9211 MIPI to LVDS module.

4. System Image Flashing

Flash a system image that supports Rockit and AVS. (Specific modification methods are omitted here. For details, please contact Forlinx Embedded for relevant patches.)

5. Panoramic Stitching Function Testing Process

Step 1: Deploy Program Files:

Place the compiled executable main_test, the AVS JSON configuration file, RK calibration files, AI libraries, and model files in the /root directory of the development board.

Step 2: Start the Panoramic Stitching Program:

Navigate to the /root directory and execute the program startup command:

./main_test

After the program runs normally, the console will print logs related to channel creation, as shown in the example output below:

22:46:30-306{4_ch_node_create:367}VPSs[1,0] sharebuffer should config staxsize[0,0], outputsize[1280,720]maybe not correct
22:46:38-308{v4_ch_node_create:367}VPSs[2,0]share buffer should config staxsize[0,0], outputsize[1280,720]maybe not correct
22:46:38-310{4_ch_node_create:367}VPSs[3,0]sharebuffer should config staxsize[0,0], outputsize[1280,720]maybe not correct

At this point, you can view the stitched 360° panoramic image from the four cameras on the LVDS screen, with target detection enabled.

6. Stitching Effect Demonstration

This summarizes the technical overview of creating a 360° panoramic stitching solution with four AHD cameras using Forlinx's OK1126B-S development board. For those evaluating platforms for similar projects, you can click to view the RV1126 series SoMs and development boards product page for detailed hardware parameters and technical specifications.

Following the Rockchip RK3572 announcement, Forlinx Embedded has introduced the FET3572-C SoM and accompanying OK3572-C development board. The platform combines an octa-core CPU configuration, 4 TOPS NPU, LPDDR5/LPDDR5X support, and multimedia capabilities extending to 8K decoding.

The RK3572 processor integrates dual Cortex-A73 performance cores together with six Cortex-A53 efficiency cores and is manufactured on an 8nm process. The platform reduces power consumption while supporting robust AI acceleration and multimedia workloads, and integrates a Mali-G310 GPU with Linux and Android software support.

RK3572 architecture overview

For AI acceleration, the integrated NPU provides up to 4 TOPS INT8 performance and supports INT4, INT8, INT16, FP4, FP8, FP16, and BF16 operations together with W4A16 asymmetric MAC processing. The platform supports frameworks including TensorFlow, Caffe, TFLite, PyTorch, ONNX, Android NN, and MXNet.

Example workloads for the platform include image enhancement, super-resolution, speech recognition, face recognition, and license plate recognition.

RK3572 NPU performance

Multimedia capabilities include support for up to 8K decoding and 4K encoding, a 12MP ISP, up to five camera inputs, dual independent displays, and Mali-G310 graphics with Vulkan support for applications such as POS systems, digital signage, commercial displays, and intelligent video systems.

RK3572 multimedia pipeline

The RK3572 also provides storage interfaces including eMMC 5.1, UFS 2.0, SD/MMC, and FSPI, while connectivity and industrial interfaces include PCIe 2.1, SATA 3.1, USB DRD 3.0/2.0, dual Gigabit Ethernet, CAN, I²C, I³C, SPI, UART, SDIO, and DSMC. Native LPDDR5/LPDDR5X support and a four-rank memory controller are also listed.

FET3572-C SoM

Further Information & Availability

Pre-orders for the FET3572-C SoM and OK3572-C development board are now officially open. For detailed hardware specifications, product pages, full software development resources, and official pricing, please contact our sales team or request an evaluation kit directly.

This article is compiled and republished from LinuxGizmos.

In industrial equipment data acquisition scenarios, this article discusses the Forlinx Embedded FCU1501 Control Unit and its supporting software for deployment and debugging, creating a practical Industrial IoT gateway.

Neuron is a lightweight, open-source edge protocol gateway software designed for the Industrial Internet of Things (IIoT). It addresses a core challenge in industrial settings: how to enable various industrial devices (such as PLCs, sensors) using different communication protocols to ''communicate'' with each other and uniformly upload data to cloud platforms.

In terms of architecture, Neuron acts as a protocol conversion bridge at the edge. It achieves multi-source data interconnection through the following core capabilities:

• Protocol Conversion: Supports converting dozens of industrial protocols such as Modbus, OPC UA, Siemens S7 into standard MQTT messages, enabling seamless data upload to the cloud or integration with other systems;
• Multi-Device Access: Supports simultaneous connection and management of hundreds to thousands of devices from different brands, achieving one-stop data acquisition;
• Ultra-Lightweight Deployment: Entirely developed in C, it has extremely low resource consumption and can run natively or containerized on various edge hardware such as X86 and ARM;
• Open and Flexible: Open-source under the LGPL license, it provides a web interface for visual configuration and management, facilitating user operation and secondary development.

The following is a complete hardware practical tutorial: Connecting a rail-mounted Modbus temperature and humidity transmitter (RS-485, Modbus-RTU protocol) to the RS485_5 serial port of the FCU1501, configuring the southbound driver through Neuron, and collecting real-time raw temperature and humidity data.

1. Downloading and Installing Neuron

This hands-on guide uses the open-source Neuron version 2.x. While versions 3.x and above have transitioned to a commercial license, Neuron 2.15.0, released under the LGPL license, still offers a complete open-source community ecosystem and high stability. It has also been meticulously optimized for resource usage on lightweight, low-power embedded hardware like the FCU1501.

1. Visit the official GitHub repository: https://github.com/emqx/neuron;

2. Download the installation package adapted for the 32-bit ARM architecture: neuron-2.15.0-linux-armhf.tar.gz;

3. After extracting the file to the FCU1501 device, modify the configuration file to enable external network access vi /root/neuron/config/neuron.json

Modification: Change the ip parameter in the configuration to 0.0.0.0.Complete Configuration Reference:

{
"ip": "0.0.0.0",
''port": 7000,
''disable_auth": 0
}

Navigate to the Neuron program directory and execute the background startup command:

./neuron -d

After the startup, you can open the login page by accessing the device IP followed by port 7000 in a browser. Default username/password: admin / 0000. After logging in, you can modify account permissions and parameters as needed.

2. Hardware Preparation and Wiring

Required Equipment List:

1. FCU1501 Embedded Control Unit (Expansion version, equipped with RK3506J processor, Linux 6.1);

2. Rail-mounted Modbus Temperature & Humidity Transmitter (RS-485 interface, Modbus-RTU protocol, default baud rate: 9600bps, address: 1).

The FCU1501 Embedded Control Unit (Expansion version) is equipped with 8 independent RS485 serial ports. This tutorial uses the RS485_5 channel, which corresponds to the system node /dev/ttyCH334_1 (refer to FCU1501 Hardware Manual §2.11.2).

Wiring Correspondence:

3. Identifying Serial Devices

After SSH login to FCU1501, first check if the serial port device is recognized:

root@FCU1501:~# ls /dev/ttyCH334*
/dev/ttyCH334_0 /dev/ttyCH334_1 /dev/ttyCH334_2 /dev/ttyCH334_3

In the output list,/dev/ttyCH334_1is the RS485_5 serial port channel used for this operation.

4. Configuring Modbus-RTU Southbound Device in Neuron

1. Add Southbound Driver Device

In the left menu bar, select 【Southbound Device】 - 【Add Device】, and fill in the parameters:

• Device Name: Temperature & Humidity Transmitter (customizable)

• Plugin Type: Modbus-RTU

• Serial Port Path: /dev/ttyCH334_1

• Baud Rate: 9600 (matches the sensor's factory settings)

• Data Bits: 8

• Stop Bits: 1

• Parity: None

The device default address is 1. If the sensor's address or baud rate has been modified previously, the configuration parameters need to be adjusted accordingly (refer to Temperature & Humidity Transmitter Manual §1.1).

1. Create Data Group and Collection Points

   Select the newly created ''Temperature & Humidity Transmitter'' device, enter the Data Group page, create a new data group named ''Temperature and Humidity Data'' (Temperature & Humidity Data), then add collection points. Configure the register parameters according to Temperature & Humidity Transmitter Manual §3.1.

   Then, add points (i.e., register addresses) within the data group:

   According to Temperature & Humidity Transmitter Manual §3.1, the register addresses are as follows:

1. Start Device Data Collection

After configuration, click the Start button on the device list page. Neuron will begin reading data from the sensor according to the set collection cycle.

5. Real-time Data Verification

Once the device is running, navigate to the corresponding data group page and click 【View Data】 (or similar). The page will continuously refresh, displaying the real-time collected temperature and humidity values, confirming the data link is functioning correctly.

6. Common Operational Issues and Precautions

1. R485 Wiring Fault: Reversing the A and B signal lines will directly cause communication failure. You can try swapping the two lines or use a multimeter to check for line continuity;

2. Serial Port Parameter Mismatch: The sensor's factory baud rate is 9600 bps. If you have modified the device parameters, the serial port baud rate, parity bit, and address configured in Neuron must match (refer to Transmitter Manual §3.2);

3. Negative Temperature (Below 0°C) Parsing: When the ambient temperature is below 0°C, the value is stored in the register in two's complement format. The read data must be parsed as a signed INT16 integer (refer to Transmitter Manual §3.4).

7. Summary

This hands-on tutorial successfully established a connection between the FCU1501 and a Modbus-RTU temperature and humidity sensor using the RS485_5 serial port. By utilizing Neuron, we configured the southbound driver, collected data points, and performed real-time data reading. This process fully validated two key advantages:

1. FCU1501's Multiple RS485 Serial Ports can flexibly adapt to various types of terminal devices in industrial settings, ensuring stable and reliable communication;

1. Neuron's Lightweight Edge Gateway Software offers comprehensive compatibility with the Modbus-RTU industrial protocol, making it simple to set up and configure.

After completing local data collection, you can proceed to configure Neuron's northbound MQTT application to upload the temperature and humidity data to a cloud platform, building a complete remote-monitoring industrial IoT data acquisition solution.

This article primarily explains how to adapt the IMX577 module on the RK3588 platform using the Linux 5.10.66 Buildroot system.

I. Hardware Interface

By referring to the development board schematic, you can clearly see the hardware design of the MIPI CSI interface on the OK3588 development board.

For this test, the CAM1 interface is used as an example. Before selecting a module, it is crucial to ensure that the pinout of the chosen camera module matches the pinout of the camera interface on the RK3588 carrier board.

II. Kernel Configuration

If you directly apply the patch provided in the attachments, you can skip “1. Driver Addition” and “2. Device Tree Modification” and proceed directly to compiling the kernel image.

Place the patch file in the kernel directory of your source code. Execute the following command in the kernel directory to apply the patch:

patch -p1 < OK3588_linux5.10.66_imx577_all.patch

1. Driver Addition

Since the IMX577 driver is not included in the Linux 5.10.66 kernel source code, it needs to be added. The corresponding driver file is provided in the attachments.

Copy imx577.c to the following path in your source code:

OK3588-linux-fs/kernel/drivers/media/i2c/

Then, modify the corresponding Makefile, Kconfig, and defconfig files to add the driver configuration to the kernel. You can refer to the following patch for the necessary modifications.

diff --git a/arch/arm64/configs/OK3588-Linux_defconfig b/arch/arm64/configs/OK3588-Linux_defconfig
index 3506488cf..f3c9c1d9e 100644
--- a/arch/arm64/configs/OK3588-Linux_defconfig
+++ b/arch/arm64/configs/OK3588-Linux_defconfig
@@ -335,6 +335,7 @@ CONFIG_VIDEO_OV7251=y
CONFIG_VIDEO_OV13850=y
CONFIG_VIDEO_VM149C=y
CONFIG_VIDEO_OV5645=y
+CONFIG_VIDEO_IMX577=y
# CONFIG_VGA_ARB is not set
CONFIG_DRM=y
CONFIG_DRM_IGNORE_IOTCL_PERMIT=y
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 6201d6d3f..d1a97cc91 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1200,6 +1200,17 @@ config VIDEO_IMX355
To compile this driver as a module, choose M here: the
module will be called imx355.
+config VIDEO_IMX577
+ tristate "Sony IMX577 sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ help
+ This is a Video4Linux2 sensor driver for the Sony
+ IMX577 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx577.
+
config VIDEO_JX_K17
tristate "Soi JX_K17 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index cc1b7ef4b..49b5c22bb 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -182,6 +182,7 @@ obj-$(CONFIG_VIDEO_IMX378) += imx378.o
obj-$(CONFIG_VIDEO_IMX415) += imx415.o
obj-$(CONFIG_VIDEO_IMX464) += imx464.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
+obj-$(CONFIG_VIDEO_IMX577) += imx577.o
obj-$(CONFIG_VIDEO_JX_K17) += jx_k17.o
obj-$(CONFIG_VIDEO_MAX9286) += max9286.o
obj-$(CONFIG_VIDEO_MAX96714) += max96714.o

2. Device Tree Modification

This modification is based on the 4lane configuration of the IMX577 camera module. On the OK3588 carrier board, only the MIPI CSI interfaces of CAM1, CAM2, and CAM3 support 4 lanes in hardware. This example uses CAM1 for demonstration.

To configure CAM1 in the device tree, please refer to the following patch for the necessary modifications.

diff --git a/arch/arm64/boot/dts/rockchip/OK3588-C-Camera.dtsi b/arch/arm64/boot/dts/rockchip/OK3588-C-Camera.dtsi
index eaec68b64..28e4b05ae 100644
--- a/arch/arm64/boot/dts/rockchip/OK3588-C-Camera.dtsi
+++ b/arch/arm64/boot/dts/rockchip/OK3588-C-Camera.dtsi
@@ -60,16 +60,8 @@
      status = "okay";
      clock-frequency = <400000>;
 
-    vm149c_0: vm149c@0c {
-        compatible = "silicon touch,vm149c";
-        status = "okay";
-        reg = <0x0c>;
-        rockchip,camera-module-index = <0>;
-        rockchip,camera-module-facing = "back";
-   };
-
-    cam1_ov13850: cam1_ov13850@10 {
-        compatible = "ovti,ov13850";
+    cam1_imx577: cam1_imx577@10 {
+        compatible = "sony,imx577";
         status = "okay";
         reg = <0x10>;
 
@@ -82,12 +74,11 @@
          rockchip,camera-module-facing = "back";
          rockchip,camera-module-name = "forlinx";
          rockchip,camera-module-lens-name = "default";
-   lens-focus = <&vm149c_0>;
 
          port {
-            cam1_ov13850_out: endpoint {
+            cam1_imx577_out: endpoint {
                  remote-endpoint = <&mipi_in_0_ucam1>;
-                data-lanes = <1 2>;
+                data-lanes = <1 2 3 4>;
              };
          };
      };
@@ -104,8 +95,8 @@
              #size-cells = <0>;
              mipi_in_0_ucam1: endpoint@1 {
                  reg = <1>;
-                remote-endpoint = <&cam1_ov13850_out>;
-                data-lanes = <1 2>;
+                remote-endpoint = <&cam1_imx577_out>;
+                data-lanes = <1 2 3 4>;
              };
          };
          port@1 {

3. Supplementary Configuration Notes

Because the data transmitted by the IMX577 requires ISP processing, it is necessary to invoke the rkisp module during the camera data pipeline processing to obtain the processed data from the rkisp node eventually.

Currently, in the OK3588 Linux 5.10.66 Buildroot system, the default camera configuration supports the OV13850 on CAM1 and CAM2. For example, the topology for CAM1 is configured as:

mipicamera0 --> csi2_dcphy0 --> mipi0_csi2 --> rkcif_mipi_lvds --> rkcif_mipi_lvds_sditf --> rkisp0_vir0

In contrast, CAM3, CAM4, and CAM5 by default support the OV5645. This camera module’s captured data does not require additional ISP processing. Therefore, the device tree topology configuration for these ports does not pass through rkisp. For example, the topology for CAM3 is:

mipicamera2 --> csi2_dphy0 --> mipi2_csi2 --> rkcif_mipi_lvds2

Therefore, if you want to configure the IMX577 on the CAM3 interface, you also need to add the rkisp node to its configuration, generally following the device tree settings for CAM1 and CAM2 as a reference.

For an explanation related to pipeline configuration, please refer to the screenshot from RK’s documentation provided below.

III. ISP Configuration File Explanation

After completing the driver loading and device tree topology configuration at the kernel stage, you can already capture image data from the rkisp video node. However, the image data at this point has not been processed by the rkisp and will likely appear predominantly green. To get the rkisp functioning, a configuration file is also required.

The rkisp configuration file is stored in the /etc/iqfiles/ directory of the filesystem, typically with a .json extension. It contains various parameters for ISP calibration.

You can check if rkisp is operational by verifying whether the rkaiq_3A_server service is running. Use the ps and grep commands to check for its process.

root@ok3588:/# ps -ef | grep 3A
root 1408 1 0 14:48 ? 00:00:00 /bin/sh -c /usr/bin/rkaiq_3A_server 2>&1 | logger -t rkaiq_3A
root 1410 1408 0 14:48 ? 00:00:00 /usr/bin/rkaiq_3A_server
root 1411 1408 0 14:48 ? 00:00:00 logger -t rkaiq_3A
root 1559 1552 0 14:49 ttyFIQ0 00:00:00 grep 3A

Currently, there is no IMX577 .json file in this path, so the 3A service will not start.

An imx577_forlinx_default.json file is provided in the attachments.

Note: The naming of this JSON file is significant. It must correspond to the rockchip,camera-module-name and rockchip,camera-module-lens-name properties in the device tree.

Currently, these properties are set to forlinx and default respectively, hence the corresponding file name imx577_forlinx_default.json.

Simply copy this JSON file to the /etc/iqfiles/ directory on the development board’s filesystem. Then, execute the sync command to save and reboot to restart. After reboot, the 3A service should be up and running.

For detailed camera configuration on the RK3588, you can refer to the relevant RK documentation located in the following directory of the source SDK:

OK3588-linux-fs/docs/Common/CAMERA/ISP3X

On the development board, you can check the current rkaiq version in the image using the following command.

root@ok3588:/# strings /usr/lib/librkaiq.so | grep -w AIQ
AIQ v3.0x8.8
AIQ: %s
E:AIQ IPC UNKNOWN CMD: %d

IV. Debugging

If the camera module does not function correctly after the above modifications, you can use i2ctool to check if the device ID of the camera module is detected on the I2C bus.

root@ok3588:/# i2cdetect -r -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Note that the device ID may differ for different camera modules. Here, 10 represents the camera module’s ID. If the corresponding driver is paired correctly, it will show as UU. If the driver is not paired, it will only display 10.

You can also check the kernel log using dmesg to determine the status of the camera module.

[ 5.199722] imx577 3-0010: driver version: 00.01.05
[ 5.199731] imx577 3-0010: Get hdr mode failed! no hdr default
[ 5.199766] imx577 3-0010: Failed to get power-gpios, maybe no use
[ 5.201129] imx577 3-0010: Looking up avdd-supply from device tree
[ 5.201140] imx577 3-0010: Looking up avdd-supply property in node /i2c@feab0000/cam1_imx577@10 failed
[ 5.202657] imx577 3-0010: supply avdd not found, using dummy regulator
[ 5.202733] imx577 3-0010: Looking up dovdd-supply from device tree
[ 5.202744] imx577 3-0010: Looking up dovdd-supply property in node /i2c@feab0000/cam1_imx577@10 failed
[ 5.202759] imx577 3-0010: supply dovdd not found, using dummy regulator
[ 5.202793] imx577 3-0010: Looking up dvdd-supply from device tree
[ 5.202803] imx577 3-0010: Looking up dvdd-supply property in node /i2c@feab0000/cam1_imx577@10 failed
[ 5.202817] imx577 3-0010: supply dvdd not found, using dummy regulator
[ 5.207877] imx577 3-0010: Detected Sony imx0577 sensor
[ 5.272651] rockchip-csi2-dphy csi2-dcphy0: dphy0 matches m00_b_imx577 3-0010:bus type 5

Check the status of camera module node creation using the v4l2-ctl command

v4l2-ctl --list-devices

Use the following command to locate the rkisp_mainpath video node. Typically, data from the rkisp pipeline is captured at the rkisp_mainpath node.

grep -H '' /sys/class/video4linux/video*/name4l2-ctl --list-devices

Preview using the gsteramer command

gst-launch-1.0 v4l2src device=/dev/video40 ! video/x-raw, format=NV12, width=1024,height=600, framerate=30/1 ! waylandsink

V. Attachment Download

• OK3588 Linux 5.10.66 IMX577 Adaption Patch Package

1. Solution Overview

Forlinx Embedded has developed a comprehensive night vision camera solution based on Rockchip's high-performance RK3588 AI vision platform, which includes the OK3588-C development board and the SC285 Ultra Starlight image sensor.

• Main Control Platform: Forlinx Embedded OK3588-C Development Board (Octa-core processor + 6TOPS NPU + 2*16M ISP)
• Image Sensor: SC285 Ultra Starlight CMOS
• Applicable Fields: Full-scenario applications including security surveillance, campus inspection, underground parking lots, road capture, outdoor equipment, and automotive night vision.
• Core Features: Full-color imaging at 0.1 lux extreme low light, low noise, high dynamic range, industrial wide temperature range, supporting rapid mass production and deployment across the industry.

2. Current Industry Pain Points

Many teams currently face numerous technical debugging challenges when independently building related camera solutions, with ISP tuning being the most significant bottleneck. This is particularly challenging for individual developers and small-to-medium-sized R&D teams:

High Technical Barrier for ISP Tuning:

The ISP parameter system is vast, encompassing hundreds of fine-grained parameters like exposure, gain, noise reduction, HDR, color matrix, gamma correction, and 3DNR. Parameter combinations vary completely under different illuminance, color temperature, and scenarios. Unlocking the full potential of the SC285's ultra-starlight night vision requires extensive image tuning experience, making it difficult for beginners.

Scarcity and High Cost of Professional Debugging Equipment:

Precise image quality tuning requires professional test equipment like standard light source boxes, illuminometers, gray cards, color temperature cards, and dark rooms. The investment for a single set is high. Most individual users and small studios lack the hardware conditions, relying on visual debugging alone, which cannot fundamentally solve issues like image noise, color cast, or dynamic imbalance.

Fragmented and Hard-to-Access Official Technical Documentation:

Core register manuals, parameter descriptions, and adaptation cases from sensor and ISP manufacturers are often supply-specific and not publicly available. Scattered online documentation lacks a complete system, missing comprehensive porting processes and troubleshooting guides, leading R&D personnel down wrong paths with high trial-and-error costs.

High Complexity in Joint Debugging and Low Troubleshooting Efficiency:

The SC285 sensor is deeply integrated with the ISP, main control chip, hardware timing, and device tree. Issues like black screen, screen artifacts, abnormal night vision, or unstable frame rates require layer-by-layer troubleshooting from hardware circuits and driver code to ISP parameters, making it difficult for individual developers to identify root causes and severely delaying project progress.

Inherent Limitations of Module-Internal ISP Solutions:

While opting for module-internal ISP reduces debugging difficulty, it is limited by computing power and architecture, resulting in significantly weaker low-light image quality, dynamic range, and noise reduction capabilities, leaving products lacking market competitiveness.

3. Core Advantages: Using Platform's Built-in ISP vs. Camera Module Internal ISP

Most current vision solutions on the market use module-internal ISPs. This solution utilizes the RK3588 platform's built-in dual ISP, offering significant advantages in image quality, tunability, stability, and scalability:

Stronger Image Processing Performance:

The RK3588 ISP has independent computing power and processing channels, not occupying the main CPU/NPU resources. Algorithms like multi-frame noise reduction, 3DNR, HDR wide dynamic range, strong light suppression, and fog enhancement are processed in parallel, resulting in far superior frame rates and smoothness compared to resource-constrained module-internal ISPs.

Higher Freedom in Image Quality Tuning:

Module-internal ISP parameters are often fixed with limited adjustment space, making deep adaptation for high-sensitivity sensors like the SC285 difficult. The RK3588 ISP supports fine-tuning of all parameters, allowing customization of image quality styles for different scenarios (night vision, backlight, automotive, security), maximizing the SC285's ultra-starlight potential.

Better Performance in Low Light & Complex Scenarios:

Faced with complex conditions like 0.1 lux ultra-low illumination, strong car headlights at night, tunnel light/dark transitions, and rainy/snowy/foggy weather, the external ISP offers stronger dynamic range, noise reduction, and color reproduction capabilities. Nighttime images are purer, without smearing or color cast.

Lower Maintenance and Iteration Costs:

Module-internal ISPs are tightly bound to the chip; upgrades require replacing the entire module. The RK3588 ISP can be upgraded independently, requiring only ISP parameter updates for image quality iterations.

Lower Cost and Simplified BOM:

The RK3588 board integrates an independent dual ISP, eliminating the need for customers to purchase additional external ISP chips/modules, significantly saving PCB area, peripheral circuits, and power design costs.

4. Forlinx Embedded One-Stop Solution for ISP Debugging and Deployment Challenges

Pre-tuned Full Set of ISP Parameters, Out-of-the-Box Usability:

Professional image engineers have completed basic ISP image quality tuning, covering daytime, low light, 0.1 lux extreme darkness, and backlight conditions. Users don't need professional ISP tuning skills, skipping complex parameter configuration to obtain high-quality night vision images directly.

Complete Official-Level Documentation Package, Ending Fragmented Information:

Provides a unified, complete set of documents including driver source code, device tree templates, register descriptions, ISP parameter manuals, and debugging commands. The documentation system is complete and standardized, breaking down manufacturer information barriers and providing reliable references for R&D.

Eliminates Investment in Professional Debugging Equipment:

The solution has been repeatedly verified and calibrated in professional dark rooms with standard light sources and precise illuminance equipment. Customers don't need to purchase expensive professional test instruments; verification and mass production can be completed using conventional development environments, significantly reducing upfront hardware investment costs.

Mature Hardware-Software Joint Debugging Solution, Greatly Reducing Troubleshooting Difficulty:

Hardware timing, driver architecture, and the ISP pipeline are all verified, ensuring full compatibility and stability. Dedicated solutions are provided for common issues like screen artifacts, black screen, and night vision abnormalities, allowing individual developers and small teams to get started quickly.

Full-Cycle Technical Support, Escorting Throughout the Process:

From sample testing, hardware modifications, software porting to mass production, Forlinx's technical team provides one-on-one technical support, solving various issues during joint debugging, adaptation, and optimization, significantly shortening project R&D cycles.

5. Driver and Adaptation Steps

Driver Configuration

• Add the SC285 sensor driver to the kernel: drivers/media/i2c/SC285.c
• Complete power-on sequence, register initialization, and exposure/gain logic configuration.
• Adapt to the standard V4L2 Subdev interface and control items.
• Complete device registration and media topology binding.

6. Effect Demonstration

Comparison between direct camera preview effects and mobile phone recording effects (both videos are 1080p60fps; color cast in the video is due to colored light strips on nearby buildings, not introduced by module tuning).

Recorded Video Comparison

Module Preview 1

Mobile Phone Preview 1

Module Preview 2

Mobile Phone Recording 2

Module Preview 3

Mobile Phone Preview 3

Module Preview 4

Mobile Phone Preview 4

Camera Preview Comparison

Comparison 1

Comparison 2

Comparison 3

Comparison 4

The above environments were shot between 8:30 PM and 9:30 PM, selecting scenes with different brightness levels. Special attention is needed for the effect in the video (Mobile Phone Preview Effect 3); the environment was too dark for 1080p@60fps recording, so it was switched to 1080p@30fps.

In summary, the SC285 has more advantages over traditional cameras in handling such extremely dark environments and colored night vision scenes, making it more suitable for low-illuminance industries like security surveillance and dash cams.

7. Conclusion

In the current rapid adoption of low-illuminance vision devices, a quality hardware platform, mature image processing capabilities, and comprehensive support services are key to rapid project deployment and building product competitiveness. Forlinx Embedded's complete night vision solution pairing the OK3588-C development board with the SC285 Ultra Starlight sensor effectively addresses industry pain points like difficult debugging, high barriers to entry, and slow iteration found in traditional solutions. This is achieved through its high-performance external ISP, excellent low-light imaging, industry-universal architecture, and comprehensive cost advantages.

We provide mature mass-production solutions, complete technical documentation, and professional technical support to help R&D teams and enterprise customers bypass complex ISP tuning and hardware-software adaptation work, significantly shortening R&D cycles and controlling project costs. Whether for security surveillance, automotive imaging, industrial inspection, or smart terminal scenarios, this solution can handle them with ease.

We look forward to collaborating with more industry partners to explore new opportunities in the low-light imaging market, relying on stable and reliable embedded vision solutions.

8. Appendix

Currently Supported Module List (as of June 24, 2026)

Forlinx Embedded has officially launched the FCU3011 AI Edge Computing Box. Developed based on the NVIDIA® Jetson Orin™ Nano platform, it delivers up to 40 TOPS of AI inference performance within a low-power, compact form factor. The FCU3011 integrates a rich set of high-speed I/O interfaces, industrial-grade isolation protection, and an optional 5G communication module. It is specifically designed to address edge computing deployment challenges in harsh environments for applications like smart manufacturing, robotics (AGV/AMR), and smart cities.

Key Advantages

1. Breakthrough Performance per Watt

The FCU3011 fully unleashes the potential of the NVIDIA Ampere architecture GPU (featuring up to 1024 CUDA cores and 32 Tensor cores).

• Performance Tiers: Offers two hardware configurations: 4GB (20 TOPS) and 8GB (40 TOPS) to meet deployment needs for neural network models of varying complexity.

• Multi-Stream Parallel Processing: Powerful hardware decoding supports simultaneous input and real-time structured analysis of up to 11 channels of 1080p30 H.265 video streams.

• Native Ecosystem Support: Pre-installed with Forlinx Desktop 22.04 (based on Ubuntu). Fully compatible with CUDA, cuDNN, and TensorRT toolchains, enabling zero-modification migration of algorithm models from cloud to edge.

  

2. Fanless Design & Harsh Environment Adaptability

Deeply optimized in mechanical and electrical design for 24/7 unmanned industrial environments.

• Fanless Cooling: Utilizes a thermally-optimized passive cooling enclosure, eliminating system failure risks from fan wear and dust accumulation, ensuring sustained 40 TOPS performance without throttling.

• Advanced Electrical Protection (ESD Level 3): All Gigabit Ethernet ports, USB, RS485, and CAN interfaces pass ±6KV contact discharge and ±8KV air discharge tests, effectively resisting electrostatic interference in industrial settings.

• Fully Isolated I/O Design: RS-485 (3KV isolation), CAN (2.5KV isolation), and digital inputs (2.5KV optocoupler isolation) prevent damage to the core computing unit from ground loop currents and surges.

• Wide Voltage Input: Supports 9V~24V DC input with built-in reverse connection and overcurrent protection, adapting to unstable industrial power grids.

  

3. “Compute + Control + Communication” Trinity Architecture

Traditionally, edge deployment requires separate assembly of AI computing boards, industrial gateways, and PLC modules. The FCU3011 integrates these into a single hardware node, significantly reducing Total Cost of Ownership (TCO).

• Multi-Sensor Access: Equipped with 4 independent Gigabit Ethernet ports and 4 USB interfaces for direct connection of multiple HD industrial cameras or 3D LiDAR units.

• Physical Layer Control: Built-in 2 relay outputs (supporting 5A 30VDC) and 2 isolated inputs allow AI algorithms to directly trigger external actuators, enabling millisecond-level local closed-loop control.

• High-Bandwidth Connectivity (5G / Wi-Fi): Features an M.2 expansion slot for optional Quectel 5G/4G cellular modules or dual-band Wi-Fi, completing the final step for edge data backhaul and cloud OTA.

  

Technical Specifications

Typical Application Scenarios

• Industrial Machine Vision: Defect detection (AOI), workpiece positioning, production line safety behavior analysis.

• Autonomous Mobile Robots (AGV/AMR): Real-time SLAM mapping, obstacle avoidance algorithm acceleration, onboard main control.

• Smart Traffic & Cities: Roadside Unit (RSU) for edge computing, real-time V2X data fusion processing.

• Medical & Commercial Equipment: Portable ultrasound/imaging-assisted diagnosis, intelligent retail terminals.

  

Developer & Enterprise Customization Support

To accelerate customer product time-to-market, Forlinx Embedded provides a complete engineering development kit for the FCU3011.

• Comprehensive Documentation & Examples: Includes 3D assembly drawings, interface test routines, and out-of-the-box CUDA algorithm development examples.

• Customization Services: Supports deep customization for enterprise clients, including boot logo modification, firmware customization, and one-click system image backup & batch distribution (supports fast flashing via OTG or USB drive).

Learn More & Sample Application

The FCU3011 is now officially available for ordering. To obtain detailed technical documentation, inquire about pricing, or apply for a test sample, please visit the official FCU3011 product page or contact our sales engineers.

Data Scarcity: The Defining Bottleneck and Market Driver for Embodied AI

Embodied intelligence has become a core direction for extending artificial intelligence into the physical world. With continuous advancements in robotics, motion control, and embodied large models, the industry is poised to enter the stage of large-scale commercial implementation. Unlike traditional large models that rely on textual data, embodied intelligence depends on multi-modal data from the physical world—such as vision, tactile feedback, and motion trajectories—to achieve autonomous decision-making and scenario generalization.

Currently, the industry faces an imbalance characterized by ''mature hardware but data scarcity.'' The global shortage of high-quality real-world training data exceeds 99%. Moreover, existing data suffers from issues such as temporal misalignment, limited scenarios, and inconsistent labeling. Simulated data also struggles to replicate real-world conditions, severely hindering algorithm iteration and product deployment.

This significant data gap has spurred the rapid emergence of a specialized ecosystem for embodied data collection. Embedded SoC platforms with multi-modal connectivity, low power consumption, and edge-side computing capabilities (such as Rockchip's RK3572/RK3576/RK3588 series) are becoming critical foundational enablers for all-scenario data collection.

Five Key Development Trends in Embodied Intelligence Data Collection for 2026

Trend 1: Shift from Teleoperated Real Robots to Lightweight Wearable Ego Collection Devices, with Miniaturization and Battery-Powered Solutions Becoming Mainstream

In the early stages, the industry relied on expensive teleoperated humanoid robots for data collection, resulting in high costs and limited production capacity. The current industry is transitioning to wearable Ego cameras, lightweight tactile gloves, and portable UMI handheld collection terminals. A single operator can now complete scenario demonstrations, enabling mass crowdsourced data collection in logistics, home environments, and industrial assembly. Terminals must be compact, fanless, low-power, and offer battery life exceeding 8 hours, placing stringent demands on chip energy efficiency.

Trend 2: Growing Demand for Multi-Modal Synchronized Collection, with Seamless Millisecond-Level Integration of Vision, IMU, Tactile Feedback, and Audio

High-quality embodied datasets require synchronized collection of four types of data: 4K ultra-wide-angle video, six-axis IMU data, 6D tactile feedback, and environmental audio. This demands chips capable of parallel multi-ISP processing, high-speed serial/USB synchronization, and local real-time timestamp alignment to prevent dataset degradation due to multi-source data misalignment. Traditional low-end single-camera processing chips can no longer meet these requirements.

Trend 3: Edge AI Preprocessing, with Hardware Performing Keypoint Extraction, Image Denoising, and Preliminary Labeling Locally

Previously, data cleaning and pose recognition relied entirely on cloud servers, incurring significant transmission bandwidth costs. Next-generation data collection terminals now require local NPUs to execute real-time preprocessing tasks, such as human keypoint detection using YOLO-POSE, object detection, and AI-based image denoising. Only structured features are uploaded instead of raw video, substantially reducing storage and bandwidth costs. Chips with dedicated, high-performance NPUs are becoming a standard requirement.

Trend 4: Cost-Effective Embedded Solutions Become Mainstream, Driven by Global Supply Chains and Cost Efficiency

Traditional dedicated collection hardware, with its high initial investment, limited the scalability of data collection. To overcome this, robotics developers worldwide are rapidly adopting more cost-effective and architecturally open SoC platforms. For example, Rockchip's full range of industrial-grade chips offers comprehensive open-source SDKs, mature multi-camera synchronization solutions, and customizable encryption and security mechanisms (adaptable to data compliance and privacy protection requirements across different global regions). This approach can reduce overall BOM costs by 40%–60% and is becoming the foundational blueprint of choice for major hardware developers globally.

Trend 5: Integrated Hardware-Software Delivery Becomes the Industry Standard, with Chip Platforms Providing Complete Data Pipeline Toolchains

Leading data collection companies are no longer merely selling hardware or datasets. Instead, they deliver comprehensive solutions encompassing ''collection terminals, edge processing platforms, and cloud data governance.'' Chip manufacturers are concurrently providing ISP tuning tools, NPU model conversion software, and multi-sensor synchronization software stacks, reducing terminal product development cycles by over 50%.

RK3572 / RK3576 / RK3588
Core Specifications and Suitability for Data Acquisition Scenarios

How Forlinx Embedded Empowers Embodied Intelligence?

Forlinx Embedded leverages its full-stack hardware capabilities to deeply empower the end-to-end data acquisition pipeline for embodied intelligence.

ISP Capabilities:

Forlinx Embedded has established its own darkroom laboratory to support ISP camera tuning, adapting to the complex real-world data collection needs of embodied intelligence. It supports a wide range of edge AI applications, including AI-HDR, intelligent picture quality optimization (AI-PQ), super-resolution (AI-SR), intelligent noise reduction, sharpening, contrast adjustment, defogging, distortion correction, and 3DNR. Through hardware and software co-design, it enhances imaging and audiovisual experiences, catering to various AIoT intelligent devices.

GMSL Camera SerDes (Serializer/Deserializer) Tuning:

Forlinx Embedded offers mature GMSL SerDes extension solutions. The team has completed adaptation and joint tuning for multiple GMSL camera links, possessing mature mass-production capabilities. This helps customers rapidly complete debugging, shorten mass-production cycles, and meet the demand for robots to perform long-distance, high-definition, and highly synchronized data acquisition.

Furthermore, backed by 20 years of technical accumulation, Forlinx Embedded can provide robust support for the data acquisition and broader requirements of embodied intelligence.

6. Summary

Embodied intelligence is a core direction for AI's evolution and implementation in the physical world. Although hardware technology is maturing, the significant gap in high-quality real-world data remains a critical bottleneck hindering large-scale industrial adoption. Currently, the data acquisition field is experiencing rapid growth, showing clear technological trends toward lightweight solutions, multi-modal synchronization, edge-side preprocessing, high cost-effectiveness, and full-stack delivery. Relying on cost-effective chip solutions, mature hardware/software development platforms, and edge-side visual tuning capabilities, Forlinx Embedded is committed to addressing the pain points in data acquisition and accelerating the large-scale commercial deployment of the embodied intelligence industry.

Background

During product development, a software environment is often deployed on the development board. At this stage, it's essential to synchronize this environment with other devices. Due to the cumbersome deployment process, a more efficient synchronization method is needed.

The method provided in this document uses the rsync tool to directly synchronize the user-modified file system into the update.img image.

Note: When compiling the source code, a file system image named rootfs.img is generated. This rootfs.img is ultimately packaged into update.img. If, after modifying the file system on the development board, the size of the file system is smaller than rootfs.img, this method can be used directly. However, if the size of the file system on the development board exceeds that of rootfs.img, you will need to expand rootfs.img before proceeding. For the specific method, please refer to Section 2.3.3 File System Image Expansion.

2. Implementation Steps

2.1 Compiling Rsync via Buildroot

The rsync tool can be compiled using Buildroot. This requires adding the corresponding CONFIG options in the configuration file. There are two methods to add them:

Method 1: Modifying OK3568_defconfig

Modify the buildroot/configs/OK3568_defconfig configuration file by adding the corresponding CONFIG option for compilation. The content to add is as follows:

BR2_PACKAGE_POPT=y
BR2_PACKAGE_RSYNC=y

Method 2: Menuconfig Graphical Configuration

The corresponding compilation options can also be added via the graphical configuration interface. First, it is necessary to modify the relevant compilation script.

Open the following file:

device/rockchip/common/scripts/mk-buildroot.sh

Comment out the line at approximately line 58.

Afterwards, navigate to the buildroot/output/OK3568 directory and execute a command to enter the graphical configuration interface.

forlinx@ubuntu:~/OK3568-linux-sdk5.10/buildroot/output/OK3568$ make menuconfig

Navigate to the following directory and check rsync.

Location:
│-> Target packages
│ -> Networking applications

Select <Save> to save and exit. The corresponding configuration will be saved in the .config file within the current directory.

After configuring using either of the methods described above, return to the top-level directory of the source code and execute the following command to compile Buildroot separately:

forlinx@ubuntu:~/OK3568-linux-sdk5.10$ ./build.sh buildroot

Note: For materials from version R6 and above, you need to remove or rename the rootfs.ext4 file located in the source/prebuilts/forlinx/OK3568/buildroot/ path. After doing this, execute ./build.sh buildroot to compile the file system.

After compilation is complete, you can find the corresponding executable files and dynamic libraries in the buildroot/output/OK3568/target directory. You can package the following files and directly copy and extract them into the development board’s file system.

buildroot/output/OK3568/target/bin/rsync
buildroot/output/OK3568/target/usr/lib64/libz.so.1
buildroot/output/OK3568/target/usr/lib64/libpopt.so.0
buildroot/output/OK3568/target/usr/lib64/libc.so.6
buildroot/output/OK3568/target/usr/lib64/ld-linux-aarch64.so.1

Run the following command to package the relevant files:

forlinx@ubuntu:~/OK3568-linux-sdk5.10/buildroot/output/OK3568/target$ tar cvf rsync.tar \
bin/rsync \
usr/lib64/libz.so.1 \
usr/lib64/libpopt.so.0 \
usr/lib64/libc.so.6 \
usr/lib64/ld-linux-aarch64.so.1

2.2 Deploying Rsync to the Development Board

Copy the rsync.tar file compiled and packaged using the above method to the root directory of the development board and extract it there.

The copying process is omitted here, and you can copy the file using your preferred method.

After copying the file to the root directory of the development board, directly use the tar command to extract it in the development board’s command line terminal:

root@OK3568-buildroot:/# tar xvf rsync.tar

Check the rsync version to verify whether the port was successful.

root@OK3568-buildroot:/# rsync --version
rsync version 3.2.3 protocol version 31
Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
no socketpairs, hardlinks, no hardlink-specials, symlinks, IPv6, atimes,
batchfiles, inplace, append, no ACLs, xattrs, optional protect-args,
iconv, symtimes, prealloc, stop-at, no crtimes
Optimizations:
no SIMD, no asm, no openssl-crypto
Checksum list:
md5 md4 none
Compress list:
zlibx zlib none
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

2.3 Synchronizing the File System

2.3.1 Connecting the Development Board to the Development Environment via SSH

Next, perform incremental synchronization. First, ensure that the development board and the development environment are on the same local network and that the development board can use SSH to log into the development environment (if using a virtual machine, for example VMware, please enable the network’s bridge mode). A normal login will appear as shown below:

root@OK3568-buildroot:/# ssh root@172.20.2.103 //SSH Log in to the virtual machine
root@172.20.2.103's password: //Enter password, no display
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.153.1-microsoft-standard-WSL2 x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
* Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
just raised the bar for easy, resilient and secure K8s cluster deployment.
https://ubuntu.com/engage/secure-kubernetes-at-the-edge
Expanded Security Maintenance for Applications is not enabled.
0 updates can be applied immediately.
5 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm
Last login: Tue Sep 3 11:00:07 2024 from 172.20.2.103

Potential issues:

root@OK3568-buildroot:/# rm ~/.ssh/known_hosts //Delete the.ssh/know _ hosts file under the current account
root@OK3568-buildroot:/# ssh root@172.20.2.103
The authenticity of host '172.20.2.103 (172.20.2.103)' can't be established.
ED25519 key fingerprint is SHA256:yq1ON/V/lLhkzvFJ4u9xJ3//ckdKvep3m0RSukKOTG0.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes //Select yes for the first input.

If the followings appears, it indicates that root SSH login permissions are not enabled. Modify the virtual machine’s configuration file:

forlinx@ubuntu:~$ sudo vi /etc/ssh/sshd_config

At approximately line 33, change it to the option indicated in the box.

Then restart the SSH service or reboot the virtual machine

forlinx@ubuntu:~$ sudo service ssh restart //Restart the SSH service

2.3.2 File System Synchronization

Development Environment: Mounting the File System Image

forlinx@ubuntu:~/OK3568-linux-sdk5.10$ cd rockdev
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ mkdir test //Create a directory to mount the file system
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ sudo mount rootfs.img test/ //Mount the file system image to the 'test' directory
[sudo] password for forlinx:
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ cd test/
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev/test$ ls
bin busybox.fragment data dev etc home info lib lib64 linuxrc lost+found //Mounted successfully
media misc mnt oem opt proc rockchip-test root run sbin sdcard sys tmp
udisk userdata usr var
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev/test$ pwd
/home/forlinx/OK3568-linux-sdk5.10/rockdev/test //Copy the mount path, which you will need later.

Development board: synchronizing file systems into the development environment.

root@OK3568-buildroot:/# rsync -avx / root@172.20.2.103:/home/forlinx/OK3568-linux-sdk5.10/rockdev/test
// The IP address here is the IP of the development environment, and the path is the mount path mentioned above.
root@172.20.2.103's password: //Enter password, no display
sending incremental file list
./
.cache/QtExamples/matrix-browser/QtWebEngine/Default/Cache/
...
...
... //The print information is too long and is omitted here.
usr/lib/libpopt.so.0
usr/lib/libz.so.1
var/lib/random-seed
sent 231,355 bytes received 19,619 bytes 33,463.20 bytes/sec
total size is 761,390,000 speedup is 3,033.74 //Synchronization completed

To synchronize and delete unused files, you can add the following parameter. This will compare and delete files that have been removed on the development board, also deleting them in the development environment:

rsync -avx --delete --exclude="rootfs" / root@172.20.2.103:/home/forlinx/OK3568-linux-sdk5.10/rockdev/test

Unmount the file system and package the image in the development environment:

forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev/test$ cd ..
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ sudo umount test
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ rmdir test
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ cd ..
forlinx@ubuntu:~/OK3568-linux-sdk5.10$ ./build.sh updateimg // Package the image and generate update.img

2.3.3 File System Image Expansion

If the file system runs out of space during synchronization as described above, you can expand it using the following method:

forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ sudo fsck.ext4 -f rootfs.img
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 8872/90112 files (0.1% non-contiguous), 229543/345650 blocks
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ sudo resize2fs rootfs.img 1250000
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on rootfs.ext4 to 1250000 (4k) blocks.
The filesystem on rootfs.ext4 is now 1250000 (4k) blocks long.
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ sudo mount rootfs.img test/
forlinx@ubuntu:~/OK3568-linux-sdk5.10/rockdev$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 990M 5.9M 985M 1% /run
/dev/sda3 1.6T 1.3T 271G 83% /
tmpfs 4.9G 0 4.9G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/sda2 512M 6.1M 506M 2% /boot/efi
tmpfs 990M 112K 990M 1% /run/user/1000
/dev/loop18 4.7G 808M 3.6G 19% /home/forlinx/OK3568-linux-sdk5.10/rockdev/test

Here is a dedicated explanation of the resize2fs command. Its basic usage format is as follows:

sudo resize2fs IMAGE SIZE

IMAGE is the name of the image to be modified.
SIZE is the number of blocks, where each block is 4K in size. For example:

It is recommended to expand the image only to the necessary size, as increasing the file system image will also enlarge the corresponding generated update.img.

As industrial digitalization technologies expand into overseas markets, market access barriers and compliance requirements are becoming increasingly strict. For equipment manufacturers and system integrators, compliance certification is not only a prerequisite for market access, but also a key technical indicator that directly affects project delivery times, R&D costs and supply chain stability.

Forlinx Embedded's FCU1501 Embedded Control Unit, based on the Rockchip RK3506J industrial-grade processor, has recently received three major certifications: CE, FCC, and RoHS. This indicates that the industrial gateway meets the highest international standards for electrical safety, electromagnetic compatibility, and environmental compliance. It can be seamlessly integrated as a "production-ready" subsystem into end solutions for global markets.

1. What important insights do these three prestigious certifications provide?

01 CE Certification: The mandatory gateway to the EU market

CE marking is a mandatory product safety certification scheme implemented by the European Union, covering key areas such as electromagnetic compatibility and electrical safety.

The certification of the FCU1501 Embedded Control Unit indicates full compliance with EU directives regarding safety regulations and electromagnetic performance. This certification allows the product to be sold in all 27 EU member states and in other regions that recognize the CE standard, eliminating the need for repetitive testing.

02 FCC Certification: Electromagnetic safety assurance for North America

Issued by the U.S. Federal Communications Commission, FCC certification is mandatory for electronic devices entering the North American market, with stringent standards for electromagnetic radiation control and interference immunity.

The FCU1501 has passed full lab-grade EMC validation, ensuring minimal external radiation, no interference with nearby devices, and robust internal anti-interference capabilities. Combined with industrial-grade EMC protection design, it operates reliably even in high-interference environments, providing essential qualification for North American projects.

03 RoHS Certification: A full-lifecycle Green Commitment

RoHS focuses on restricting hazardous substances in electronic products, strictly limiting six harmful components including lead, mercury, and cadmium.

The FCU1501 enforces eco-friendly standards from raw materials through production, usage, and disposal, aligning with global low-carbon trends and meeting stringent environmental requirements in sectors like healthcare, advanced manufacturing, and energy.

2. Product Profile: Engineered for High-Density Data Acquisition

The Forlinx FCU1501 is a highly integrated, low-power industrial gateway specifically tailored for multi-channel data acquisition, protocol conversion, and edge communication.

Hardware Architecture & Technical Specifications

Industrial-Grade Processor: Powered by the Rockchip RK3506J processor (3x Cortex-A7 @ 1.5GHz + 1x Cortex-M0 MCU), delivering optimized computing efficiency with ultralow power consumption.

Rich Peripheral Interfaces:

• Up to 8x RS485 isolated ports and 2x CAN FD channels for high-density sensor and controller networking.

• 2x Fast Ethernet ports (10M/100Mbps) for reliable local networking and WAN upstreaming.

• 8x DI (Digital Input) and 8x DO (Digital Output) for direct relay control and signal monitoring.

• Optional 4G Cat1 wireless communication with dual SIM card slots for seamless failover cellular backup.

Ruggedized Design: Features a robust, compact, fanless enclosure that supports wide-temperature operations from -40°C to +85°C, ensuring 24/7 reliability in harsh industrial fields.

Modern Linux Kernel: Runs on Linux 6.1, fully equipped with built-in middleware and communication protocols including Modbus RTU/TCP, MQTT, SSH, and OpenVPN.

3. How Does Pre-certification Deliver Tangible Value to Clients?

The core challenge in overseas projects lies in ''uncertainty.'' With the FCU1501’s pre-certification, compliance risks are mitigated early in the R&D phase, translating into clear engineering benefits:

Accelerated time-to-market

No need to invest months or high costs in certifying the gateway separately. Ready-to-use certifications enable rapid deployment of your complete system overseas, securing critical market windows.

Reduced selection risk, ensured long-term reliability

The FCU1501 is backed by proven EMC performance, environmental adaptability, and operational stability, minimizing project delays or rework due to non-compliance or instability.

Broader global adaptability

Whether for EU industrial automation lines, energy storage EMS, power equipment monitoring, rail transit, or smart manufacturing, the FCU1501 complies and adapts seamlessly.

4. Target Industry Applications for European & American Markets

With its highly optimized interface layout and complete international certifications, the FCU1501 Industrial Gateway perfectly matches the mainstream demand for distributed data acquisition and green energy efficiency in Global markets:

• Distributed Renewable Energy & Storage Systems (EMS/HEMS): Driven by accelerating European carbon-neutrality mandates and the rapid growth of North American commercial & industrial energy storage, the FCU1501 serves as an ideal local controller. It utilizes its 2x CAN FD and up to 8x RS485 interfaces to simultaneously ingest high-frequency data from Battery Management Systems (BMS) and Power Conversion Systems (PCS), enabling reliable local edge control and data continuation.

• Industrial IoT & Data Acquisition Lines: In manufacturing facilities or automated warehouse lines, it effortlessly bridges the gap between OT and IT—acting as an edge data-cleaning gateway that aggregates downstream sensor data from the 8x RS485 ports and upload s JSON payloads to local or cloud MES platforms under strict CE safety compliance.

• Smart Grid & Utility Monitoring: For distributed solar PV monitoring, EV charging infrastructure, and smart grids across Europe and North America, the FCU1501 leverages its wide-temperature design (-40°C to +85°C) to serve as a secure Remote Terminal Unit (RTU) or protocol converter, guaranteeing uninterrupted data pipelines in harsh outdoor and high-electromagnetic-interference environments.

• Infrastructure & Environmental Monitoring: Meeting stringent international regulatory requirements for structural health and equipment uptime, the gateway utilizes its multiple DI/DO relay interfaces for real-time monitoring of roadside equipment, environmental sensors, and remote alarm triggers, maximizing operational efficiency.

5. Building ''Compliance'' into Design DNA

At Forlinx Embedded, international standards are not an afterthought—they are the ''baseline'' aligned from the initial circuit design, PCB layout, and component selection.

By entrusting hardware compliance to Forlinx, you can focus your engineering resources on core application development and scaling global operations.

Explore the FCU1501 product page for detailed specifications and technical insights.

Forlinx Embedded has recently launched the FET3572-C, a System-on-Module (SoM) and an accompanying OK3572-C development board powered by the newly introduced Rockchip RK3572 octa-core processor. Positioned strategically between the entry-level RK3568 and the higher-end RK3576, this mid-range AIoT platform balances a highly optimized heterogeneous architecture with an aggressive selection of industrial-grade interfaces.

While the CPU cores rely on older, cost-efficient microarchitectures, the module shines in edge computing and multi-protocol gateway applications, offering an integrated 4 TOPS NPU, dual Gigabit Ethernet, native RS485 modes, and a unique DSMC parallel bus for FPGA/DSP interconnects.

Forlinx FET3572-C Specifications

Processor & Memory Topography

SoC: Rockchip RK3572 octa-core heterogeneous processor manufactured on an 8nm process

• CPU: 2x ARM Cortex-A73 cores up to 2.2 GHz + 6x ARM Cortex-A53 cores up to 2.1 GHz (split into a 4-core cluster and a 2-core cluster for DVFS)

• GPU: ARM Mali-G310V2 MC1 supporting OpenGL ES 1.1/2.0/3.2, OpenCL 3.0, and Vulkan 1.4

• NPU: In-house Neural Processing Unit delivering 4 TOPS (INT8); supports mixed-precision (INT4, INT8, INT16, FP4, FP8, FP16, BF16) and W4A16 asymmetric MAC acceleration

System Memory: 2GB, 4GB, or 8GB LPDDR5

Storage: 64GB eMMC

Technical Highlight

Downscaled Architecture, Upscaled Efficiency

Instead of packing power-hungry newer-generation performance cores, the choice of dual Cortex-A73 and six Cortex-A53 cores allows the RK3572 to hit highly efficient power targets. Actual measured data highlights a secondary standby power draw of less than 10mW, with idle power consumption hovering around 1.3W under no-load conditions. During standard 1080p video playback, consumption stabilizes at approximately 670mW. This makes the SoM an ideal candidate for fanless sealed industrial enclosures or battery-powered terminals.

DSMC Parallel Bus: Bridging the ARM-FPGA Gap

One of the most notable features of the FET3572-C is the inclusion of the DSMC (Dynamic Static Memory Controller) parallel bus. Supporting 8-bit and 16-bit transfer modes with up to 4 chip-selects (CS) and a configurable 16-bit or 32-bit address width, the DSMC bus allows the host ARM processor to communicate with an external FPGA or DSP as if it were mapping native memory. This eliminates the high latency associated with SPI or the complexity/cost of implementing a multi-lane PCIe bridge in high-frequency data acquisition systems.

Extensive Industrial Interconnects

Where general-purpose application processors require external logic or bridge chips, the FET3572-C breaks out native interfaces directly to its four 100-pin board-to-board connectors:

• Serial Protocols: Up to 12x UARTs, all of which natively support hardware Auto-Flow-Control (AFC) and RS485 mode, removing the need for software-driven direction control pins.

• Fieldbus Connectivity: 4x CAN-FD controllers compliant with standard and extended frame transmission, backed by an 8192-word receive FIFO.

• High-Speed SerDes: 3x Combo SerDes lanes configurable for PCIe 2.1, SATA 3.1, or USB 3.0 DRD.

Multimedia and Displays

The VPU supports 8K @ 30fps decoding (H.265, VP9, AV1, AVS2) and 4K encoding. It pairs with a 12MP ISP supporting up to five camera inputs (via split MIPI CSI-2 lanes). Display engines support independent dual-screen output (up to 4K@60Hz + 2K@60Hz) over HDMI 2.1, eDP 1.3, and MIPI DSI. Notably, it includes an integrated EBC (Electronic Paper Display) hardware controller supporting up to 1872×1404 resolution, expanding its use case into industrial smart signage and E-ink dashboards.

Software and Longevity Support

On the software side, Forlinx provides board support packages (BSPs) based on modern upstream stacks, including Linux 6.12 LTS, Forlinx Desktop 24.04 (Ubuntu-based), Android 16, and Debian 13. AI developers can leverage the Rockchip RKNN toolchain, which converts models directly from mainstream frameworks including PyTorch, TensorFlow, ONNX, and TFLite.

To mitigate layout migration risks, the FET3572-C is designed to be pin-compatible with the FET3576-C SoM. This allows hardware architects to scale designs up or down based on customer performance requirements without spinning a new carrier board. The SoM is available in a standard commercial grade (0°C to +80°C) and a rugged Industrial Grade (FET3572J-C, -40°C to +85°C) with a guaranteed product longevity of 10 to 15 years.

Forlinx Embedded has opened pre-orders for both the FET3572-C SoM and the full OK3572-C evaluation kit. Pricing metrics haven't been published openly but can be requested directly via the Forlinx Sales Engineers.

Related Video and Deep Dive

Meet the Forlinx FET3572-C: 8nm AIoT Platform with 4 TOPS NPU

This video provides a practical breakdown of the FET3572-C module's hardware topography, actual 8nm thermal/power efficiency under load, and its role as a mid-range bridge in the 2026 industrial hardware ecosystem.

In application scenarios such as industrial control, edge computing, data acquisition, and device collaboration, GPIO can not only be used as a general input/output interface but also handle tasks such as external event triggering, pulse counting, frequency statistics, and synchronous signal capture. Especially in scenarios involving multi-device collaboration or high-precision event detection, GPIO capture capability directly affects system response speed, event statistics accuracy, and overall real-time performance.

Based on the OKMX9596-C platform, Forlinx Embedded has verified the GPIO capture function in the Linux system. By combining kernel interrupt counting, periodic timer sampling, sysfs output, and application-layer delay statistics, an effective evaluation of GPIO interrupt frequency and response jitter has been achieved. This provides a reference solution for industrial device synchronization, external pulse acquisition, high-frequency event detection, and similar scenarios.

Application Background: The Value of GPIO Capture in High-Precision Synchronization Scenarios

In conventional systems, device synchronization can usually be achieved through network time synchronization methods such as NTP or PTP. However, in some industrial sites, local network devices, standalone acquisition systems, or environments with limited network conditions, devices may not be able to rely on standard network time synchronization solutions. In such cases, external GPIO signals can serve as a simple and reliable synchronization trigger method.

These applications place higher demands on GPIO capture. The system must not only detect edge changes but also accurately count interrupt occurrences while minimizing interrupt response latency and system scheduling jitter.

Implementation Methods for GPIO Capture

From an implementation perspective, high-precision GPIO capture can generally be classified into several categories, including GPIO interrupts, GPT input capture, and TPM input capture.

GPIO interrupt methods offer stronger versatility. When a GPIO edge is triggered, the system enters the interrupt service routine (ISR), recording events, counting, or reading timestamps within the interrupt. This method does not rely on additional hardware capture resources and has broad applicability, but its precision may be affected by factors such as system interrupt latency, task scheduling, and high-priority task occupation.

GPT input capture is a hardware capture solution. It utilizes the input capture channels of the SoC’s internal general-purpose timer. When a signal edge arrives, the hardware automatically latches the current counter value and notifies the CPU to read it. Since timestamps are directly latched by hardware, precision is higher, and jitter is lower, making it suitable for high-precision period, pulse width, and frequency measurement.

TPM input capture is similar to GPT and is typically provided by timer/PWM modules, supporting rising-edge, falling-edge, both-edge detection, input filtering, DMA, and other functions. This method also belongs to the hardware timestamp solution and is suitable for scenarios requiring high capture precision.

In the verification on the Linux A-core side of the OKMX9596-C platform, the GPIO interrupt method was prioritized for capture capability testing. This approach offers good versatility and implementation flexibility, enabling quick evaluation of the platform’s GPIO interrupt response and frequency statistics capabilities in the Linux system.

Limitations of the Traditional gpio_keys Solution

In the Linux system, the common gpio_keys driver is primarily designed for low-frequency scenarios such as button inputs. This method typically reads events via application-layer poll/read operations, making it suitable for general button presses or status inputs but not for high-frequency GPIO capture.

In high-frequency interrupt scenarios, traditional methods face three main issues: significant user-space scheduling delays; high-frequency events can easily accumulate when notified to user space one by one; and application-layer self-timing and interrupt accumulation may be affected by thread scheduling, system load, and wake-up jitter, making it difficult to accurately reflect the actual interrupt frequency.

Therefore, in high-frequency GPIO capture or high-precision synchronization scenarios, it is more appropriate to implement core counting logic in the kernel space and then have the user space read statistical results and observe end-to-end response performance.

Forlinx Implementation Approach: Interrupt Counting Only, Periodic Timer Sampling

This verification adopts the implementation method of “GPIO interrupt counting + kernel timer sampling + sysfs output.” The overall approach is as follows: After a GPIO edge triggers an interrupt, only atomic counting is performed in the ISR; a kernel timer periodically reads and clears the count value; statistical results are written to frequency variables; frequency data is output via the sysfs interface; and the application layer blocks reads events and statistics response intervals.

The core principle of this design is: Keep interrupt handling as short as possible and delegate complex statistics to periodic timers.

Driver Key Code

static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
{
    struct gpio_irq_data *data = dev_id;
    atomic_inc(&data->event_count);
    spin_lock(&data->lock);
    data->data_active = true;
    spin_unlock(&data->lock);
    wake_up_interruptible(&data->queue);
    return IRQ_HANDLED;
}
static void timeout_callback(struct timer_list *t)
{
    struct gpio_irq_data *data = from_timer(data, t, timer);
    unsigned long flags;
    int event_count;
    spin_lock_irqsave(&data->lock, flags);
    event_count = atomic_read(&data->event_count);
    if (event_count == 0) {
        data->data_active = false;
    } else {
        atomic_set(&data->event_count, 0);
        data->data_active = true;
    }
    data->status_changed = true;
    data->last_freq = event_count;
    wake_up_interruptible(&data->queue);
    spin_unlock_irqrestore(&data->lock, flags);
    mod_timer(&data->timer, jiffies + msecs_to_jiffies(data->timeout_ms));
}

In the interrupt service routine (ISR), only atomic_inc is used to increment the event count and wake up the wait queue. Complex computations, print operations, or user-space notifications are avoided within the ISR. This reduces the execution time in interrupt context and lowers system load in high-frequency input scenarios.

In the timer callback, the accumulated interrupt count is read via atomic_read, then cleared with atomic_set. Read and clear operations are protected by a spinlock to ensure no missed or duplicate counts when executed concurrently with the ISR. Subsequently, the driver writes the statistical result into last_freq and wakes up the blocked read operation.

Application-Layer Statistics: Observing End-to-End Response and Jitter

The driver-side freq provides the kernel’s statistical interrupt frequency, which is used to determine whether GPIO input events are accurately counted. To further observe system response performance, the application layer can call clock_gettime(CLOCK_MONOTONIC) immediately after each read returns to obtain a timestamp.

The time difference between two consecutive read returns reflects the actual interval between two sampling events. This interval includes end-to-end factors such as kernel timer scheduling, user-space wake-up, and application thread scheduling, making it suitable for analyzing overall system response jitter.

Application-Side Statistical Code:

while (running) {
    ret = read(fd, buf, sizeof(buf));
    if (ret < 0) { if (errno == EINTR) continue; perror("read error"); break; } if (ret == 0) continue; uint64_t now_ns = get_ns(); if (count == 0) { first_ns = now_ns; last_ns = now_ns; last_print_time = now_ns; count = 1; continue; } interval_ns = now_ns - last_ns; last_ns = now_ns; count++; if (interval_ns < min_interval) min_interval = interval_ns; if (interval_ns > max_interval) max_interval = interval_ns;
    sum_interval += interval_ns;
    if ((now_ns - last_print_time) >= 1000000000ULL) {
        double elapsed_sec = (now_ns - first_ns) / 1e9;
        double rate = count / elapsed_sec;
        double avg_interval_us = (count > 1) ?
            (sum_interval / (double)(count - 1)) / 1000.0 : 0;
        printf("[%6.2f s] events=%lu, rate=%.1f Hz, avg_interval=%.1f us, min=%.1f us, max=%.1f us\n",
               elapsed_sec, count, rate, avg_interval_us,
               min_interval / 1000.0, max_interval / 1000.0);
        last_print_time = now_ns;
    }
}

The application layer can periodically output event count, real-time rate, average interval, minimum interval, and maximum interval. By comparing the driver-side freq with the application-side statistical results, it is possible to determine whether there are interrupt losses, user-space read delays, or system scheduling anomalies.

Test Results: Achieving ~408kHz Interrupt Frequency Statistics

In tests on the OKMX9596-C platform, GPIO interrupt frequency statistics can be directly obtained by reading the sysfs node:

cat /sys/class/gpio_irq_class/gpio_irq/freq

The actual measurement results show that the frequency values obtained from multiple reads are stable at around ~408kHz, for example: 408664, 408739, 408657, 408658. This result demonstrates that the method based on kernel timer atomic sampling of interrupt counts can achieve stable statistics even in high-frequency input scenarios.

Compared to the traditional gpio_keys + application-layer polling approach, this solution reduces the path overhead of transferring each individual event to user-space, making it more suitable for high-frequency GPIO capture capability verification and event statistics in industrial scenarios. At the same time, directly outputting frequency results via sysfs facilitates quick reading by scripts, testing tools, and upper-layer applications, providing convenience for automated testing and system monitoring.

Solution Advantages

Lightweight Interrupt Handling: The ISR only performs atomic counting and necessary wake-ups, avoiding complex logic in interrupt context.

More Accurate Kernel-Side Counting: Interrupt counting is completed within the kernel, independent of real-time scheduling of user-space threads.

Stable Timer-Based Periodic Sampling: Periodic sampling and clearing via kernel timers reduce statistical errors introduced by application-layer self-timing.

Sysfs Output for Easy Integration: Frequency results can be directly read via sysfs, facilitating calls from shell, Python, C applications, or upper-layer business logic.

Adapted to Industrial High-Frequency Event Scenarios: Can be extended to applications such as external pulse counting, synchronous triggering, event capture, and industrial control input detection.

Applicable Scenarios

Industrial equipment synchronous triggering, external pulse input detection, high-frequency GPIO event statistics, multi-device synchronous acquisition, edge gateway event capture, motor/sensor/control signal frequency detection, auxiliary synchronization when network time synchronization is unavailable, industrial field status change monitoring.

For scenarios requiring further improvement in timestamp precision, this can be combined with M-core real-time processing, independent RTC, hardware capture channels, or real-time system optimization schemes to further reduce latency and jitter.

Summary

Forlinx Embedded has validated GPIO capture capabilities under the Linux system based on the OKMX9596-C platform. By combining GPIO interrupt counting, kernel timer periodic sampling, sysfs output, and application-layer delay statistics, stable statistics for high-frequency GPIO interrupt events were achieved.

This solution avoids the issues present in the traditional gpio_keys driver in high-frequency scenarios, such as large user-space scheduling delays, untimely event reading, and affected statistical accuracy. Test results show that the OKMX9596-C platform can achieve GPIO interrupt frequency statistics at the ~408kHz level, providing a referable technical path for high-precision event capture, industrial synchronous control, and edge device coordination.

In the future, Forlinx will continue to conduct technical validation and solution refinement around the industrial control, real-time processing, edge computing, and heterogeneous multi-core capabilities of the OKMX9596-C platform, providing stable, efficient, and implementable embedded platform support for more industrial intelligent devices.

In industrial control and smart IoT devices, the real-time performance, stability, and anti-interference capability of bus communication directly determine the overall reliability of the equipment. Especially in complex working conditions characterized by high loads and strong electromagnetic interference, the performance of the CAN/CAN-FD bus is a core hardware benchmark for embedded master control chips.

As Rockchip latest mid-range processor, the RK3572 integrates 4 x native CAN-FD controllers, featuring high real-time performance, high reliability, and multi-channel concurrent communication capabilities. Today, through a full suite of standardized, practical tests, this analysis comprehensively validates the real-world performance of the RK3572 CAN-FD bus.

Multi-Dimensional Validation of Native CAN/CAN-FD

The RK3572 processor is built on an advanced 8nm process and features an 8-core architecture (2×A73 + 6×A53). It is specifically designed for industrial control equipment, Industrial IoT (IIoT), and edge AI computing scenarios. Given the core requirement for stable communication in its application scenarios, the RK3572 has been specially reinforced in its communication configuration. The chip natively integrates four independent CAN-FD interfaces, supporting both CAN 2.0 and CAN-FD dual modes, making it suitable for diverse scenarios ranging from low-speed sensor data acquisition to high-speed, large-volume data transmission.

This test completes a full-scenario performance validation from core dimensions such as load throughput, real-time performance, and multi-channel concurrency.

Standardized Test Environment Ensures Credible and Authentic Data

To replicate real-world operating conditions, this test establishes a closed-loop bus test environment. The entire process is conducted without parameter optimization or special adaptations, presenting the chip’s native performance.

Test Equipment Information

CAN Performance Test

First, a series of tests were conducted on the CAN interfaces, covering six key operating conditions: single-channel independent receiving, multi-channel independent receiving, single-channel independent transmission, multi-channel independent transmission, single-channel bidirectional transceiving, and multi-channel bidirectional transceiving. The corresponding test data is as follows:

Test Conclusions:

1. Receiving capability is normal: Under bus conditions close to full load, no frame loss occurs during single-channel or dual-channel simultaneous receiving;

2. Simultaneous sending and receiving: For both single-channel and dual-channel setups at a 1:1 ratio, bus utilization can reach around 90% without any frame loss or issues such as insufficient transmit buffer space;

CAN-FD Performance Test

Next, the CAN-FD interface will be tested, following the same categories as described above. The specific test data is as follows:

Test Conclusions:

1. Receiving capability is normal: Under bus conditions close to full load, no frame loss occurs during single-channel or dual-channel simultaneous receiving;

2. Single-channel or dual-channel, 1:1 simultaneous sending and receiving, with a maximum bus utilisation of 96 per cent; no frame loss and no issues such as lack of transmission space;

3. Application Scenarios

Leveraging excellent CAN-FD bus performance, Forlinx Embedded FET3572-C SoM is widely adaptable to various high-reliability, high-real-time scenarios:

• Industrial Field: PLC industrial control terminals, motion controllers, industrial gateways, industrial robots;

• Power & New Energy: Power monitoring terminals, photovoltaic/wind power monitoring, energy storage management devices;

• AIoT Edge Computing: Edge data gateways, multi-node bus monitoring terminals.

• Intelligent Measurement & Control Equipment: Precision motion control, equipment status monitoring, industrial data acquisition terminals;

• Medical Intelligent Terminals: Medical monitoring, intelligent medical measurement and control devices.

To meet the growing demands of industrial intelligence and IoT device innovation, the Forlinx Embedded FET3572-C System-on-Module (SoM) delivers a high-performance, cost-optimized core solution for next-generation terminal devices.

Ready to accelerate your next-generation industrial design?

Forlinx Embedded FET3572-C SoM ensures outstanding CAN-FD stability and computational efficiency, powering your edge devices with robust and reliable performance. Samples are now officially available for pre-order.

• Order Evaluation Kit / Samples

• Download Product Brochure

• Contact Our Sales Engineers

As edge intelligence absorbs highly complex, concurrent workloads, standalone application processors must evolve. Modern edge infrastructure demands a compute foundation capable of deterministic control, high-throughput network ingestion, and scalable AI inference—without compromising thermal or power efficiency.

The NXP i.MX 95 applications processor architecture. (Source: NXP Semiconductors.)

Forlinx Embedded meets this demand by bridging NXP’s next-generation processing with high-performance discrete AI hardware. By combining the FET-MX9596-C System-on-Module (SoM) with the FAI-ARA240-M Edge AI Accelerator, developers gain a high-reliability, production-ready ecosystem designed to scale deployment confidently.

1. The Edge Compute Benchmark: i.MX 95 High-Performance Processing

The Forlinx FET-MX9596-C SoM unleashes the full capabilities of the NXP i.MX 95 applications processor—the performance flagship of the i.MX portfolio. Engineered for applications demanding relentless compute density and long-term software lifecycle sustainability, this hardware platform is built on a highly optimized heterogenous architecture:

• Compute Density & Multi-OS Scalability: Powered by a multi-core ARM Cortex-A55 application cluster alongside an ARM Cortex-M7/M33 real-time co-processor, enabling concurrent execution of rich OS environments (Linux/Android) alongside low-latency deterministic tasks.

• Hardware-Enforced Functional Safety: Features an independent, hardware-isolated safe-domain architecture designed to assist system-level compliance with ISO 26262 ASIL-B and IEC 61508 SIL-2 functional safety standards. This pre-engineered safety foundation isolates critical real-time sub-systems from the main application environment, guaranteeing the strict fault-containment, predictive health monitoring, and data integrity required for mission-critical industrial controllers and automated production lines.

• Next-Gen Multimedia & Visual Ingestion: Integrates an advanced 3D GPU (Arm Mali-G310) and an enterprise-grade dual ISP to orchestrate concurrent, low-latency MIPI CSI-2 camera pipelines. The platform unlocks high-bandwidth dual-display pipelines to drive premium user experiences without external bridge hardware, delivering crisp physical output through a native 4-lane MIPI DSI (supporting up to 4K @ 30 Hz or 3840x1440 @ 60 Hz) alongside an integrated dual-channel LVDS interface (up to 1080p @ 60 Hz).

2. Dynamic Co-Processing: FET-MX9596-C + FAI-ARA240-M

While the i.MX 95 features a capable native NPU for everyday edge classification, heavy multi-modal workloads and Vision-Language Models require a decoupled acceleration path.

By utilizing the high-speed PCIe Gen 3 lanes natively exposed on the OK-MX9596-C single-board computer (SBC), engineers can seamlessly integrate the FAI-ARA240-M Edge AI Acceleration Card. This synergy delivers distinct architectural advantages:

• 40 eTOPS of Dedicated AI Acceleration: Offload complex neural network inference, Large Language Models (LLMs), and transformer-based vision pipelines to the FAI-ARA240-M's discrete neural processing unit (DNPU), freeing up 100% of the i.MX 95 host CPU resources for core application logic and system orchestration.

• 10Gbps Wire-Speed Data Ingestion: The OK-MX9596-C carrier board breaks through traditional bandwidth bottlenecks by routing the processor's native 10Gbps XFI protocol directly to an on-board SFP cage, alongside dual Gigabit Ethernet ports. This enables real-world high-speed data streaming directly from network cameras or enterprise subnets into the compute fabric without packet loss.

• Optimal Performance-per-Watt Dispersal: Assign computational workloads to the most efficient hardware engine. The i.MX 95 handles real-time control, high-speed peripheral I/O, and UI graphics, while the Ara240 powers intensive deep learning models, drastically driving down system thermals.

  

  FAI-ARA240-M Edge AI Acceleration Card

3. Targeted for the Most Demanding Edge Applications

To meet the uncompromising demands of modern localized processing, Forlinx Embedded delivers a powerful edge compute ecosystem by pairing the FET-MX9596-C System-on-Module (SoM) with the FAI-ARA240-M Edge AI Accelerator. This cohesive platform shifts decision-making directly to the autonomous edge, delivering the immense performance headroom required by the industry's most rigorous sectors.

Industrial Automation and Robotics

Modern manufacturing demands the perfect convergence of high-speed vision and physical execution. The Forlinx solution addresses this by isolating mission-critical, deterministic motion control from intensive deep learning workloads. While the host processor guarantees low-latency real-time control for robotic links and industrial networks, the dedicated acceleration card powers advanced machine vision pipelines—enabling safer, smarter, and entirely synchronized automated workflows.

Smart Infrastructure and Traffic Gateways

Deploying intelligence at the local node requires exceptional compute density and uncompromised data ingestion. This platform acts as an intelligent edge aggregator, capturing and processing multi-sensor data streams in real time. By handling complex analytics and multi-object tracking locally, the solution eliminates cloud-dependency bottlenecks, ensuring robust connectivity, rich localized graphical insights, and true edge autonomy for smart transit networks.

Next-Generation Medical Devices

In healthcare environments, absolute operational uptime and advanced data processing are paramount. The high-performance architecture of this dual-processor combination enables sophisticated high-resolution imaging, complex diagnostic analytics, and highly responsive user interfaces. It provides medical equipment developers with a stable, long-lifecycle foundation where data integrity and fluid visual interaction are guaranteed.

In these environments, performance, reliability, and architectural flexibility are not luxuries—they are prerequisites. The Forlinx i.MX 95 and Ara240 edge compute platform is designed to meet these challenges head-on, empowering engineering teams to move swiftly from concept to market deployment.

Production-Ready Developer Ecosystem

Forlinx Embedded bridges the gap between evaluation and market entry. Backed by an annual production capacity of one million units, Forlinx ensures long-term hardware availability and industrial-grade build quality. The FET-MX9596-C platform arrives with comprehensive, developer-vetted Board Support Packages (BSPs) based on modern Linux kernels, detailed hardware reference documentation, and direct engineering support to expedite your prototyping-to-production pipeline.

4. Accelerate Your Next-Generation Edge Solution

The OK-MX9596-C Evaluation Kit is available now to support rapid software bring-up, peripheral prototyping, and early-stage benchmarking. Pair your design with the FAI-ARA240-M Acceleration Card to realize the true limits of high-performance edge intelligence.

• Explore the FET-MX9596-C SoM & Development Board Specifications
• Review the FAI-ARA240-M Edge AI Accelerator Technical Sheet
• Contact a Forlinx Systems Engineer / Request an Evaluation Unit

In application scenarios such as robotics, AGVs, industrial inspection, and spatial perception, depth cameras provide capabilities like distance sensing, depth map acquisition, object recognition assistance, and environmental modeling for devices. This article, based on the OK3588-C development board, introduces the method for adapting the Orbbec DCW2 depth camera in a Linux + ROS1 environment. It compiles a complete workflow covering environment setup, SDK compilation, camera startup, and image data acquisition.

Primarily intended for developers needing to integrate Orbbec depth cameras on the RK3588 platform, this serves as a reference for depth camera adaptation in ROS1 environments.

I. Adaptation Background

The Orbbec DCW2 is a depth camera that requires control via the official Orbbec SDK. To achieve depth map and RGB image capture on the RK3588 platform, corresponding software environment setup, SDK compilation, and ROS topic verification are necessary.

The system environment selected for this adaptation is as follows:

Ubuntu 20.04

ROS1 Noetic

OrbbecSDK-ROS1

Linux 6.1.118 Preempt-RT

Please note that this article has been verified based on the above environment and has not yet undergone complete testing on other Ubuntu versions, ROS versions, or hardware platforms.

II. Testing Environment

Hardware Environment

Development Board: OK3588-C

Processor: Rockchip RK3588

Memory/Storage: 8GB RAM + 64GB eMMC

Camera: Orbbec DCW2 Depth Camera

Software Environment

Kernel：Linux 6.1.118 Preempt-RT

Ubuntu：20.04

ROS：ROS1 Noetic

SDK：OrbbecSDK-ROS1

III. Overall Adaptation Approach

There are two methods for adapting:

• 1. Installing and compiling directly on the board
• 2. Pre-installing ROS and the OrbbecSDK on the host machine by mounting the Ubuntu rootfs image via QEMU

During practical operations, the method can be chosen based on the development environment.

Compiling directly on the board is a more straightforward process but requires attention to permissions, network, and system resource usage.

Pre-installing via QEMU on the host machine allows for generating a pre-integrated image with ROS and the OrbbecSDK, facilitating reuse and batch deployment later.

This document adopts the second method: mounting the Ubuntu rootfs image via QEMU, pre-installing ROS1 and the OrbbecSDK on the host machine, and ultimately generating a pre-installed environment image.

The advantages of this method are:

• Reducing the time spent repeatedly installing dependencies on the board.
• Facilitating the generation of reusable system images.
• Suitability for repeated testing and environment stabilization.
• Avoiding compilation failures due to insufficient resources on the board.

IV. Environment Preparation

Whether installing on the board or pre-installing on the host, ensure the system network is functioning properly.

If encountering DNS resolution issues, you can temporarily modify the nameserver:

echo "nameserver 222.222.202.202" > /etc/resolv.conf

Afterward, update the system resources:

sudo apt-get update
sudo apt-get upgrade -y

Install lightdm:

sudo apt-get install lightdm

V. Installing ROS1 Noetic

This installation of ROS1 Noetic utilizes the FishROS one-click installation script:

wget http://fishros.com/install -O fishros && . fishros

Note: During the installation process, ensure you select ROS1 and do not mistakenly choose ROS2.

After installation, perform a simple verification with the following commands:

which rosdepc && sudo rosdepc init && rosdepc update

If no significant errors appear, it indicates that the basic ROS1 environment has been successfully installed.

VI. Installing Dependencies for OrbbecSDK-ROS1

Before compiling OrbbecSDK-ROS1, you need to install the necessary dependencies:

sudo apt install libgflags-dev ros-noetic-image-geometry ros-noetic-camera-info-manager ros-noetic-image-transport-plugins ros-noetic-compressed-image-transport ros-noetic-image-transport ros-noetic-image-publisher libgoogle-glog-dev libusb-1.0-0-dev libeigen3-dev ros-noetic-diagnostic-updater ros-noetic-diagnostic-msgs libdw-dev libuvc-dev

These dependencies primarily include:

• ROS image transport and processing components;
• Camera information management components;
• Libraries for USB device access;
• Logging and diagnostic libraries;
• Support for OpenCV and ROS image bridging.

VII. Obtaining OrbbecSDK-ROS1 Source Code

Create a ROS workspace:

mkdir -p ~/ros_ws/src
cd ~/ros_ws/src

Extract the prepared source code package (from the main branch) of OrbbecSDK-ROS1 into this directory:

unzip OrbbecSDK_ROS1-main.zip
mv OrbbecSDK_ROS1-main OrbbecSDK_ROS1

Notes:

• It is recommended to use the main branch for development; otherwise, you may encounter issues like ''No device found;''

• To ensure consistent testing results, it's advised to use a verified source code version to avoid changes in compilation or runtime behavior due to upstream source updates.

VIII. Compiling OrbbecSDK

Navigate to the ROS workspace:

cd ~/ros_ws

If compiling on an RK3588 board, it is recommended to use single-threaded mode:

catkin_make -j1 -l1

During testing, it was observed that compiling on the board without limiting the number of threads might lead to compilation failures. Initial analysis suggests this may be related to memory usage; therefore, using single-threaded compilation is advised to improve compilation stability.

If compiling on a host machine (e.g., a PC), you can simply run:

catkin_make

However, it is recommended that the host machine have at least 12GB of free memory to avoid resource shortages during compilation.

IX. Loading Environment and Installing udev Rules

After compilation, load the ROS workspace environment:

source ~/ros_ws/devel/setup.bash

Navigate to the Orbbec camera package directory:

roscd orbbec_camera

Install the udev rules:

sudo bash ./scripts/install_udev_rules.sh

After installation, you must reconnect the camera (unplug and plug it back in) for the udev rules to take effect.

For convenience in subsequent use, you can add the environment variable to your bashrc:

echo "source ~/ros_ws/devel/setup.bash" >> ~/.bashrc

X. Launching the DCW2 Camera

Before launching the camera on the board, load the environment:

source ~/ros_ws/devel/setup.bash

Launch the DCW2 camera:

roslaunch orbbec_camera dabai_dcw2.launch

If the launch is successful, it indicates that OrbbecSDK-ROS1 can recognize and interface with the DCW2 camera.

XI. Checking Camera Data

Open another terminal and load the environment:

source ~/ros_ws/devel/setup.bash

Check the ROS topic list:

rostopic list

Check the depth image frame rate:

rostopic hz /camera/depth/image_raw

Check the depth image data:

rostopic echo /camera/depth/image_raw -n1 | head -20

You can also use RViz to view the image:

rviz

In RViz, select:

Add → By topic → /camera/depth/image_raw/Image

This will display the depth image.

XII. Exporting Depth Images in PNG Format

During debugging, it's often necessary to save depth images for analysis. You can use the following Python script to subscribe to the ROS depth image topic and export both the raw depth image and a visualized version.

import rospy
import cv2
import numpy as np
from sensor_msgs.msg import Image
from cv_bridge import CvBridge
def callback(msg):
    bridge = CvBridge()
    # Convert to a 16-bit depth image, preserving the original depth data
    raw_depth = bridge.imgmsg_to_cv2(msg, desired_encoding="16UC1")
    # Save the raw depth image for subsequent measurement and analysis
    cv2.imwrite("depth_raw.png", raw_depth)
    # Generate a visualized depth image for easier direct viewing on a computer
    viz_depth = cv2.normalize(raw_depth, None, 0, 255, cv2.NORM_MINMAX, dtype=cv2.CV_8U)
    cv2.imwrite("depth_visual.png", viz_depth)
    print("Depth images saved.")
    print("Raw depth image: depth_raw.png")
    print("Visualized depth image: depth_visual.png")
    rospy.signal_shutdown("Task completed")
if __name__ == '__main__':
    rospy.init_node('save_depth_image')
    rospy.Subscriber('/camera/depth/image_raw', Image, callback)
    rospy.spin()

After running, two files will be generated:

depth_raw.png: The original 16-bit depth image, usable for distance measurement and data analysis;

depth_visual.png: The visualized depth image, easier for directly perceiving depth variations.

XIII. Exporting RGB Images

If you need to save RGB images, you can subscribe to the /camera/color/image_raw topic:

import rospy
import cv2
from sensor_msgs.msg import Image
from cv_bridge import CvBridge
def callback(msg):
    bridge = CvBridge()
    # Convert the ROS image message to OpenCV format
    cv_image = bridge.imgmsg_to_cv2(msg, desired_encoding="bgr8")
    # Save the RGB image
    cv2.imwrite("rgb_image.jpg", cv_image)
    print("RGB image saved as rgb_image.jpg")
    rospy.signal_shutdown("Save completed")
if __name__ == '__main__':
    rospy.init_node('save_rgb_image')
    rospy.Subscriber('/camera/color/image_raw', Image, callback)
    rospy.spin()

After running, you will get:

rgb_image.jpg

XIV. Notes During the Adaptation Process

1. Ubuntu Version Selection

Ubuntu 20.04 was chosen for this verification primarily to match the ROS1 Noetic environment.

2. Recommend Installing ROS1 First, Then OrbbecSDK-ROS1

From this verification, OrbbecSDK-ROS1 has dependencies on the ROS1 environment. Therefore, it is recommended to complete the ROS1 installation before proceeding with the compilation and configuration of OrbbecSDK-ROS1.

3. Recommend Using the main Branch Source Code

During testing, it was found that not using the main branch could lead to device recognition issues. Hence, it is advised to use the main branch source code for development and verification.

4. Recommend Limiting Threads When Compiling on the Board

When compiling on the RK3588 board, it is recommended to use:

catkin_make -j1 -l1

This reduces memory pressure and increases the success rate of compilation.

5. udev Rules Should Be Installed in the Actual Runtime Environment

The udev rules should be installed on the board in its actual runtime environment. After installation, reconnect the camera for the rules to take effect.

XV. Summary

This document details the adaptation and verification of the Orbbec DCW2 depth camera on the OK3588-C platform within a Linux 6.1.118 Preempt-RT + Ubuntu 20.04 + ROS1 Noetic environment.

Using OrbbecSDK-ROS1, we achieved camera launching, depth image data acquisition, RGB image capture, and visualization in RViz. This solution provides reference value for fields including robotics, AGVs, industrial visual inspection, and spatial perception.

Through adaptation, the RK3588 platform demonstrates strong edge visual processing capabilities. When combined with the ROS ecosystem and depth cameras, it offers a robust development foundation for applications such as depth perception, visual recognition, spatial distance measurement, and multi-sensor fusion.

Edge AI is now in a phase where large language models are closely integrated with multimodal perception. There is a growing demand for local real-time inference, low-latency responses, and compliance with data security in various applications, including energy storage, industrial gateways, intelligent robotics, and video analytics. Deploying large models with over 3 billion parameters at the edge often encounters hardware limitations with mainstream industrial controllers such as the RK3588, RK3576, and RK3568. This is primarily due to their limited native NPU computing power and inadequate memory bandwidth.

To address the challenge in the industry of balancing strong business needs with limited on-device computing power, Rockchip has introduced the high-performance RK182X series computing cards designed specifically for AI applications. With the release of the RKNN3 SDK V1.0.4, these cards offer a comprehensive software support system for deploying AI models on-device. They feature significant enhancements in edge inference performance, model compatibility, functional interfaces, and inference accuracy, demonstrating high performance, adaptability, and energy efficiency. Simply plug them in to bridge the gap in computing power, ensuring stable and seamless deployment of LLM/VLM on edge devices.

01. 20 TOPS Dedicated AI Power, Supporting Up to 8B-Parameter Models for Local Inference

The RK182X series integrates multi-core RISC-V CPU and 3D stacked high-bandwidth DRAM, featuring a multi-core high-performance NPU with a peak computing power of up to 20 TOPS. It comprehensively supports multiple computational precisions from INT4 to FP16. Through high-speed PCIe/USB interfaces connecting with the main control device, it supports the inference and local deployment of large language/multimodal models ranging from 0.5B to 8B parameters, as well as traditional CNN models. Dedicated to on-device AI inference, it operates independently without occupying main control resources, providing dedicated computing power output.

02. Full Coverage of Mainstream Models, Breaking Algorithm Ecosystem Barriers

The RK182X computing card achieves full adaptation of mainstream AI algorithms, natively supporting three core model types: LLM (large language models), VLM (vision-language multimodal models), and CNN (convolutional neural networks). It covers full-scenario AI applications including natural language interaction, cross-modal image-text analysis, image classification/detection, and audio signal processing. With stable computing power scheduling and excellent inference latency, paired with a complete model compilation toolchain, it easily enables model quantization, adaptation optimization, and rapid deployment on embedded devices.

RK182X Supported Model List

03. Compatible with All Main Controls + Dual Systems, Enabling Low-Cost Smooth Computing Power Upgrades for Existing Industrial Equipment

The RK182X series computing cards are fully compatible with Rockchip's mainstream main controls such as RK3588, RK3576, and RK3568, and support both Linux/Android dual systems. They can be used via PCIe plug-and-play without requiring additional driver adaptations. Leveraging this architecture design, the product achieves cross-main-control and cross-system universality. Existing equipment in use can be upgraded with AI large model computing power without any modifications—no need to replace motherboards, alter device structures, or redo product certifications. Older edge gateways, industrial control hosts, and AI edge boxes can be iteratively upgraded into high-performance AI inference terminals at low cost, avoiding the high transformation costs and cycle losses associated with hardware generation replacement.

OK3588-C development board paired with the RK1828 computing card

The following shows a comparison of large model inference performance before and after pairing each main control platform with the RK182X computing card:

Test Parameter Description:

• Input_Tokens and New_tokens represent the number of input/output tokens, respectively.

• TPS (Tokens Per Second): The number of tokens the model can generate per second.

As a widely deployed platform, the RK3568 features a 1 TOPS integrated NPU, which is insufficient for on-device large model deployment. Its reserved PCIe interface allows the addition of 20 TOPS dedicated NPU computing power via RK1820/RK1828 accelerator cards. Existing hardware requires no modifications, enabling low-cost performance upgrades and reliable deployment of large language and multimodal models.

On the software level, Forlinx Embedded has completed in-depth driver debugging and full operator implementation verification for the entire RK182X series on both Linux and Android systems. Multiple scenarios—including industrial vision, service robots (Linux side), smart interactive all-in-ones, and commercial smart displays (Android side)—support plug-and-play functionality. A single computing card can be reused across different hardware platforms and operating systems, effectively reducing customers' inventory and post-maintenance costs. It implements an edge computing power upgrade solution characterized by ''one card fits all, revitalizing old devices.'' Based on real business scenarios considering context size and output length, please refer to the end of the document for measured on-device inference performance data of various LLM/VLM models with different parameter sizes when the RK182X computing card is paired with various RK main control platforms.

04 Energy Storage Industry: Private Knowledge Base Implementation

To address the AI-driven Q&A needs for energy storage BMS scenarios, Forlinx Embedded has developed a dedicated private knowledge base using RK3588 paired with the RK1828 accelerator card. The solution integrates ASR (speech recognition) and TTS (speech synthesis) modules, enabling fully voice-based interactions. It supports multi-level BMS equipment data queries, real-time operational status monitoring, and intelligent fault diagnosis. By accurately interpreting maintenance personnel's questions, the system facilitates continuous interactions—such as troubleshooting, data lookup, and analytical recommendations—all deployed offline at the edge without requiring internet connectivity, ensuring data locality, compliance, and security.

Core Capabilities

• Local Deployment: Data remains within the facility, meeting security and compliance requirements for power storage applications.

• Rapid Response: Edge-based large language model inference delivers a stable output speed of 60+ tokens/s for real-time fault diagnosis and data queries.

• Plug-and-Play: Enables quick knowledge base import, voice interaction, customizable MCPs, and standardized interfaces.

05 Why Choose RK182X Compute Cards?

1. Plug-and-Play

Supports PCIe/USB dual interfaces and dual systems, reducing deployment time by over 50%.

2. Full Platform Coverage

Fully compatible with RK3588/3576/3568, offering seamless performance upgrades for existing hardware.

3. Scenario-Optimized Solutions

Tailored for verticals including energy storage, industrial automation, and robotics, with full technical support.

4. Stable & Reliable

Industrial-grade quality backed by mass delivery assurance and end-to-end technical support.

The RK182X compute card series effectively addresses edge-side computational shortages, empowering cost-effective, stable, and high-speed local deployment of LLMs and VLMs.

The following are the actual performance data for on-device inference of LLM/VLM models using the RK182X computing card in conjunction with various RK controller platforms:

Ubuntu on RK3568 + RK1828 Compute Card

LLM Edge Inference Key Performance Data:

VLM Edge Inference Key Performance Data:

Ubuntu on RK3576 + RK1828 Compute Card

LLM Edge Inference Key Performance Data:

VLM Edge Inference Key Performance Data:

Android on RK3588+RK1828 Computing Card

LLM Edge Inference Key Performance Data:

VLM Edge Inference Key Performance Data:

Test Parameter Description:

• 1. The test is based on a main control SOC and an RK1820/RK1828, connected via PCIe;
• 2. TTFT: The time taken by the model to generate the first token;
• 3. TPOT: The average time required to generate each output token;
• 4. TPS: The number of tokens the model can generate per second;
• 5. The time taken for VLM's Vision and LLM was measured in separate tests;

The RK182X series computing cards will be available soon – stay tuned for updates!

As the global transition to renewable energy deepens, industries such as photovoltaics, energy storage, and EV charging infrastructure demand higher performance in real-time data acquisition, edge collaborative computing power, and industrial-grade reliability. At the recent SNEC International Photovoltaic Power Generation and Smart Energy Conference & Exhibition in Shanghai, digital evolution took center stage as the defining industry trend.

In response to this transformation, Forlinx Embedded has executed a strategic pivot, shifting from traditional hardware showcases to a dual-driven strategy centered on "SoM + Scenario Solutions." By directly targeting the digitalization pain points in key sectors—such as photovoltaics, energy storage, charging stations, and station security—Forlinx has introduced seven customized, integrated software-hardware solutions. These are designed to assist global energy providers in enhancing system stability while significantly reducing time-to-market.

Seven Scenario Solutions Empowering Full-Spectrum Energy Implementation

Forlinx Embedded has concentrated on addressing practical challenges in the industry by introducing seven customized solutions that cover the entire energy sector. These solutions include: PV monitoring and control, energy storage management, intelligent interaction, outdoor security, AI-driven vision, energy consumption management, and privatized intelligent operations and maintenance. Together, these solutions offer lightweight, easily implementable, one-stop options for upgrading the energy industry.

PV Box Transformer Monitoring Solution: Leverages the T536 SoM's "one-chip multi-core, integrated heterogeneous" technical advantages to ensure strict real-time power management. The Linux management core aggregates data and interfaces with the cloud, offering high integration and stable operation suitable for all types of box transformer monitoring scenarios.

8 x CAN-FD Battery Management Solution: Based on the T536 SoM, this solution is suitable for mid-level controllers in energy storage and new energy vehicle batteries. It supports 8 x high-speed CAN-FD parallel communication, collects core battery parameters at millisecond-level speeds, builds a comprehensive battery health assessment system, and ensures efficient, stable transmission of massive energy storage data.

Charging Pile Interaction Solution: Utilizes the LVGL graphics engine to create a smooth visual interactive interface that supports dynamic display of charging data and responsive touch control, balancing long-term low-power operation with an excellent user experience.

Low-Power Intelligent Monitoring Solution: Implements AOV low-power monitoring based on the RV1126B development board. It employs a sleep-patrol closed-loop mechanism: normal sleep, AI-triggered snapshot capture in seconds, and automatic wake-up for video recording upon anomaly detection. Integrated with an energy consumption monitoring module, it suits outdoor scenarios without mains power, balancing security and ultra-long standby.

16 x AI Vision Solution: Based on the RK3588 SoM, it efficiently processes 16 x 720P@10FPS H.264 video streams. Through hardware decoding and NPU heterogeneous acceleration, it builds an end-to-end real-time inference system. This meets high-precision edge vision demands like intelligent inspection and image analysis in energy stations, breaking through computational bottlenecks.

Energy Consumption Management Solution: The FCU2601 embedded control unit is a highly reliable, dedicated energy control unit. Solutions built with it feature low power consumption, multiple interfaces, and high protection levels, suitable for various energy data collection and intelligent control scenarios, aiding refined energy management.

Energy Storage Privatized Knowledge Base Solution: Leveraging the dual-core architecture of the RK3588 SoM and the RK1828 AI coprocessor, it establishes a purely intranet-based privatized operations platform. This enables energy storage fault diagnosis, data queries, and policy push without public network access, balancing data security with operational efficiency.

Full-Gradient Hardware Matrix Solidifies the Foundation for Industrial Intelligent Control

To support the seamless implementation of these scenario solutions, Forlinx Embedded has built a comprehensive hardware matrix leveraging mainstream platforms such as Rockchip, Allwinner, NXP, TI, and Nuvoton. The product lineup spans SoMs, development kits, industrial control boxes, edge AI computing devices, and ecosystem accessories, achieving full-gradient coverage across high-, mid-, and low-end tiers.

Industrial-Grade Reliability Commitment:

All products feature industrial-grade low power consumption, high stability, and strong anti-interference capabilities. They are suitable for complex scenarios like outdoor stations and industrial rooms, fully meeting diverse deployment needs for smart energy terminal acquisition, edge computing, and cloud management, providing solid hardware support for industrial intelligent upgrades.

Partnering with Global Energy Providers to Accelerate Intelligent Transformation

As the photovoltaic and energy storage industries accelerate their intelligent iteration, embedded technology has become the digital foundation for industry upgrades. By deeply integrating industrial-grade reliable hardware with scenario-based solutions, Forlinx Embedded provides customers with a cost-effective, rapidly implementable path toward intelligent upgrades.

If you are planning the development of the next generation of smart energy devices, please feel free to connect with us at any time.

• Product Information: Explore our Product pages to access the latest materials, datasheets, and technical documentation.

• Technical & Sales Support: Contact our sales engineering team via sales@forlinx.com to apply for a SoM/development board evaluation platform.

With the deepening integration of AIoT, intelligent edge applications are experiencing exponential growth. From real-time recognition in smart security to high-definition rendering in commercial displays, and from edge computing data processing to intelligent interactions in portable devices, the market demands greater AI computing power and multimedia processing capabilities from SoMs. Key requirements include robust edge AI inference performance, support for ultra-HD video codec, and an optimal balance between performance and power efficiency.

In response, Forlinx Embedded—a strategic partner of Rockchip—introduces the FET3572-C SoM powered by the RK3572 processor. Featuring a hardware-accelerated 4 TOPS NPU and an octa-core heterogeneous architecture backed by a comprehensive ecosystem, it delivers a versatile computing solution for edge AI scenarios, paving the way for embedded intelligence innovations.

Empowered by 4TOPS NPU for More Efficient Edge AI Inference

Equipped with a dedicated NPU offering 4 TOPS (INT8) computing power, the FET3572-C SoM addresses the critical bottlenecks of AI performance and inference speed at the edge. Its compatibility with INT4/INT8/INT16 mixed precision and frameworks such as TensorFlow and PyTorch facilitates straightforward deployment of a wide range of edge AI inference tasks.

From facial recognition in smart security to anomaly detection in industrial settings, or intelligent noise reduction in consumer electronics—the Forlinx Embedded FET3572‑C SoM enables real-time responses with its powerful computing capability. By eliminating reliance on cloud computing, it dramatically cuts data transmission costs and latency, delivering true ''local intelligence'' for edge devices.

Robust Foundation Balancing Performance and Power Consumption

Powerful AI and multimedia capabilities require a solid hardware foundation. Built on an octa-core heterogeneous architecture (2×Cortex‑A73 + 6×Cortex‑A53) and an advanced 8nm process, the board offers over 100% higher performance than previous mid-range platforms while reducing typical power consumption by more than 50%.

The dual A73 cores handle demanding AI inference and ultra-HD video processing, while the six A53 cores manage lighter tasks—ensuring peak power when needed and optimal efficiency during low loads.

Test results include an Antutu v10 score above 310,000 and standby power below 10mW, enabling support for high-performance loads like the 4 TOPS NPU and 8K codec while meeting the low-power demands of portable devices.

8K Codec: The Ultimate Ultra-HD Experience

Equipped with a high-performance multimedia unit, the board supports 8K decoding and 4K encoding across mainstream and open-source formats.

It integrates a 12 MP ISP for accurate color reproduction and supports 5 x camera input, ideal for multi‑channel capture and monitoring. With dual‑screen independent display (4K@60fps + 2K@60fps), it suits commercial displays, POS systems, digital signage, and more.

An efficient decoding architecture lowers system bandwidth and power use—delivering stunning 8K quality without compromising stability or energy efficiency.

Full-Scenario Adaptability

Beyond AI and multimedia, the board provides extensive connectivity:

• High‑speed interfaces: PCIe 2.1, dual Gigabit Ethernet
• Industrial buses: CAN‑FD, I2C
• Native support for LPDDR5/5X memory

It adapts seamlessly to smart security, commercial displays, industrial control, edge computing, and vehicle‑mounted systems—enabling everything from HD surveillance with real‑time AI analysis to local data processing and intelligent interaction.

Comprehensive Ecosystem & Support

To speed up development, the board supports Linux and Android and comes with full resources: driver source code, development manuals, and technical examples.

Backed by Forlinx Embedded's expertise, customers receive end‑to‑end support—from solution design and prototyping to mass production—helping shorten R&D cycles and accelerate time‑to‑market.

The All‑ound Edge AI Platform

As edge AI and ultra‑HD demands grow, the Forlinx Embedded FET3572‑C SoM stands out with its 4 TOPS NPU, 8K codec performance, and balanced power efficiency.

It delivers an efficient, stable, and cost‑effective core solution for upgrading intelligent devices across industries.

The FET3572‑C SoM is now open for pre‑orders. Developers and manufacturers are invited to explore collaboration—let's build more competitive intelligent products and drive the edge AI industry forward.

Shanghai, June 3, 2026 — Forlinx Embedded, a global leader in embedded System-on-Modules (SoMs) and solutions, announced today its participation in the 2026 SNEC International Photovoltaic Power Generation and Smart Energy Conference & Exhibition. This event will take place from June 3 to 5 at the Shanghai National Exhibition and Convention Center, with Forlinx exhibiting at Booth 8.1H-F375. As one of the world's most influential summits on green energy technology, this year's SNEC will focus on next-generation photovoltaic technologies and the digital transformation of renewable energy.

With the rapid increase in global demand for clean energy and distributed grid systems, the need for safety, real-time communication, and hardware-level intelligence has reached new heights. Forlinx Embedded is dedicated to providing strong foundational support for the digital energy transition through its highly reliable embedded technologies.

At this exhibition, Forlinx will showcase its dual-drive product system—“Industrial-grade Core Hardware + Fully Customized Solutions”—which targets key applications in smart energy.

• PV Substation Monitoring & Control Solution: This solution is designed for harsh outdoor industrial environments and enables high-precision intelligent data collection, local control, and remote communication. It significantly improves the operational efficiency and stability of photovoltaic power stations.
• 8 x CAN-FD Technology Demo: This demo addresses the urgent need for high-bandwidth, low-latency communication in new energy storage systems (BESS) and high-density smart grids. It showcases an industry-leading multi-channel, high-reliability bus architecture.
• LVGL Charging Pile Interactive Solution: This solution combines a modern graphical user interface (GUI) with efficient hardware acceleration to provide a smoother and more intuitive human-machine interface for new energy charging infrastructure.

"Intelligence and digitalization are essential for the widespread global adoption of renewable energy," stated a Global Spokesperson for Forlinx Embedded. "We are eager to engage with international energy leaders, system integrators, and engineering experts at the SNEC platform to discuss how innovations in embedded technology can accelerate the deployment and commercialization of smart energy solutions."

We invite partners and media from around the world to visit Booth 8.1H-F375 to experience Forlinx Embedded’s latest technological advancements and collaborate on new opportunities in green energy.

About Forlinx Embedded

Forlinx Embedded is a global technology company that specializes in the research and development, as well as manufacturing, of ARM-based embedded System on Modules (SoMs) and single-board computers (SBCs). The company is committed to providing high-quality, long-lifecycle hardware solutions for various applications, including industrial control, smart energy, medical devices, and intelligent transportation. Through continuous technological innovation, Forlinx Embedded assists clients worldwide in reducing product time-to-market and minimizing development risks.

The complexity and harshness of industrial settings have always been the ultimate test for embedded control equipment. In extreme conditions—such as drastic temperature fluctuations, intense electromagnetic interference, frequent voltage variations, and exposure to dust and moisture—ordinary devices are prone to crashes, data loss, reboots, or even damage, potentially causing system failures and immeasurable losses.

To address industrial stability challenges, the Forlinx Embedded FCU1501 control unit has undergone rigorous testing, successfully passing three core industrial-grade trials: high/low temperature resistance, thermal cycling startup, and electromagnetic compatibility (EMC). With proven reliability, it provides a solid foundation for stable industrial system operation, showcasing true industrial-grade quality.

The triple certification of the Forlinx Embedded FCU1501 is not merely a formality; it signifies a rigorous assessment of performance and precise alignment with industrial requirements.

1. High/Low Temperature Testing: Unwavering Stability in Extreme Temperatures

Industrial applications span diverse environments, from freezing outdoor enclosures and remote sites in cold regions to sweltering workshops and temperature-controlled cold storage. Such drastic temperature changes place high demands on operational stability. The Forlinx Embedded FCU1501 has passed stringent high/low temperature tests, maintaining long-term stable operation in environments ranging from -40°C to +85°C, with no crashes, lags, or performance degradation.

Whether deployed in winter conditions or operating continuously in summer heat, the FCU1501 performs reliably, ensuring responsive and efficient operation in extreme temperatures. It eliminates the risks of temperature-related failures common in ordinary devices, offering a dependable control core for outdoor, cold chain, high-temperature manufacturing, and similar scenarios.

2. Thermal Cycling Startup Test: Unfazed by Instantaneous Changes

Temperature fluctuations in industrial environments are unavoidable. Whether due to seasonal shifts between summer and winter, or sudden day-night temperature variations, such changes can cause startup failures or delays, disrupting production schedules. The Forlinx Embedded FCU1501 control unit has passed professional thermal cycling startup tests, ensuring rapid and stable boot-up even under extreme temperature differences.

Whether it’s a cold start in winter or a reboot in summer heat, the FCU1501 responds instantly—without crashes or delays—entering full operational readiness quickly. This effectively prevents production interruptions caused by startup issues and maintains continuity and efficiency in industrial workflows.

3. Electromagnetic Compatibility (EMC) Test: Reliable Communication in Strong Interference Environments

Industrial sites are often saturated with powerful electromagnetic interference sources such as frequency converters, motors, and high-voltage equipment. Such disturbances can easily lead to communication packet loss, signal instability, or system reboots, severely impacting operational reliability. The Forlinx Embedded FCU1501 control unit has passed stringent EMC testing, demonstrating strong anti-interference capability. Even in intense electromagnetic environments, it maintains stable communication—without packet loss, restarts, or failures.

Particularly suited for industries with high interference—such as power, metallurgy, petrochemicals, and rail transportation—the FCU1501 excels in resisting on-site electromagnetic disturbances. It ensures stable transmission of control signals, significantly reducing failure rates while enhancing overall system reliability and safety.

Industrial-grade Quality: Built Through Rigor, Sustained Through Commitment Supported by triple-core certification, the Forlinx Embedded FCU1501 breaks through the environmental limitations faced by embedded control devices. It is fully adaptable to demanding industrial environments—including outdoor, underground, workshop, base station, and remote field applications—delivering uninterrupted 24/7 stable operation.

Forlinx Embedded has consistently focused on the needs of industrial environments, from research and development to certification. The company adheres to strict quality standards, ensuring that each product is built with meticulous attention to detail. The Forlinx Embedded FCU1501 Embedded Control Unit guarantees equipment stability through its robust certifications, supports industrial advancements with reliable performance, and protects the consistent operation of industrial systems across various sectors.

In industrial control, motion control, machine vision, edge data acquisition, and other application scenarios, the system must not only run but also operate on time. In scenarios that require high determinism in response, standard Linux often struggles to meet strict real-time requirements related to scheduling latency and interrupt response. As a result, enhancing real-time performance on Linux platforms has become a key focus for many developers.

This article provides a comprehensive overview of the acquisition, porting, compilation adaptation, and real-time verification of the PREEMPT_RT real-time patch on the OK3588 Buildroot platform, along with actual testing processes. Real-time performance before and after applying the patch is compared using cyclictest. The results indicate that the maximum scheduling latency of the system is significantly improved in both idle and stress scenarios.

Why Do We Need PREEMPT_RT?

The standard Linux kernel is not specifically designed for strong real-time scenarios. In the traditional Linux kernel, task preemption points are limited, meaning that certain code paths cannot be interrupted by higher-priority tasks during execution. This is particularly true for critical sections, such as lock management and interrupt handling. As a result, this can lead to scheduling latency with a degree of unpredictability. For general consumer applications, this unpredictability is usually not a significant issue. However, in industrial applications that require stable response cycles and minimal jitter, this inconsistency can become a bottleneck for the system.

The primary goal of PREEMPT_RT is to modify the standard Linux kernel to improve kernel preemptibility as much as possible. This involves transforming interrupt handling, lock mechanisms, and other code paths to better align with real-time requirements. For instance, many interrupt handling processes that originally ran in non-preemptible contexts are converted into schedulable kernel threads. This change allows for finer-grained priority management and minimizes the impact of interrupt blocking on real-time tasks. According to the documentation, these transformations can significantly reduce task response latency, resulting in markedly improved real-time performance compared to the standard kernel.

How to Obtain the Real-Time Patch for the OK3588 Platform？

For the OK3588 platform, the SDK provides the PREEMPT_RT patch corresponding to the relevant version.

ls docs/rk3588/Patches/Real-Time-Performance/PREEMPT_RT/kernel-6.1/kernel-6.1.118/
0001-patch-6.1.99-rt36-on-rockckip-base-5c295c763974.patch
0002-sched-isolation-remove-HK_FLAG_TICK-for-nohz_full-fo.patch
0003-mm-Kconfig-remove-selection-of-MIGRATION-for-CMA-to-.patch
0004-ARM-configs-add-rockchip_rt.config-for-PREEMPT_RT.patch
0005-arm64-configs-optimize-latency-for-PREEMPT_RT.patch
0006-phy-rockchip-inno-usb2-Fix-DEBUG_LOCKS_WARN_ON-in-ch.patch

The path includes several patch files related to real-time performance, such as the foundational RT patch, scheduler isolation optimizations, memory configuration adjustments, additional real-time kernel configurations, and USB-related fixes, among others.

It is important to note that applying PREEMPT_RT is not a simple task of "apply one patch and you're done." Since the preemption points of the real-time patch are distributed throughout nearly the entire kernel, chip manufacturers often need to adjust some underlying drivers accordingly. Therefore, from an engineering perspective, it is more reliable and easier to implement patch sets that have already been curated by chip manufacturers or platform providers, rather than using generic upstream RT patches directly.

How to Port the Real-Time Patch to the Buildroot Kernel？

According to the workflow outlined in the documentation, porting the real-time patch for the OK3588 6.1.118

Batch Application of Patches in the Kernel Directory

First, navigate to the kernel directory and use the patch command to import the real-time patch files provided in the SDK.

for i in ../docs/rk3588/Patches/Real-Time-Performance/\
PREEMPT_RT/kernel-6.1/kernel-6.1.118/*;\
do patch -p1 -i $i; done

Supplementing and Saving the Corresponding Kernel Configuration Items

After entering the patch, you also need to add the corresponding CONFIG item.

# Must be executed, otherwise there will be problems with the compilation environment.
export ARCH=arm64
make menuconfig
make savedefconfig
# You need to select the defconfig corresponding to the SDK
cp defconfig arch/arm64/configs/OK3588-C-linux_defconfig

Operation on the menu is performed by pressing the ''/'' key to search for the PREEMPT option, then pressing 1 to enter it.

Navigate further into the submenu, select the highest real-time priority level, and proceed to compile.

Return to the Top-level SDK Directory and Perform a Full Compilation

After configuration is complete, return to the top-level SDK directory and execute ./build.sh to compile the entire system.

tips:

Encountering errors during compilation is common, as different SDKs incorporate various drivers that may not be adapted to the modifications introduced by the real-time patch.

For instance, by examining the changes made to specific functions within the real-time patch, clues about the issue can often be identified.

cd docs/rk3588/Patches/Real-Time-Performance/PREEMPT_RT/kernel-6.1/kernel-6.1.118/
grep -nr "u64_stats_fetch_begin"
cd -

As observed in the real-time patch, the function `u64_stats_fetch_begin_irq` has been completely replaced by `u64_stats_fetch_begin`. By referencing this modification from the real-time patch and making the corresponding adjustments to the driver, the compilation was successful, allowing the firmware to be flashed for testing.

Real-Time Performance Testing

Download the compressed package and place it on the development board. Execute the command `tar -xvf rt-tests-2.2.tar -C /` to extract the contents into the root directory. The `cyclictest` tool will then be available in `/usr/bin/`.

Testing Without the Real-Time Patch Applied

cyclictest -c 0 -m -t 8 -p 99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.00 0.02 0.00 1/208 3200
T: 0 ( 2749) P:99 I:1000 C: 94901 Min: 2 Act: 3 Avg: 2 Max: 43
T: 1 ( 2750) P:99 I:1500 C: 63265 Min: 2 Act: 2 Avg: 2 Max: 31
T: 2 ( 2751) P:99 I:2000 C: 47446 Min: 2 Act: 3 Avg: 2 Max: 36
T: 3 ( 2752) P:99 I:2500 C: 37956 Min: 2 Act: 3 Avg: 3 Max: 39
T: 4 ( 2753) P:99 I:3000 C: 31628 Min: 2 Act: 3 Avg: 2 Max: 42
T: 5 ( 2754) P:99 I:3500 C: 27109 Min: 2 Act: 2 Avg: 2 Max: 16
T: 6 ( 2755) P:99 I:4000 C: 23720 Min: 2 Act: 2 Avg: 2 Max: 69
T: 7 ( 2756) P:99 I:4500 C: 21084 Min: 2 Act: 2 Avg: 2 Max: 28

Testing With the Real-Time Patch Applied

No-load Test

root@OK3588-C-buildroot:/# cyclictest -c 0 -m -t 8 -p 99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 2.70 0.93 0.34 1/373 2203
T: 0 ( 1961) P:99 I:1000 C: 46702 Min: 0 Act: 0 Avg: 0 Max: 4
T: 1 ( 1963) P:99 I:1500 C: 31133 Min: 0 Act: 1 Avg: 0 Max: 6
T: 2 ( 1964) P:99 I:2000 C: 23348 Min: 0 Act: 1 Avg: 0 Max: 3
T: 3 ( 1965) P:99 I:2500 C: 18677 Min: 0 Act: 1 Avg: 0 Max: 3
T: 4 ( 1966) P:99 I:3000 C: 15563 Min: 0 Act: 0 Avg: 0 Max: 1
T: 5 ( 1967) P:99 I:3500 C: 13339 Min: 0 Act: 0 Avg: 0 Max: 1
T: 6 ( 1968) P:99 I:4000 C: 11670 Min: 0 Act: 0 Avg: 0 Max: 1
T: 7 ( 1969) P:99 I:4500 C: 10373 Min: 0 Act: 0 Avg: 0 Max: 1

Test Performance Mode

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy6/scaling_governor
cyclictest -c 0 -m -t 8 -p 99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 2.03 2.76 2.40 2/345 11678
T: 0 (11652) P:99 I:1000 C: 3968 Min: 0 Act: 1 Avg: 0 Max: 2
T: 1 (11653) P:99 I:1500 C: 2641 Min: 0 Act: 0 Avg: 0 Max: 6
T: 2 (11654) P:99 I:2000 C: 1977 Min: 0 Act: 1 Avg: 0 Max: 2
T: 3 (11655) P:99 I:2500 C: 1581 Min: 0 Act: 1 Avg: 0 Max: 2
T: 4 (11656) P:99 I:3000 C: 1315 Min: 0 Act: 0 Avg: 0 Max: 1
T: 5 (11657) P:99 I:3500 C: 1127 Min: 0 Act: 0 Avg: 0 Max: 1
T: 6 (11658) P:99 I:4000 C: 986 Min: 0 Act: 0 Avg: 0 Max: 1
T: 7 (11659) P:99 I:4500 C: 875 Min: 0 Act: 0 Avg: 0 Max: 1

Pressure Test

stress-ng -c 8 --io 2 --vm 1 --vm-bytes 1024M --timeout 1000000s &
cyclictest -c 0 -m -t 8 -p 99
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 9.48 3.99 2.84 11/365 13327
T: 0 (13232) P:99 I:1000 C: 18287 Min: 0 Act: 1 Avg: 1 Max: 7
T: 1 (13233) P:99 I:1500 C: 12192 Min: 0 Act: 1 Avg: 1 Max: 8
T: 2 (13234) P:99 I:2000 C: 9142 Min: 0 Act: 1 Avg: 1 Max: 3
T: 3 (13235) P:99 I:2500 C: 7310 Min: 0 Act: 1 Avg: 1 Max: 4
T: 4 (13236) P:99 I:3000 C: 6088 Min: 0 Act: 0 Avg: 0 Max: 6
T: 5 (13237) P:99 I:3500 C: 5219 Min: 0 Act: 0 Avg: 0 Max: 3
T: 6 (13238) P:99 I:4000 C: 4565 Min: 0 Act: 1 Avg: 0 Max: 3
T: 7 (13239) P:99 I:4500 C: 4056 Min: 0 Act: 0 Avg: 0 Max: 4

Summary

This test based on the OK3588 6.1.118 Buildroot platform demonstrates that the PREEMPT_RT real-time patch can not only be smoothly integrated into the existing SDK but also significantly improve system scheduling latency performance under idle, performance mode, and high-stress scenarios. Particularly from the cyclictest results, the maximum latency after applying the patch shows a marked decrease compared to the pre-patch state, effectively enhancing the system’s real-time determinism.

For Linux projects requiring stronger real-time capabilities, this approach holds substantial engineering and practical value.It is not merely about transforming Linux into ''another RTOS.'' Instead, it moves Linux closer to real-time scenarios while preserving its ecosystem and driver capabilities, offering a more viable technical pathway for industrial-grade applications.

Composition

The T536 has 4 GPADC controllers: GPADC0 to GPADC2 each have 10 channels, while GPADC3 has only 1 channel. The 10 channels of GPADC0 are multiplexed with the PA group IOs. GPADC1 only exposes seven channels: 0–3 and 7–9 (the other three are used internally on the SoM). All channels of GPADC2 and GPADC3 are led out.

OK536-C Development Board Interface Diagram

Sampling Rate

GPADC0 to GPADC2 channels support a maximum sampling rate of 1 MHz, while GPADC3 can reach up to 2 Mhz.

It's important to note that all channels within an ADC share this sampling rate. For instance, if the ADC is set to a 1 MHz sampling rate with four channels enabled, the effective sampling rate per channel will be approximately 250 kHz.

However, actual testing revealed that the achievable sampling rate per channel does not reach this theoretical maximum. On the SDK1.1 Rt core, the Burst Mode for a single channel can process up to 230,000 samples per second; exceeding this limit can overload the kernel. Additionally, this limitation may be influenced by kernel scheduling constraints, as later tests uncovered issues, including interrupt nesting. Furthermore, the logging during these tests relied on printk, which consumes kernel resources. If a customer requires higher sampling rates, modifications to the driver must be considered based on the specific If a customer needs higher sampling rates, driver modifications must be considered based on the specific application scenario.

Block Diagram

Data and Interrupt Registers

Data Register

High Comparison, Low Comparison

Data

Interrupt Register

High Comparison Interrupt

Low Comparison Interrupt

Data Interrupt

FIFO-Related Interrupts

Allwinner Driver Processing Flow

1. Enable data interrupts and high/low comparison interrupts.

2. In the test application, select the channel to be tested;

3. Enable the corresponding channel, and the GPADC begins conversion;

4. Once data is captured, the interrupt service routine (ISR) is triggered;

5. Within the ISR, determine whether the data is within the specified range using the high/low comparison interrupts;

6. If within the range, report an input event; otherwise, do not report.

FIFO and Burst Mode

The T536 also supports Burst Mode to acquire GPADC values. Data is first stored in the FIFO, and once a certain amount is accumulated, a FIFO interrupt is triggered.

However, there is a limitation: only one channel can be enabled in this mode. If two channels are enabled, the device cannot identify their data source unless distinguished by data range.

In this mode, the maximum achievable sampling rate is approximately 230 kHz.

Testing Procedure:

echo 0x02088004 0x00880000 > write # continuous disabled
echo 0x02088004 0x00890000 > write # continuous enable
echo 0x02088004 0x008C0000 > write # burst disabled
echo 0x02088004 0x008D0000 > write # burst enable
echo 0x0208800c 0x00071f00 > write # endable fifo

I. Background

In the deployment and maintenance of Android devices, the system upgrade solution remains a key focus for customers. Common local upgrade methods are OTA upgrades and SD/TF card flashing. The Over-The-Air (OTA) upgrade method, which is the standard for Android updates, allows for both full and incremental packages to be installed through local and network upgrades. While it offers strong functionality, there are limitations in specific situations. These limitations include the inability to roll back an upgrade after a failure and a lack of flexibility when it comes to flashing third-party or custom systems. On the other hand, SD/TF card flashing is more straightforward but requires the hardware platform to have a dedicated card slot.

To address these practical project needs, the OK3588 Android 14 platform offers a more flexible local upgrade method: U-disk upgrade via USB interface. This solution does not rely on TF/SD card interfaces and is suitable for scenarios such as on-site maintenance, offline upgrades, and rapid system recovery.

II. Core Implementation Approach

1. Enabling USB Boot in U-Boot

Before entering Recovery, it is crucial to ensure that U-Boot can recognize the U-disk and successfully boot from the USB device. Boot capability from the U-disk is confirmed when the boot logs display messages such as “Booting from USB.” The default U-Boot in the public version image mainly supports booting from TF/SD cards. If USB boot functionality is required, you must use a version of U-Boot that supports booting from U-disks. For assistance, please contact Forlinx engineers for the necessary support.

2. Recovery Support for USB Storage Flashing (Default support in public version image, no modification required)

The source code for Android 14 Recovery can be found in the directory OK3576-android14-source/bootable/recovery. The current version of the Android 14 Recovery source code supports flashing from USB storage media by default, which means that additional modifications to Recovery are usually not required. Once you enter Recovery, the system will follow the standard upgrade procedure to recognize the upgrade package and execute the flashing process.

2.1 Entering Recovery

OK3576-android14-source/bootable/recovery/recovery_main.cpp

if (usb_config != usb_state) {
if (!SetUsbConfig("none")) {
LOG(ERROR) << "Failed to clear USB config";
}
if (!SetUsbConfig(usb_config)) {
LOG(ERROR) << "Failed to set USB config to " << usb_config;
}
}
ui->SetEnableFastbootdLogo(fastboot);
auto ret = fastboot ? StartFastboot(device, args) : start_recovery(device, args, &rksdboot); //Enter recovery
if (ret == Device::KEY_INTERRUPTED) {
ret = action.exchange(ret);
if (ret == Device::NO_ACTION) {
continue;
}
}
switch (ret

2.2 Start_recovery Flashing

OK3576-android14-source/bootable/recovery/recovery.cpp

OK3576-android14-source/bootable/recovery/recovery.cpp
ui->SetBackground(RecoveryUI::INSTALLING_UPDATE);
    ui->SetProgressType(RecoveryUI::DETERMINATE);
    printf("start USB upgrade...\\n");
    ui->Print("start USB upgrade...\\n");
    if (bUpdateIDBlock)
    bRet= do_rk_firmware_upgrade(pFwPath,(void *)handle_upgrade_callback,(void *)handle_upgrade_progress_callback);   //Updating the API for firmware
    else
    bRet = do_rk_partition_upgrade(pFwPath,(void *)handle_upgrade_callback,(void *)handle_upgrade_progress_callback);
    ui->SetProgressType(RecoveryUI::EMPTY);
    if (!bRet)
    {
        prksdboot->sdboot_set_status(INSTALL_ERROR);
        ui->Print("SD upgrade failed!\\n");
    }
    else
    {
        prksdboot->sdboot_set_status(INSTALL_SUCCESS);
        printf("USB upgrade ok.\\n");
        ui->Print("USB upgrade ok.\\n");
        forlinx_clear_env_partition();
    }

III. USB Flashing Implementation and Process

1. Creating a Bootable U-disk

First, prepare a FAT32-formatted U-disk and create the upgrade medium according to the flashing rules.

In essence, this process is similar to creating a traditional SD card flashing package, but the storage medium is switched from a TF/SD card to a U-disk.

2. U-boot Booting from the U-disk and Entering Recovery

After the device powers on, the USB boot-enabled U-Boot scans various USB buses and storage devices.

scanning bus usb@fc000000 for devices... 1 USB Device(s) found
scanning bus usb@fc800000 for devices... 2 USB Device(s) found
scanning bus usb@fc840000 for devices... 1 USB Device(s) found
scanning bus usb@fc880000 for devices... 1 USB Device(s) found
scanning bus usb@fc8c0000 for devices... 2 USB Device(s) found
scanning bus usb@fc400000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found //Scan USB storage device
Scanning usb 0 ...
=== Booting from usb 0 === //Boot from USB 0 device
Minidump: init...
RESC: ‘boot', blk@0x0001f600

3. Flashing via the Update Process in Recovery

After entering Recovery, the system invokes the corresponding upgrade interfaces based on the selected upgrade mode and initiates the upgrade process.

bSDBoot = 0, sdboot_update_package=1
bSDBoot = 0, sdboot_update_package=1
enter sdboot_set_bUpdateModel !
enter sdboot_get_bSDBoot !
enter sdboot_get_bUsbBoot !
UsbBoot do_rk_mode_update
UsbBoot do_rk_mode_update
enter sdboot_set_status !
start USB upgrade...
start USB upgrade...
librkupdate_Start to upgrade firmware...
Start to upgrade firmware...
[ 16.889130][ T195] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 16.909900][ T195] usb 2-1: New USB device found, idVendor=2c7c, idProduct=0900, bcdDevice= 4.04
[ 16.909939][ T195] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 16.909955][ T195] usb 2-1: Product: RM500U-CN
[ 16.909968][ T195] usb 2-1: Manufacturer: Quectel
[ 16.909982][ T195] usb 2-1: SerialNumber: 0123456789ABCDEF
[ 16.969799][ T195] cdc_ncm 2-1:1.0: MAC-Address: 2a:fa:91:8d:90:36
[ 16.970415][ T195] cdc_ncm 2-1:1.0 usb0: register 'cdc_ncm' at usb-xhci-hcd.3.auto-1, CDC NCM (NO ZLP), 2a:fa:91:8d:90:36
[ 16.970967][ T195] option 2-1:1.2: GSM modem (1-port) converter detected
[ 16.971155][ T195] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
[ 16.971384][ T195] option 2-1:1.3: GSM modem (1-port) converter detected
[ 16.971537][ T195] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
[ 16.971780][ T195] option 2-1:1.4: GSM modem (1-port) converter detected
[ 16.971939][ T195] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
[ 16.972224][ T195] option 2-1:1.5: GSM modem (1-port) converter detected
[ 16.972365][ T195] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB3
[ 16.972613][ T195] option 2-1:1.6: GSM modem (1-port) converter detected
[ 16.972762][ T195] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB4
[ 17.253090][ T138] Freeing drm_logo memory: 2704K
[ 18.049006][ T101] rk_pcie_establish_link: 451 callbacks suppressed
[ 18.049025][ T101] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.069521][ T99] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.070269][ T101] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.090759][ T99] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.091471][ T101] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.112025][ T99] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.112680][ T101] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.133184][ T99] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.133882][ T101] rk-pcie fe170000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.154435][ T99] rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3
[ 18.470438][ T99] rk-pcie fe190000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=1
[ 18.472362][ T101] rk-pcie fe170000.pcie: PCIe Link Fail, LTSSM is 0x3, hw_retries=1
librkupdate_INFO:emmc_point-->is /dev/block/mmcblk0
librkupdate_INFO:is emmc devices...
flashSize is 61865984000
CRKUsbComm INFO m_bEmmc=1 m_ufs=0
librkupdate_INFO:CRKUsbComm-->is emmc.
librkupdate_INFO:CRKUsbComm EMMC_DRIVER_DEV_VENDOR-->/dev/vendor_storage=18
librkupdate_INFO:CRKUsbComm emmc_point-->/dev/block/mmcblk0=20
In Md5Check
[ 19.341061][ T195] rockchip-dp fded0000.edp: failed to read max link rate
[ 19.493155][ T99] rk-pcie fe190000.pcie: failed to initialize host
[ 19.498111][ T101] rk-pcie fe170000.pcie: failed to initialize host
[ 19.673244][ T195] rockchip-dp fded0000.edp: failed to read max link rate
New Md5:
61 35 33 36 39 37 32 65 63 66 65 31 31 38 35 38
34 65 35 33 37 36 63 61 33 30 63 34 66 39 36 39
Old Md5:
61 35 33 36 39 37 32 65 63 66 65 31 31 38 35 38
34 65 35 33 37 36 63 61 33 30 63 34 66 39 36 39
librkupdate_uid: 52 4F 43 4B 43 48 49 50 E1 5C A1 69 6B 7B 98 73
74 49 94 4C A3 E8 58 AB 2E B7 A9 46 A1 BE
uid: 52 4F 43 4B 43 48 49 50 E1 5C A1 69 6B 7B 98 73
74 49 94 4C A3 E8 58 AB 2E B7 A9 46 A1 BE
librkupdate_Get FlashInfo...
Get FlashInfo...
librkupdate_INFO:FlashInfo: 00 00 80 00 00 04 04 00 28 00 01
librkupdate_INFO:m_flashInfo.uiFlashSize=59000 MB, RKU_GetFlashSize=120832000 sectors
librkupdate_IDBlock Preparing...
Complete the Flashing Through the Recovery Update Process

4. Flashing Completion Prompt

RKA_SparseFile_Check entry.name=super
librkupdate_INFO:Start to check super,offset=0x1fd400,size=I64u
INFO:Start to check super,offset=0x1fd400,size=I64u
RKA_SparseFile_Check entry.name=super Done!
librkupdate_Finish to upgrade firmware.
Finish to upgrade firmware.
enter sdboot_set_status !
USB upgrade ok.
USB upgrade ok.
enter sdboot_get_status !
enter sdboot_set_status !
prksdboot->do_rk_mode_update Successful!
prksdboot->do_rk_mode_update Successful!
enter sdboot_get_bSDBoot !
enter sdboot_get_bUsbBoot !
enter sdboot_get_status !
Doing Actions succeeded.please remove the usb disk......
enter sdboot_get_bUpdateModel !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
enter sdboot_get_usb_device_path !
Flashing completion screen display is as shown in the figure.

IV. Application Value of the USB Flashing Solution

For the OK3588 Android 14 platform, the USB flashing solution is not merely a supplement to existing upgrade methods, but a more practical upgrade path better suited to project field requirements.

1. Reduced Dependence on Hardware Interfaces

It does not require reserved TF/SD card slots, making it suitable for terminal devices with limited structural space or interface resources.

2. Enhanced On-site Maintenance Convenience

Local upgrades can be performed simply using a U-disk. The operation is straightforward, suitable for after-sales maintenance and rapid system recovery in engineering environments.

3. Favorable for Custom System Deployment

In scenarios where preserving existing user data is not required, USB flashing serves as a more direct method for full system updates.

4. Facilitates Batch Deployment and Standardized Promotion

For projects requiring offline upgrades, batch delivery, or system recovery, this solution offers good replicability and promotional value.

Summary

Implementing USB local flashing on the OK3588 Android 14 platform involves establishing a USB boot link in U-Boot, enhancing the existing Android Recovery upgrade capability to create a comprehensive U-disk upgrade solution.

Compared to traditional OTA and TF/SD card flashing methods, this solution offers significant advantages in offline upgrades, on-site maintenance, structural adaptability, and system recovery efficiency.

For projects that require local upgrades, rapid recovery, and flexible deployment, USB flashing undoubtedly is a solution with greater practical engineering value.

Overview

In embedded vision projects, camera adaptation is often a critical aspect of system development. The entire process involves multiple layers of collaboration across the kernel, file system, and user-space applications—from enabling underlying drivers, configuring device trees and the kernel, to deploying IQ files, starting 3A services, and finally verifying video preview, photo capture, and video recording. For practical project development, only when this entire chain is fully functional can a camera solution be considered ''successfully adapted.''

This article outlines the adaptation process for the OV13855 camera module based on the OK1126B-S / OK1126BJ-S Linux 6.1.141 Buildroot platform. It covers the following key areas: kernel configuration, patch application, file system preparation, verification of the rkaiq service, and testing of camera functionality. This comprehensive guide serves as a reference for similar future projects.

Note: This solution is modified based on
OK1126B-S&OK1126BJ-S_Linux6.1.141_User_Materials_R1.

Specific modifications can be reviewed in the relevant documentation.

Operation Steps:

1. Kernel configuration

Verify whether the kernel includes the following configurations; add them if they are missing.Configuration file path: kernel/arch/arm64/configs/OK1126B-S-linux_defconfig

CONFIG_VIDEO_OV13855=y
CONFIG_VIDEO_TECHPOINT=y

Execute the following command in the SDK’s kernel directory to apply the corresponding patch:

patch -p1 < ov13855_tp2855.diff

2. Filesystem

Place the IQ file for the 13855 camera, ov13855_CMK-OT2016-FV1_default.json, into the /etc/iqfiles directory on the development board.
Additionally, verify whether the rkaiq process is enabled.

root@OK1126B-buildroot:~# ps -ef | grep rkaiq
root 1042 1 0 Jan24 ? 00:00:00 /bin/sh -c /usr/bin/rkaiq_3A_server 2>&1 | logger -t rkaiq_3A
root 1044 1042 0 Jan24 ? 00:00:01 /usr/bin/rkaiq_3A_server
root 1045 1042 0 Jan24 ? 00:00:00 logger -t rkaiq_3A
root 1923 1075 0 00:23 ttyFIQ0 00:00:00 grep --color=auto rkaiq

If the process is not running, you need to start the rkaiq process.

root@OK1126B-buildroot:~# /etc/init.d/S40rkaiq_3A start

Note: When executing the following statements, the OV13855 camera must be connected to the 4-lane MIPI-CSI interface on the outer side of the development board (P9), otherwise the process will not be visible.

Camera Testing

1. Check Camera Nodes

v4l2-ctl --list-devices

After running the command, the output should include the following segment:

rkisp_mainpath (platform:rkisp-vir0):
/dev/video23
/dev/video24
/dev/video25
/dev/video26
/dev/video27
/dev/video30
/dev/media3
rkisp_mainpath (platform:rkisp-vir1):
/dev/video31
/dev/video32
/dev/video33
/dev/video34
/dev/video35
/dev/video38
/dev/media4

(Where /dev/video23 corresponds to the outer camera (P9) and /dev/video31 corresponds to the inner camera (P8).)

The following steps use /dev/video23 as an example.

OK1126B Development Board Interface Diagram

2. Check Supported Formats and Resolutions

v4l2-ctl --list-formats-ext -d /dev/video23

3. Camera Preview

gst-launch-1.0 v4l2src device=/dev/video23 ! video/x-raw, format=NV12, width=640, height=480, framerate=30/1 ! waylandsink

4. Capture a Photo

gst-launch-1.0 v4l2src device=/dev/video23 num-buffers=1 ! video/x-raw,format=NV12,width=640,height=480 ! mppjpegenc ! filesink location=pic.jpg

Check whether pic.jpg is generated. You can copy it to a PC for viewing.

5. Record H.264 Video

gst-launch-1.0 v4l2src device=/dev/video23 num-buffers=100 ! video/x-raw,format=NV12, width=640,height=480 ! tee name=t ! queue ! mpph264enc ! queue ! h264parse ! qtmux ! filesink location=13855_h264.mp4 t. ! queue ! waylandsink

6. Play H.264 Video

gst-launch-1.0 filesrc location=13855_h264.mp4 ! qtdemux ! queue ! h264parse ! mppvideodec ! waylandsink

Adapting the OV13855 camera module on the OK1126B-S / OK1126BJ-S Linux 6.1.141 Buildroot platform involves several important steps. It requires not only configuring the kernel and integrating patches but also deploying the IQ file, activating the rkaiq service, and verifying functionality through V4L2/GStreamer tests. Only after completing these steps can the entire image acquisition pipeline be fully operational.

This guide emphasizes that camera adaptation goes beyond simply compiling the driver into the kernel. It is crucial to ensure that the underlying driver, image signal processor (ISP), artificial intelligence algorithms (AIQ), and user-space applications work together seamlessly. For embedded vision projects, this comprehensive approach to adaptation is more aligned with real-world development and offers greater engineering reference value.

Recently, Rockchip has officially released its new generation octa-core AIoT platform: the RK3572. It achieves a breakthrough balance between high performance, low power consumption, and comprehensive AI capabilities, providing a highly competitive computing foundation for diverse scenarios such as consumer electronics, smart hardware, industrial control, edge computing, intelligent security, and in-vehicle terminals.

As a strategic partner of Rockchip, Forlinx Embedded has taken the initiative to launch the FET3572-C System on Module (SoM) and the OK3572-C Development Board, both based on the RK3572 processor. These products are now available for pre-order. It offers a stable, mature, and quickly deployable embedded development platform, significantly reducing the time-to-market for products.

RK3572: Key Features & Advantages of the New-Gen Mid-Range AIoT Platform

1. Advanced 8nm Process: Power Halved, Performance Doubled

The advanced 8nm process integrates an octa-core architecture featuring dual-core Cortex-A73 and hexa-core Cortex-A53. Compared to the previous mid-range platform, this setup delivers over 100% better performance while reducing typical scenario power consumption by more than 50%.

The actual measured data is highly impressive (source: Rockchip official):

• Standby power at secondary state: < 10 mW, enabling fast wake-up and long battery life;

• 1080P video playback power consumption: ≈ 670 mW;

• Light 3D gaming power consumption: < 1 W;

• AnTuTu v10 score reaches 310,000+, with significant improvement in multitasking and system fluidity.

2. 4 TOPS INT8 AI Power & Full-stack AIoT Capabilities

The RK3572 integrates a 4 TOPS NPU supporting INT4/INT8/INT16/FP4/FP8/FP16/BF16 mixed precision and W4A16 asymmetric MAC operations. It is compatible with mainstream AI frameworks such as TensorFlow, Caffe, TFLite, PyTorch, ONNX, Android NN, and MXNet.

A comprehensive suite of on-device intelligent applications can be easily implemented, including:

AI‑PQ (Intelligent Picture Quality Enhancement), AI‑SR (Super-Resolution), AI‑HDR, Intelligent Noise Reduction, Speech Recognition, Image-Based Search, AI Beauty Filters, Face Recognition, License Plate Recognition, Abnormal Behavior Analysis

3. 8K Decoding + 12M ISP for a Premium Multimedia Experience

The RK3572 delivers industry-leading multimedia performance:

• Up to 8K video decoding and 4K video encoding;

• Compatible with mainstream and open-source formats;

• 12M ISP for high-pixel image processing and precise color reproduction;

• 5 x camera inputs, meeting multi-channel video capture and surveillance needs;

• Dual-screen independent display (4K@60fps + 2K@60fps);

• Ideal for POS machines, digital signage, commercial displays, and similar applications;

• Mali-G310 GPU with Vulkan 1.4 support, ensuring smooth and stable graphics rendering and interaction.

4. Comprehensive High-Speed Interfaces for Enhanced Expandability

RK3572 is equipped with a full suite of interfaces to meet demands for high-speed data transfer and industrial control:

• Storage Interfaces: eMMC 5.1, UFS 2.0, SD 3.0/MMC 4.51, FSPI, etc.
• High-Speed Interfaces: PCIe 2.1, SATA 3.1, USB DRD 3.0/2.0, dual Gigabit Ethernet, etc.
• Industrial Buses: CAN, I²C, I³C, SPI, UART, SDIO 3.0, DSMC, etc.

Whether for high‑speed data transmission, large‑capacity storage expansion, or industrial bus communication, RK3572 delivers comprehensive support.

5. LPDDR5/5X Support Ensures Stable Supply

To tackle current challenges in the industry, such as tight memory supply chains and limited compatibility, the RK3572 offers a significantly enhanced memory solution.

It features native support for high-speed LPDDR5/5X memory, which improves memory bandwidth and optimizes power efficiency, thereby boosting device performance and extending battery life. Additionally, the integrated DRAM controller supports four ranks, providing greater flexibility in response to ongoing memory shortages.

6. Complete Ecosystem for Lower Development Barriers

The RK3572 is backed by a well-established software ecosystem compatible with mainstream embedded operating systems such as Linux and Android, complete with driver source code, development documentation, and technical references.

To further streamline development, Forlinx Embedded has built on this platform with the FET3572-C SoM and the OK3572-C Development Board, which provide: Optimized system adaptation, Pre‑tuned drivers and functional integrations, One‑stop development support.

These resources significantly lower the development barrier, shorten R&D cycles, and enable customers to move rapidly from prototype design to mass‑production deployment.

The all-new RK3572 platform offers high performance, optimized power consumption, comprehensive AI capabilities, and extensive interface support. It is an excellent choice for mid-to-high-end AIoT and industrial embedded products.

We are pleased to announce that the Forlinx Embedded FET3572-C System on Module (SoM) and the OK3572-C development board are now available for pre-order. We invite customers with development, selection, or evaluation needs to contact Forlinx Embedded for detailed materials and sample support.

Preface

Zephyr is an open-source real-time operating system (RTOS) incubated by the Linux Foundation, backed by industry giants such as Intel, NXP, Nordic Semiconductor, Google, Qualcomm, Synopsys, and Meta. To date, Zephyr has evolved to the v4.x series, supporting over 700 development boards across mainstream architectures including ARM, ARM64, RISC-V, ARC, Xtensa, and x86. It features a comprehensive driver framework, a hardware description mechanism using Devicetree, and a vibrant community ecosystem.

Zephyr is not merely a replacement for traditional RTOSes; instead, it introduces cloud-era development concepts into the resource-constrained embedded world. As a next-generation foundational software, it addresses challenges such as fragmentation, security, and development efficiency. Its design philosophy emphasizes modularity, scalability, and out-of-the-box usability.

The i.MX 9352, a lightweight edge AI processor from NXP, integrates two Cortex-A55 cores and one Cortex-M33 real-time core. Its architecture is designed to balance real-time performance with complex task-handling capabilities. To help developers fully leverage the real-time capabilities of the i.MX 9352's M33 core, this article provides a comprehensive development experience using VSCode with MCUX extensions. It guides readers through validating the PWM driver for the M33 core on Zephyr, enabling quick onboarding for porting and testing Zephyr on industrial-grade SoCs.

Demo Platform: OK-MX9352-C Development Board

Why Choose Zephyr?

1.1 Advantages of Zephyr Compared to Traditional RTOS

From ''Configuring Hardware with Code'' to ''Declaring Hardware Relationships''

Traditional Pain Point: Changing an MCU pin or peripheral often requires rewriting drivers, adjusting registers, and modifying compilation options.

Zephyr's Approach: Uses a Devicetree hardware blueprint (.dts) to describe the entire hardware layout. Changing hardware only requires modifying the blueprint, leaving core application code largely untouched. The Kconfig feature menu allows graphical system configuration similar to the Linux kernel, making kernel customization as easy as ordering from a menu.

From ''Feature Implementation'' to ''Native Security and Power Design''

Traditional Pain Point: Security and low-power features are often added as afterthoughts late in a project, leading to vulnerabilities and difficult power optimization.

Zephyr's Approach: Security is foundational—from the secure boot chain and Memory Protection Unit (MPU) to cryptographic services, security is infrastructure, not just a module. Its event-driven power management framework enables predictive microampere-level power management, moving beyond empirical sleep modes.

From ''Single Firmware'' to ''Portable Software Assets''

Traditional Pain Point: Drivers written for Company A's chips often need to be completely rewritten for Company B's chips.

Zephyr's Approach: Based on a consistent device model, a driver developed once can be reused across multiple chip vendors. Protocol stacks like Bluetooth, Wi-Fi, and Matter are plug-and-play and isolated from hardware.

Result: Core code becomes inheritable, value-adding ''digital assets'' rather than disposable ''project consumables.''

1.2 Zephyr vs FreeRTOS

Zephyr and FreeRTOS both fall within the category of real-time operating systems and are both advancing deeper into the Internet of Things (IoT) domain. However, there are significant differences in their software architecture and kernel technologies.

Core Design Philosophy

System Architecture

Protocol Stacks and Functionality

Resource Footprint

(Minimum kernel image comparison for Cortex-M4, no peripherals)

Development Environment and Debugging

Based on the comparison, Zephyr has the following shortcomings:

• Steeper learning curve

• Larger resource footprint

• More complex build system

• Slightly slower context switch performance than FreeRTOS

Key Insight:

Zephyr's disadvantages are mostly concentrated in the entry phase and highly resource-constrained scenarios. Once a team establishes the workflow and the target platform has sufficient resources, these drawbacks diminish. Meanwhile, Zephyr's advantages—portability, security, and ecosystem maturity—become increasingly prominent as project complexity grows.

1.3 Zephyr Application Scenarios

Medical and Wearable Devices

Zephyr's deterministic real-time response and low-power characteristics enable applications like continuous glucose monitors and heart monitors, providing a technical path for mass-producible, medical-grade products.

Industrial Automation

Support for 10BASE-T1S and other industrial Ethernet protocols makes Zephyr well-suited for factory automation and process control. OSADL has already established quantifiable performance benchmarks for Zephyr in the industrial field.

Smart Home and Consumer Electronics

From Matter protocol support to the complete Bluetooth 5.4 stack, Zephyr is becoming a core support for the smart home ecosystem. The Arduino VENTUNO Q platform has adopted Zephyr to ensure deterministic execution of time-critical tasks.

Automotive Electronics

As automotive E/E architecture evolves towards centralization, Zephyr's modular design and memory protection mechanisms meet automotive functional safety requirements, making it an ideal choice for vehicle domain controllers.

2. Development Environment Setup (VS Code + MCUX)

2.1 Tool Preparation

It is recommended to use the NXP MCUXpresso for VS Code extension, which includes:

CMakePresets.json for one-click builds

SEGGER J-Link / LinkServer debugging support

Device Tree visualization (preview .overlay files)

Installation Steps:

1. Install VS Code.

2. Search for and install the MCUXpresso for VS Code extension in the Extensions Marketplace.

3. Follow the plugin's prompts to install west, the Zephyr SDK, and arm-none-eabi-gcc.

2.2 Project Structure

Use CMakePresets.json to manage build configurations. Each application follows a unified structure as shown below:

my_app/
├── CMakeLists.txt
├── CMakePresets.json ← Specifies BOARD and build directory
├── prj.conf ← Global Kconfig configuration
├── boards/
│ ├── imx93_evk_mimx9352_m33.overlay ← Board-level DTS overlay
│ └── imx93_evk_mimx9352_m33.conf ← Board-level Kconfig overrides
└──
src/
└── main.c

CMakePresets.json example：

{
  "configurePresets": [
    {
      "name": "debug",
      "cacheVariables": {
        "BOARD": "imx93_evk/mimx9352/m33",
        "CMAKE_BUILD_TYPE": "debug"
      }
    }
  ]
}

In VSCode, click the ''Build'' button in the bottom status bar to compile, eliminating the need for manual command entry.

3. Devicetree Overlay: The Core of Zephyr's Hardware Abstraction

Zephyr describes hardware through Devicetree, where board-specific differences are added via .overlay files, leaving the main DTSI files unmodified. This is a key design element for Zephyr's portability.

Overlay Description for an RTC Peripheral

The RTC (Real-Time Clock) is an essential peripheral in industrial and consumer electronics. In Zephyr, external RTC chips are connected via an I2C bus and are fully described in an .overlay file. The application layer can then use the unified RTC API without needing to understand the underlying hardware differences.

Taking the example of connecting an EPSON RX8010 to the i.MX93 EVK, the overlay needs to accomplish two things:

/* boards/imx93_evk_mimx9352_m33.overlay */
&lpi2c3 {
    status = "okay";
    clock-frequency =;   /* 400 kHz */
    pinctrl-0 = <&i2c3_default>;
    pinctrl-names = "default";
    rx8010: rx8010@32 {
        compatible = "epson,rx8010";        /* Matches driver binding binding */
        reg =;                       /* I2C device address */
        status = "okay";
    };
};
/ {
    aliases {
        rtc = &rx8010;                      /* pplication accesses via "rtc" alias */
    };
};

In the application code, you only need:

const struct device *rtc = DEVICE_DT_GET(DT_ALIAS(rtc));
struct rtc_time tm = { .tm_year = 125, .tm_mon = 3, .tm_mday = 20 };
rtc_set_time(rtc, &tm);
rtc_get_time(rtc, &tm);

Demonstration of Portability: If you replace the RX8010 with another RTC chip supported by Zephyr (e.g., DS3231, PCF8563), you only need to modify the compatible and reg properties in the overlay. The application code requires zero changes.

4. Driver Verification Practice

This section demonstrates a validated PWM driver example on the i.MX93 M33 core.

Example: pwm_api — Outputting PWM signals using the TPM2 controller

After importing the pwm_api project via Import Example from Repository,

The overlay only needs to declare an alias:

/* boards/imx93_evk_mimx9352_m33.overlay */
/ {
    aliases {
        pwm-test = &tpm2;
    };
};

Kconfig Configuration：

/* boards/imx93_evk_mimx9352_m33.overlay */
CONFIG_PWM=y

The test uses pwm_set_cycles() / pwm_set() to set the duty cycle, and the output waveform can be verified with an oscilloscope. The TPM (Timer/PWM Module) on i.MX93 maps directly to the Zephyr nxp,kinetis-tpm driver, requiring no custom code.

5. Common Debugging Techniques in Zephyr Development

5.1. Kconfig Configuration Check

Check debug/zephyr/.config in the VSCode project file directory. This file contains the final, merged configuration for the project.

5.2. Final Devicetree Output Check

Check debug/zephyr/zephyr.dts in the VSCode project file directory. This is the final, merged Devicetree content and is the most direct way to verify if your overlay merged successfully.

5.3. Log Level

CONFIG_I2C_LOG_LEVEL_DBG=y Enable I2C driver debug logs

5.4. ztest Test Framework

All driver examples use the ztest framework. After running, results are output via the serial port. Taking the PWM test as an example, the serial output after flashing is as follows:

*** Booting Zephyr OS build v4.1.0 ***
Running TESTSUITE pwm_basic
===================================================================
START - test_pwm_nsec
[PWM]: 0, [period]: 2000000, [pulse]: 1000000
[PWM]: 0, [period]: 2000000, [pulse]: 2000000
[PWM]: 0, [period]: 2000000, [pulse]: 0
PASS - test_pwm_nsec in 3005 ms
START - test_pwm_cycle
[PWM]: 0, [period]: 64000, [pulse]: 32000
[PWM]: 0, [period]: 64000, [pulse]: 64000
[PWM]: 0, [period]: 64000, [pulse]: 0
PASS - test_pwm_cycle in 3003 ms
===================================================================
TESTSUITE pwm_basic succeeded

Output Description:

• test_pwm_nsec: Sets the following duty cycles sequentially in nanoseconds (each maintained for 1 second):

  50% duty cycle (1.65V)

  100% duty cycle (3.3V)

  0% duty cycle (0V)

• test_pwm_cycle: Repeats the verification of the above three duty cycles in units of ''cycles,'' with period=64000 cycles and pulse widths of 32000 / 64000 / 0 cycles sequentially.

• Each [PWM] line in the output corresponds to one call to pwm_set() / pwm_set_cycles(). The actual voltage can be verified on the TPM2 output pin using an oscilloscope or multimeter.

7. Summary

Through this Zephyr porting practice on the i.MX93 M33 core, we have validated: the native Zephyr application pwm_api works on the i.MX93 M33 core.

The core value of Zephyr lies in:

1. One set of driver APIs covering all platforms — Changing the SoC only requires modifying the overlay, not the application code；

2. Devicetree-driven development — Clear separation between hardware configuration and software logic；

3. Complete testing infrastructure — ztest + testcase.yaml support CI/CD integration；

4. Native security and low-power design — Not an afterthought patch, but a system-level infrastructure；

5. Active upstream community — Over 1,600 contributors worldwide, with hundreds of merges weekly.

Forlinx Embedded OK-MX9352-C Development Board, based on NXP i.MX93, is a high-performance industrial-grade hardware platform. It demonstrates exceptional adaptability and outstanding stability with Zephyr RTOS. Leveraging Zephyr's engineering capabilities, developers can rapidly implement peripheral driver development, system porting, and functional verification on the Forlinx Embedded OK-MX9352-C development board, significantly shortening the R&D and mass production cycles of industrial products.

For teams engaged in embedded RTOS selection and industrial-grade product development, the combination of the Forlinx Embedded OK-MX9352-C Development Board + Zephyr RTOS offers an optimal solution that balances development efficiency, system security, and hardware reliability.

Forlinx Embedded OK-MX9352-C Development Board: Providing a stable, efficient, and industrial-grade hardware foundation for Zephyr implementation.

Forlinx Embedded is proud to announce its membership in SGET, a globally recognized organization dedicated to the development and promotion of open standards for embedded computing technologies.

As a long-term provider of industrial-grade System on Modules (SoMs) and Single Board Computers (SBCs), Forlinx has always believed that standardization is the foundation of scalability, interoperability, and long-term product value. Joining SGET marks another important step in our mission to deliver reliable, future-ready embedded solutions for industrial automation, transportation, medical devices, and IoT applications.

What is SGET?

The Standardization Group for Embedded Technolgies or in short SGET is an international not-for-profit association of companies and organizations that collaboratively develop independent specifications for embedded computer technology.

Founded in 2012, SGET is a registered technical, scientific and educational association organised under German law with its registered office in Gauting, close to Munich. The main purpose of SGET is to provide a platform to define and market open industry standards for embedded technologies.

Why Forlinx Joined SGET

At Forlinx, we do not simply manufacture hardware, we design platforms built for long lifecycle deployment, engineering flexibility, and ecosystem compatibility.

Joining SGET aligns perfectly with our long-term strategy for three key reasons:

1. Commitment to Open Standards

Customers increasingly demand vendor-independent solutions that reduce redesign costs and protect long-term investments. By joining SGET, Forlinx reinforces our commitment to delivering products based on internationally recognized open standards rather than proprietary architectures.

This ensures our customers benefit from easier migration paths, multi-vendor ecosystem compatibility, and lower total cost of ownership.

2. Driving Industrial Innovation

As edge AI, machine vision, and industrial IoT continue to accelerate, embedded systems require stronger standardization to support faster deployment and simplified system design.

SGET provides a collaborative platform where industry leaders shape the future of embedded standards. As a member, Forlinx can contribute directly to the evolution of next-generation embedded architectures.

3. Strengthening Global Customer Trust

As an NXP Gold Partner and a trusted provider of industrial embedded platforms across Europe and global markets, participation in SGET demonstrates Forlinx’s technical credibility and long-term commitment to high-quality engineering standards. This is not only a membership, it is also a signal of trust, reliability, and engineering responsibility.

Products Aligned with the SMARC Standard

One of SGET’s flagship standards is SMARC (Smart Mobility ARChitecture), a highly popular small form factor Computer-on-Module specification designed for low-power, high-performance embedded applications.

SMARC defines standardized module dimensions, pinouts, and carrier board interfaces, enabling developers to achieve faster time-to-market, easier scalability, and long-term upgradeability. The standard supports modules typically under 6W power consumption and offers two module sizes: 82mm x 50mm and 82mm x 80mm, using a 314-pin MXM edge connector.

Forlinx’s membership in SGET is backed by specific modules aligned with the SMARC ecosystem. Our flagship NXP i.MX 8M Plus SMARC platform includes both a high-performance SoM and a ready-to-deploy development SBC:

FET-MX8MPx-SMARC System on Module

FET-MX8MPx-SMARC System on Module is built on the NXP i.MX 8M Plus processor and fully complies with the SMARC 2.1 specification.

Key highlights include:

• 4xCortex-A53@1.6GHz + Cortex-M7@800 MHz
• 2.3 TOPS NPU & Dual Image Signal Processor for machine learning and vision applications
• Dual-band 2.4/5 GHz 2×2 Wi-Fi 5 (802.11ac) + Bluetooth 5.3
• Industrial temperature range from -40°C to +85°C
• 82mm × 50mm standard SMARC form factor
• 314-pin MXM3 edge connector
• Preloaded Linux 6.1.36 LTS software stack with BSP, drivers, and sample code

It is designed for smart cities, industrial IoT, intelligent transportation, and smart healthcare applications.

OK-MX8MPx-SMARC Single Board Computer

OK-MX8MPx-SMARC Single Board Computer is the companion development platform built around the same SMARC architecture.

It allows engineers to accelerate evaluation, prototyping, and deployment while maintaining full compatibility with the standardized module architecture. It provides a practical bridge from development to mass production for industrial-grade applications.

As embedded systems move toward higher integration, AI acceleration, and longer lifecycle requirements, standardization becomes critical. By aligning with SGET, Forlinx ensures its platforms remain interoperable, scalable, and ready for long-term industrial deployment.

Industrial digitalization relies on cross-device, cross-platform connectivity to eliminate data silos and improve operational efficiency. Yet real-world deployment faces persistent interoperability issues: protocol barriers, costly cabling, unstable signals, and legacy‑to‑new‑system gaps.

Such connection bottlenecks remain key barriers to digital transformation.

The Forlinx FCU1501 Embedded Control Unit is built to solve these challenges. Through optimized connection logic, a comprehensive interface matrix, and industrial‑grade reliability, it acts as the core enabler for seamless, efficient communication across diverse industrial devices.

Comprehensive Interface Resources Fortify the Foundation of ''Connectivity''

The core advantage of the FCU1501 Embedded Control Unit lies in its all‑dimensional interface matrix, covering wired communication, wireless communication, industrial serial ports, high‑speed buses, and digital control. Unlike gateways in the market that require add‑on expansion modules, the FCU1501 interfaces are natively integrated. This eliminates the need for complex retrofitting, enabling seamless ''integration'' of diverse industrial equipment and efficient ''interconnection'' between devices and platforms—perfectly meeting the fragmented connectivity demands of industrial sites.

For instance, in a medium‑sized manufacturing workshop with newly purchased smart PLCs, legacy inverters and meters, as well as environmental sensors, disparate protocols and incompatible interfaces previously prevented centralized data monitoring. With the deployment of the FCU1501 Embedded Control Unit, its extensive interface matrix allowed all devices to be ''integrated'' at once, achieving efficient ''interconnection'' between production data and the monitoring platform. This entirely eliminated information silos and significantly improved operational efficiency.

Stable Wired Communication Ensures Reliable Data Interconnection

In industrial environments, the stability of data transmission directly impacts production efficiency. Wired Ethernet serves as the core channel for ''connecting'' devices and data. The FCU1501 Embedded Control Unit comes standard with two industrial Ethernet ports, supporting 10/100Mbps adaptive transmission. It can automatically align with the communication requirements of different devices, enabling simultaneous ''connection'' of multiple industrial devices while ensuring efficient data interconnection between equipment, cloud platforms, and control terminals—effectively reducing latency and packet loss.

Notably, the FCU1501 is designed with three‑level EMC protection, maintaining stable communication links even in high‑electromagnetic‑interference workshop environments. With its strong anti‑interference capability, it supports 24/7 stable communication between production‑line equipment and management platforms. Connection disruptions are effectively eliminated, significantly improving the reliability of production data collection and ensuring continuous and accurate data transmission.

Scenarios

Industrial Serial Ports Bridge Legacy and New Equipment for Seamless Integration

Many older industrial sites rely on legacy devices that lack Ethernet ports and can only communicate via serial interfaces. Enabling these ''legacy devices'' to interconnect with modern intelligent systems is a key challenge in digital transformation. The FCU1501 Embedded Control Unit offers differentiated serial port configurations: a base version with 4 RS485 ports and an expanded version with 8 RS485 ports, complemented by 2 multiplexed RS232 interfaces. These can directly connect to PLCs, smart meters, inverters, and other traditional industrial terminals without additional modification.

High-Speed CAN Bus Meets High Real‑Time Requirements for Massive Data Interconnection

For applications with strict demands on data transmission speed and stability—such as rail transportation and new energy storage—the FCU1501 provides CAN bus interfaces (supporting CAN‑FD and CAN 2.0B, with isolated digital ground per channel). Options include 1 CAN interface in the base version and 2 in the expanded version, natively supporting dual protocols for high‑speed interconnection of large‑scale data.

For example, in a new‑energy storage power station, the CAN interface successfully ''connects'' battery packs with the management platform, enabling real‑time collection of voltage, current, temperature, and other battery data. This achieves high‑speed interconnection between the Battery Management System (BMS) and the monitoring platform, ensuring real‑time data transmission and fast command response—fully meeting the demands of high‑real‑time scenarios and aligning with the development trends of the new energy storage industry.

Expand and Wirelessly Adapt to Diverse Scenarios, Achieve Massive Data Interconnection

Industrial environments are complex and varied. In areas where outdoor equipment is deployed or wiring is impractical, wired connections become difficult to implement—requiring flexible wireless ''connectivity'' capabilities. The FCU1501 Embedded Control Unit is equipped with one USB 2.0 port, allowing flexible connection of external devices such as USB drives. It also features dual-band Wi-Fi and Bluetooth 5.0 as standard, with an optional 4G module to supplement wireless ''connectivity,'' making it suitable for outdoor and wiring-challenged scenarios.

For example, in smart park renovations of older factories, some outdoor monitoring devices cannot be wired, making it difficult to transmit equipment data to the management platform. With the introduction of the FCU1501 Embedded Control Unit, wireless ''interconnection'' between outdoor monitoring devices and the park management platform is achieved—eliminating the need for wiring, enabling rapid intelligent integration of park equipment, and significantly improving park management efficiency.

Digital Control Bridges Sensing and Control

Efficient operation in industrial settings relies on a closed loop of ''sensing → acquisition → control.'' The FCU1501 is equipped with comprehensive DI/DO digital interfaces (2 DI/DO in the base version, 8 DI/DO in the expanded version), enabling precise ''connection'' of on-site sensors, audible/visual alarms, valve actuators, and other equipment. It facilitates real-time acquisition of equipment status signals and output of control commands, with millisecond-level response speeds ensuring rapid ''connectivity'' between sensing and actuating devices.

In smart municipal pipeline monitoring scenarios, real-time monitoring of pipeline pressure and flow is required, alongside automatic valve control based on the monitored data. The FCU1501 uses DI interfaces to ''connect'' pipeline sensors, collecting real-time data and transmitting it to the monitoring platform. Through DO interfaces, it then ''connects'' valve actuators, realizing a closed-loop ''interconnection'' of monitoring and control. This enables automatic adjustment of pipeline pressure and flow without manual intervention, significantly reducing municipal operation costs and enhancing the intelligence level of pipeline management.

Summary | Full-Stack Independent Architecture Enables Efficient Global Interconnection

The FCU1501 Embedded Control Unit, a new-generation, fully self-developed data gateway, consistently focuses on ''connectivity'' and ''interconnection'' in industrial scenarios. Leveraging comprehensive interface resources and flexible expansion capabilities, it adapts to applications across smart manufacturing, new energy, smart municipal, and other industries. By providing stable, cost-effective connectivity solutions, it supports enterprise digital transformation and empowers global businesses to achieve efficient, wide-area interconnection.

Adaptation Background and Platform Characteristic Analysis

Adaptation Background

Currently engaged in industrial display development on the RK3588 platform running Android 14 (kernel version 6.1.99). The work involves adapting the LT9211 MIPI-to-LVDS module to support a 1280×800 LVDS screen and a GT911 touchscreen. The primary goal is to ensure stable display power-on and normal touchscreen functionality.

Platform Characteristic Analysis Before Adaptation

The Android 14 BSP for the platform incorporates a standard DRM framework for its display architecture. The integration of the MIPI DSI bridge focuses on three crucial aspects: ensuring that the driver is correctly compiled into the kernel, configuring hardware resources in the device tree to avoid conflicts, and achieving complete compatibility between the display timing and screen parameters.

Before modifications, the layered rules of the kernel configuration in the compilation environment were verified: the kernel configuration for OK3588-Android 14 consists of three files: rockchip_defconfig (chip-level), -14.config (system-level), and OK3588-C-Android.config (board-level). All board-level custom configurations must be placed in the third file to prevent overwriting during future SDK upgrades. This version compatibility rule is mandatory for industrial-grade development.

Specific Implementation Steps for Adaptation

I. Driver Layer Deployment

1. LT9211 Driver File and Makefile Configuration

The LT9211 is a MIPI-to-LVDS bridge chip from Lontium, classified as a DRM bridge driver. It must be placed in the corresponding driver directory to be correctly recognized by the framework.

Copy the lt9211.c driver file to kernel-6.1/drivers/gpu/drm/bridge, and modify the Makefile in the same directory by adding the following compilation configuration at the end to ensure the driver is compiled into the kernel image:

Complete context reference:

Makefile
27 obj-$(CONFIG_DRM_SIMPLE_BRIDGE) += simple-bridge.o
28 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
29 obj-$(CONFIG_DRM_TOSHIBA_TC358762) += tc358762.o
30 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
31 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
32 obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
33 obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
34 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
35 obj-$(CONFIG_DRM_TI_DLPC3433) += ti-dlpc3433.o
36 obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o
37 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
38 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
39 obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
40 obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
41 obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o
42 obj-y += lt8912b.o
43
44 obj-y += analogix/
45 obj-y += cadence/
46 obj-y += imx/
47 obj-y += lt9211.o

2. Kernel Configuration Modification

This adaptation is paired with a GT911 touchscreen, requiring the activation of the Goodix series touch driver in the kernel. Following the previously confirmed configuration layering rules, modify the board-level configuration file kernel-6.1/kernel/configs/OK3588-C-Android.config by adding the following:

Complete context reference:

Plain Text
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_SND_SOC_NAU8822=y
CONFIG_NET_VENDOR_INTEL=y
CONFIG_R8169=y
CONFIG_E1000E=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_RX8010=y
CONFIG_NXPWIFI=m
CONFIG_VIDEO_OV5645=y
CONFIG_USB_SERIAL_EXAR=y
CONFIG_TOUCHSCREEN_GOODIX=y

II. Device Tree Hardware Resource Configuration

The device tree modification path is kernel-6.1/arch/arm64/boot/dts/rockchip/OK3588-C-Common.dtsi. This adaptation uses the MIPI0 channel as an example. To facilitate future rollback and troubleshooting, all existing conflicting configurations are retained through commenting rather than direct deletion.

1. Addition of Touchscreen Node Definition

In the original device tree, the FT5x06 touchscreen node occupied pins required for the current GT911. The existing node was first commented out, and the GT911 interrupt and reset pin multiplexing configuration was added to prevent pin resource conflicts.

Plain Text
usb-typec {
usbc0_int: usbc0-int {
rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
};
typec5v_pwren0: typec5v-pwren0 {
rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
};
usbc1_int: usbc1-int {
rockchip,pins = <1 RK_PB3 RK_FUNC_GPIO &pcfg_pull_up>;
};
typec5v_pwren1: typec5v-pwren1 {
rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
tp_int {
gt911_dsi1_gpio: gt911-dsi0-gpio {
rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>,
<3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
/* Original ft5x06 node comment to avoid pin conflict */
/*
ft5x06_dsi0_gpio: ft5x06-dsi0-gpio {
rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>,
<3 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
};
*/
ft5x06_dsi1_gpio: ft5x06-dsi1-gpio {
rockchip,pins = <3 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>,
<3 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
};
headphone {
hp_det: hp-det {
rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
};

2. Adding Device Configuration under the I2C2 Node

Both the LT9211 and GT911 are connected to the I2C2 bus. New device node configurations are added under the &i2c2 node, while the conflicting original ft5x06 device node is commented out.

Plain Text
extio: tca6424@23 {
compatible = "ti,tca6424";
reg =;
interrupt-parent = <&gpio1>;
interrupts =;
gpio-controller;
#gpio-cells =;
interrupt-controller;
#interrupt-cells =;
pinctrl-0 = <&extio_int_gpio>;
pinctrl-names = "default";
status = "okay";
};
/* Comment out the original ft5x06 node, kept for reference */
/*
ft5x06_dsi0: ft5x06@38 {
compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
reg =;
pinctrl-names = "ft5x06_default";
pinctrl-0 = <&ft5x06_dsi0_gpio>;
interrupt-parent = <&gpio3>;
interrupts =;
// irq-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
// reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
touchscreen-size-x =;
touchscreen-size-y =;
input-phy = "ft5x06 2 38/input0";
status = "okay";
}
*/
usbc0: fusb302@22 {
compatible = "fcs,fusb302";
reg =;
interrupt-parent = <&gpio1>;
interrupts =;
pinctrl-names = "default";
pinctrl-0 = <&usbc0_int>;
vbus-supply = <&vbus5v_typec>;
status = "okay";
};
/* LT9211 MIPI-to-LVDS bridge chip device node */
lt9211: lt9211@2d {
compatible = "lontium,lt9211";
reg =;
// reset-gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
status = "okay";
};
/* GT911 touchscreen device node */
gt911_14: gt911_14_ts@14 {
compatible = "goodix,gt911";
reg =;
pinctrl-names = "default";
pinctrl-0 = <>911_dsi1_gpio>;
interrupt-parent = <&gpio3>;
interrupts =;
irq-gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
// reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
touchscreen-size-x =;
touchscreen-size-y =;
// touchscreen-inverted-x;
// touchscreen-inverted-y;
touchscreen-swapped-x-y;
status = "okay";
};
};

3. Modifying Screen Parameters in the DSI Node

Replace the original 1024×600 timing configuration in the &dsi0 node with timing parameters adapted for the 1280×800 resolution LVDS screen. All parameters must strictly correspond to the screen’s specification sheet to prevent black screens or screen corruption issues.

Plain Text
/* Comment out the original 1024×600 timing configuration, kept for reference */
/*
disp_timings0: display-timings {
native-mode = <&dsi0_timing0>;
dsi0_timing0: timing0 {
hback-porch =;
hfront-porch =;
hactive =;
hsync-len =;
vback-porch =;
vfront-porch =;
vactive =;
vsync-len =;
clock-frequency =;
vsync-active =;
hsync-active =;
de-active =;
pixelclk-active =;
};
};
*/
/* Add timing configuration for the 1280×800 LVDS display */
disp_timings0: display-timings {
native-mode = <&dsi0_timing0>;
dsi0_timing0: timing0 {
hback-porch =;
hfront-porch =;
hactive =;
hsync-len =;
vback-porch =;
vfront-porch =;
vactive =;
vsync-len =;
clock-frequency =;
vsync-active =;
hsync-active =;
de-active =;
pixelclk-active =;
};
};

III. Kernel Compilation and Flashing

To improve validation efficiency, there is no need to compile the entire Android system. The kernel can be compiled separately using commands. After compilation, the generated boot.img image is located in the rockdev/Image-ok3588_c/ directory. Flashing only this image completes the adaptation.

Bash
# Navigate to the SDK root directory
cd /home/forlinx/work/OK3588-android14-source/
# Load the build environment, select the corresponding product branch
source build/envsetup.sh;lunch ok3588_c-userdebug
# Compile the kernel separately and generate the boot image
./build.sh -Ku

Verification and Experience Summary

After the modifications and compilation according to the above steps, the generated boot.img is flashed onto the embedded RK3588 development board. Upon power-up, the 1280×800 resolution LVDS screen lights up normally, the Android 14 system desktop displays completely, the GT911 touchscreen responds correctly without drift or missed touches, and a continuous 72-hour power-on test shows no display abnormalities.

The main focus of this adaptation is to align with the DRM display framework for high-version Android on the Rockchip platform. It is crucial to strictly follow the SDK's layered configuration rules. This means that board-level custom configurations must not override chip-level or system-level configuration files, which is important for ensuring future SDK upgrades and maintaining long-term compatibility.

Additionally, adapting the MIPI-to-LVDS bridge requires a comprehensive approach that encompasses three key areas: the driver, the device tree, and timing. Any deviation in these parameters can lead to display issues. In industrial-grade product development, achieving a display is not the ultimate goal. The fundamental principles of embedded development include preserving complete reference configurations, ensuring version compatibility, and guaranteeing long-term stability.

1. Industry Demands and Development Challenges

Maintaining a process keep-alive is essential in Android application development for ARM platforms. This is especially true in industrial-grade embedded scenarios, where the continuous and stable operation of background applications is crucial for tasks like device monitoring and data acquisition. So, during recent Android 14 development on the Forlinx Embedded RK3576 development board, the focus has been on addressing the need for industrial monitoring applications to maintain continuous background operation under native system management policies. Several key technical challenges have been identified in this process：

• System-Level Cleanup Mechanisms:

OOM Killer and Low Memory Killer proactively clear background processes. The system automatically terminates low-priority processes based on memory usage.

• User-Action Triggered Termination:

Actions such as screen-off, process freezing, manually swiping away the app interface, or executing kill commands via the shell terminal can directly terminate processes.

• Inherent System Limitations:

The system lacks native keep-alive or auto-restart mechanisms, preventing terminated processes from recovering automatically.

• Severe Impact on Operations:

This leads to interruptions in data acquisition, device monitoring failures, and severely compromises the stability of the entire industrial system.

Therefore, there is an urgent need to develop a targeted solution for process keep-alive and automatic restart, ensuring the continuous and stable operation of core business processes in industrial environments.

2. System Characteristics and Core Solution Approach

An analysis of the RK3576 development board running the Android 14 system reveals that it adheres to strict policies for managing background processes. The system actively removes low-priority background processes based on memory usage and supports functions such as freezing processes and enforcing terminations.

In the native setup, there are no dedicated mechanisms to protect specific processes from being terminated, nor is there built-in logic to restart processes automatically after they have been stopped. This limitation does not meet the stability requirements for background applications in industrial scenarios.

Core Solution Approach: A customized system service is proposed to create a whitelist for processes that require keep-alive functionality. Processes on this whitelist can bypass the restrictions imposed by the system's memory management and process freezing mechanisms. Additionally, a separate monitoring thread is developed to continuously track the operational status of whitelisted processes. If a process is terminated—whether manually or by the system—this thread will trigger an automatic restart.

3. Development Basis and Overall Framework

During the development process, it was noted that the Android 14 system source code included with the Forlinx RK3576 development board already features a foundational "whitelist" keep-alive mechanism. This significantly reduces the need for tedious low-level adaptation work. Building on this existing foundation, a comprehensive APP keep-alive solution has been further refined and implemented.

Forlinx RK3576 Development Board

The core carrier of the solution is the whitelist system service WhiteAppProcessListManagerService, whose specific path is:

frameworks/base/services/core/java/com/android/server/whiteappprocesslist/WhiteAppProcessListManagerService.java

The entire keep-alive solution is logically clear and highly implementable, primarily divided into the following three core steps:

• Whitelist Control Interface Development

Encapsulates the functions for retrieving and adding processes to the whitelist, enabling the management of process protection.

• Monitoring Service Development

An independent monitoring thread is developed to track the real-time status of whitelisted processes and implement automatic process restart.

• Testing and Validation

A test application is developed and subjected to comprehensive scenario validation to ensure the stability and reliability of the keep-alive mechanism.

4. Whitelist Management Interface Development and Initialization Configuration

As the system service managing the whitelist, WhiteAppProcessListManagerService encapsulates two core external interfaces, which respectively implement the retrieval and addition of whitelist entries:

4.1 Implementation of SoM Interfaces

//Get the whitelist process list interface
@Override
public @Nullable List<String> getWhiteAppProcessList() {
try{
// Call the corresponding method of the Activity Manager Service to obtain the whitelist
return mActivityManagerService.getWhiteAppProcessList();
}catch(Exception e){
e.printStackTrace();
return null;
}
}
//Add Process Name to Whitelist Interface
@Override
public void setWhiteAppProcessList(@Nullable String whiteAppProcess){
try{
// Call the corresponding method of the Activity Manager Service to set the whitelist
mActivityManagerService.setWhiteAppProcessList(whiteAppProcess);
}catch(Exception e){
e.printStackTrace();
}
}

4.2 Service Initialization Configuration

In the constructor of this service, the Forlinx RK3576 development board preconfigures the test application com.forlinx.logtest and adds this test app to the whitelist as the validation carrier for the keep-alive mechanism. At the same time, the monitoring thread is launched to ensure the proper triggering of keep-alive logic:

public WhiteAppProcessListManagerService(Context context, ActivityManagerService activitymanagerservice) {
mContext= context;
mActivityManagerService = activitymanagerservice;
//Add the test APP to the white list, and there is no extra space in the package name
mActivityManagerService.setWhiteAppProcessList("com.forlinx.logtest");
//Get the whitelist and print the log for debugging verification
List<String> list = mActivityManagerService.getWhiteAppProcessList();
for (int i=0;i<list.size();i++){
Log.d(TAG,"white app process list["+i+"]-"+list.get(i));
}
// Start the whitelist monitoring thread and start the process status detection
Thread thread = new Thread(new WhiteListMonitor(mContext,this));
thread.start();
}

Note: The whitelist monitoring service operates at the system level, starts automatically on system boot, and runs independently without relying on the test app launch. Only processes within the whitelist require manual initial startup, after which the monitoring service will continuously track the status.

5. Development of Whitelist Process Monitoring and Auto-Restart Service

The monitoring service and the framework-level whitelist mechanism have distinct roles:

Framework-Level Whitelist Mechanism:

Already adapted within the framework-level process management module, it allows processes in the whitelist to bypass system-level process cleanup and freezing restrictions, such as those imposed by OOM Killer, Low Memory Killer, Freeze (process freezing), and the ''Force Stop'' button in Android Settings.

Monitoring Service:

As an independent thread, it primarily handles scenarios where processes are terminated manually, such as when the application interface is closed or the process is killed via shell commands.

5.1 Core Logic of the Monitoring Thread

The monitoring service performs real-time traversal detection at 1-second intervals. When an abnormal status is detected for a whitelisted process, it automatically restarts the process and switches it to the background:

@Override
public void run(){
while(true){
try{
//Get all the process information of the system
List<ActivityManager.RunningAppProcessInfo> processes = getRunningAppProcesses();
for (ActivityManager.RunningAppProcessInfo process : processes){
//Print basic process information for debugging
Log.d(TAG,"Process:"+process.processName+",PID:"+process.pid+",state:"+process.processStateToString(process.processState)+","+process.processState);
//Detect whether the process is a whitelist process and the status is equal to or greater than empty cache status.
if (mWhiteProcessList.contains(process.processName) && process.processState >= ActivityManager.PROCESS_STATE_CACHED_EMPTY){
//Build the startup Intent based on the process name
Intent intent = getLaunchIntentForPackage(process.processName);
if (intent != null){
Log.d(TAG,"restart"+process.processName);
//Add a flag bit to avoid creating a new task stack
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
//Carry the startup mode ID and mark it as background active.
intent.putExtra("StartMode","Background");
//Start the process and complete the automatic pulling.
mContext.startActivity(intent);
//Simulate the HOme key after activation, and switch the application to the background.
Instrumentation instrumentation = new Instrumentation();
instrumentation.sendKeyDownUpSync(KeyEvent.KEYCODE_HOME);
}
}
}
//The thread sleeps for 1s, and the process status is detected in a loop to ensure the timeliness of pulling activity.
Thread.sleep(1000);
} catch(Exception e){
Log.d(TAG,"restart process fail");
e.printStackTrace();
}
}
}

The monitoring thread can quickly identify and complete the restart process when an abnormal status occurs in a whitelisted process. The transmission of Intent parameters provides a key basis for the application to distinguish the startup method and execute background operation logic. The operation of switching to the background after restart ensures the concealment and stability of application background operation in industrial scenarios.

6. Test APP Adaptation Development and Full-Scenario Validation

To verify the effectiveness and stability of the keep-alive mechanism, this test conducts adaptation development and full-scenario validation based on the com.forlinx.logtest test APP. This APP completes the development of startup mode judgment and background operation logic, and includes its own test thread.

6.1 Development of Startup Method Recognition Logic

The test APP receives the StartMode message transmitted by the monitoring service in the onCreate function. By determining whether the message content is ''Background,'' it accurately identifies whether the application's startup method is triggered by the monitoring service's restart or manually triggered by the user:

// Determine if the application was started by background restart
private boolean isAppIsInBackground() {
boolean isInBackground = false;
String StartMode = getIntent().getStringExtra("StartMode");
if(StartMode != null && StartMode.equals("Background")) {
isInBackground = true;
}
return isInBackground;
}
@Override
protected void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//Execute the corresponding logic according to the startup mode
if(isAppIsInBackground()){
Log.d(TAG, "start in the background");
moveTaskToBack(true);
}else{
Log.d(TAG, "The user triggers the start");
}
}

6.2 Development of Background Operation Verification Thread

The test APP includes a built-in test thread that prints an incremental number at 1-second intervals. Developers can observe real-time number changes through logcat logs, providing a clear and intuitive way to confirm whether the APP is running stably and continuously in the background:

new Thread(() -> {
long num = 0;
while (true) {
num++;
Log.d(TAG, "logtest count " + num);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
}).start();

6.3 Full-Scenario Validation Results

After completing the adaptation development, the author conducted full-scenario validation on the Forlinx OK3576-C Android 14 platform. After launching the com.forlinx.logtest test APP, the following operations were performed sequentially: screen off, manual closing of the application interface, executing kill commands via the shell terminal, and triggering OOM Killer due to low system memory. Observations via logcat logs revealed:

• After a process was manually terminated or cleared by the system, the monitoring service completed the automatic restart within 1 second. After restart, the APP automatically resumed running in the background without displaying any foreground interface;

• The incremental numbers from the test thread continued printing without any interruption, confirming the APP stable background operation;

• Processes within the whitelist were not cleared by OOM Killer, Low Memory Killer, or the process freezing mechanism, fully bypassing the limitations of the system's background process management;

The full-scenario validation results demonstrate that the developed keep-alive solution meets the core requirements of continuous and stable background operation for APPs in industrial-grade embedded scenarios, with effective and reliable keep-alive and restart logic.

7. Reflections and Insights on Scenario Adaptation

Implementing the APP keep-alive function on the Forlinx OK3576-C (RK3576) platform running Android 14 has provided developers with a deeper understanding of system service customization for embedded Android platforms. There is a fundamental difference between embedded platforms and consumer-grade Android devices:

Key differences between embedded platforms and consumer-grade Android devices:

• Industrial Requirements: Higher demands for stability and continuity of background processes compared to consumer scenarios; core operations must not be interrupted.

• Native System Limitations: Android's process management mechanism prioritizes resource optimization, which cannot fully meet the specific needs of industrial scenarios.

• Core Solution: Custom development of an independent, system-level keep-alive monitoring service through low-level system services.

• Design Advantages: The monitoring service starts automatically on boot, is decoupled from application processes, and ensures stability of the monitoring logic.

8. Areas for Optimization and Functional Expansion Suggestions

While the current keep-alive solution generally meets the core needs of industrial scenarios, there is one area that requires optimization. Specifically, processes that are included in the whitelist do not start automatically upon boot. Developers need to manually launch the test application for the first time before the monitoring service begins status detection and restart operations.

To enable automatic startup for whitelisted processes at boot, the constructor of the WhiteAppProcessListManagerService could be modified to directly launch these processes via an Intent, similar to the method used by the monitoring service to start processes. This change would create a fully automated workflow of "start on boot, restart on exception."

Expansion Suggestion: If there is a need for flexible control over the whitelist at the application layer—such as dynamically adding or removing keep-alive processes—the management class for the whitelist system service could be packaged as a JAR interface to facilitate external calling capabilities. However, from a system stability perspective, this modification is not recommended. Industrial-grade embedded devices have extremely high demands for system stability, and dynamic modifications to the whitelist could introduce risks, such as process management issues and excessive consumption of system resources.

9. Summary

The Core Value of Embedded Development

Embedded development focuses on tailoring systems and hardware to meet specific business needs. This APP keep-alive solution is a customized adaptation of Android process management system, designed to fulfill the critical requirement of maintaining continuous background processes for device monitoring and data collection in industrial scenarios.

In embedded development, native systems often offer only generalized functions and mechanisms, which may not fully address the unique and specific requirements of different industries. As a result, developers need to have a deep understanding of both the hardware platform and low-level system logic. This knowledge enables them to engage in customized development that effectively tackles real-world business challenges.

Forlinx Embedded has officially launched the FAI-ARA240-M, an M.2-based AI accelerator built around the NXP Ara240 processor. The module provides a discrete NPU for offloading inference workloads from embedded host systems.

The Ara240 processor was first seen during the launch of the OK-MX9596-C. Forlinx provides additional details with this module, which delivers up to 40 TOPS of AI performance and supports a range of model types, including convolutional neural networks, transformer-based models, and multimodal architectures.

The accelerator is available with 8GB or 16GB of LPDDR4 memory for handling larger models and high-throughput workloads.

The module adopts a standard M.2 2280 form factor with an M-Key interface, allowing integration into existing platforms through PCIe without requiring changes to the base hardware.

FAI-ARA240-M dimensions

It supports PCIe Gen4 x4 and USB 3.2 Gen1 interfaces for data transfer between the host processor and the accelerator.

In this configuration, the FAI-ARA240-M operates as a co-processor, where the host system manages control and application logic while the accelerator handles AI inference tasks.

FAI-ARA240-M cooling system

The module is compatible with host platforms such as those based on NXP i.MX8M Plus and i.MX95 processors.

Software support includes compatibility with TensorFlow, PyTorch, and ONNX, along with development tools for model deployment, quantization, and optimization. The platform supports multiple data types, including INT4, INT8, and mixed-precision formats.

FAI-ARA240-M

The design includes secure boot and root-of-trust features, along with a thermal solution intended to maintain stable operation under sustained workloads.

Forlinx states that the module is specified for continuous operation and has undergone environmental validation for industrial use.

Specifications listed for the FAI-ARA240-M include:

• Processor:

  NXP Ara-240 Edge AI processor

• AI Performance:

  Up to 40 TOPS

• Memory:

  8GB / 16GB LPDDR4

• Form Factor:

  M.2 2280 (M-Key)

• Interface:

  PCIe Gen4 x4

  USB 3.2 Gen1

• Mechanical:

  80 x 22mm

Further Information

The FAI-ARA240-M is currently available for order. Please contact our sales team for the latest pricing.

Copyright Notice:

This article is reposted from LinuxGizmos. The original content is intended for industry information sharing and product news purposes. All copyrights and intellectual property belong to the original author and the platform LinuxGizmos. Forlinx Embedded respects the original work and has included the source for reference.

Recently, development on the OK1126B-S board based on the Rockchip RV1126 required adaptation of the Lontium LT8912B for MIPI-to-HDMI conversion. This is a common requirement in embedded display expansion, mainly involving driver porting, device tree configuration, and display parameter tuning. With its industrial-grade design, clear directory structure, and reliable hardware, the OK1126B-S provides an efficient development platform and simplifies third-party peripheral integration.

LT8912B MIPI-to-HDMI Adaptation Test Scenario on the OK1126B-S Development Board

After completing the basic configuration according to the standard adaptation process, the screen remained blank, and the HDMI output reported: ''Cannot display this video mode. Please reset the computer to 1920×1080.'' This prompted targeted troubleshooting and adaptation optimization.

Issue Analysis:

The HDMI output indicated that the video mode was incompatible. In MIPI-to-HDMI adaptation, such issues are often caused by a mismatch between the display modes supported by the driver and the resolution or timing parameters configured in the device tree. On the RV1126 platform, based on the DRM display framework, the driver layer provides display mode support, while the device tree defines the specific display timing and resolution. These two layers must match exactly for successful display initialization.

Based on this, the completed adaptation steps were first reviewed to confirm that driver deployment and device tree hardware binding were configured correctly. The focus was then narrowed to display mode matching, and the root cause was identified: in the LT8912B driver file lt8912_cp.c, only the 1280 × 800 display mode was enabled by default, while the initial device tree configuration was set to 1920 × 1080. As a result, the driver could not recognize or initialize the corresponding display mode, leading to the blank screen and HDMI compatibility issue.

Complete Adaptation Solution

To address the issue above, a complete adaptation solution was developed based on the characteristics of the OK1126B-S development board running the 6.1.141 Buildroot system. The process was carried out step by step, covering driver deployment, build configuration, device tree hardware binding, and display parameter matching. The specific steps are as follows:

1. Deploy the LT8912B Driver File

Place the Lontium LT8912B driver file lt8912_cp.c into the OK1126B-linux-source/kernel/drivers/gpu/drm/bridge/ directory of the Forlinx embedded development board source tree. This directory is the standard location for bridge chip drivers in the platform DRM display framework and also conforms to the driver directory structure of the Rockchip RV1126 kernel.

Note: The lt8912_cp.c file can be obtained by contacting online customer support.

2. Modify the Makefile to include the driver compilation.

After deploying the driver file, edit the Makefile in the kernel/drivers/gpu/drm/bridge/ directory. Add the following build instruction at the end of the file so that lt8912_cp.c is included in the kernel build process and the corresponding driver module is generated during kernel compilation:

obj-y += lt8912_cp.o

3. Add the LT8912B Hardware Node to the Device Tree

After resolving the driver build configuration, the next step is device tree configuration. Referring to the OK1126B-S-common.dtsi device tree file of the OK1126B-S platform, add the LT8912B device node under the i2c3 node to complete the hardware binding and attachment of the chip to the i2c3 bus. Since the LT8912B has three I2C addresses, address 0x01 is temporarily configured in the device tree. The core I2C addresses are added dynamically by the kernel driver functions. The node configuration is as follows:

&i2c3{
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c3m1_pins>;
// Lontium LT8912B MIPI-to-HDMI device node
lt8912: lt8912@1 {
compatible = "lontium,lt8912";
reg = <0x01>;
i2c-bus = <&i2c3>;
reset-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>;
status = "okay";
};
};

Device Tree i2c3 Node Configuration Example

4. Modify the Display Device Tree to Match the Driver-Supported Display Mode

The previous black screen issue was mainly caused by a resolution mismatch. Edit the OK1126B-S-display.dtsi device tree file and change the display timing configuration to 1280 × 800, so that it matches the default display mode supported by the lt8912_cp.c driver. The specific display timing parameters are as follows:

disp_timings0: display-timings {
native-mode = <&panel_1280x800>;
panel_1280x800: timing0 {
hback-porch = <10>;
hfront-porch = <100>;
hactive = <1280>;
hsync-len = <10>;
vback-porch = <1>;
vfront-porch = <2>;
vactive = <800>;
vsync-len = <20>;
clock-frequency = <71000000>;
/* Approximate 71 MHz for ~60Hz with these timings */
vsync-active = <0>;
hsync-active = <0>;
de-active = <0>;
pixelclk-active = <0>;
};
};

Display Timing Parameter Configuration Example

5. Rebuild the Kernel to Complete the Adaptation

After modifying all the files above, run the kernel build command in the Buildroot environment of the RV1126 development board to compile the driver and device tree changes into the kernel image. Once the build is complete, flash the new kernel to the development board. At this point, the MIPI-to-HDMI adaptation is fully completed.

Verification Results

After powering on the RV1126B development board, the LT8912B MIPI-to-HDMI function was successfully adapted, the display lit up normally, and the previous video mode error no longer appeared. The adaptation results were further verified through terminal commands on the development board, and all feedback matched expectations:

1. Running i2cdetect -y 3 detected the LT8912B device on the i2c3 bus, confirming successful hardware attachment.

2. Running dmesg | grep 8912 showed normal driver initialization logs. The key log messages are as follows:

[4.964730] LT8912 ID:12,b2
[4.964736] LT8912:Start Initialization...
[5.222233] LT8912:Setting Mode 1280x800
[5.705876] LT8912:Releasing Reset (0xFF)...
[5.806216] LT8912: Enabling HDMI...
[5.806543] LT8912:Init Done.

Driver Initialization Log Verification Screenshot

Technical Summary

The successful adaptation of the LT8912B MIPI-to-HDMI function on the OK1126B-S platform once again confirms a core principle of embedded low-level development: the driver and device tree must match exactly. This is especially critical for display bridge chips, where the display modes supported by the driver and the timing parameters configured in the device tree are key to achieving proper display output.

During peripheral adaptation on embedded platforms, if the hardware has been successfully attached but the function still does not work properly, the most efficient troubleshooting approach is to first check the consistency between the driver and device tree parameters. Particular attention should be paid to resolution, display timing, configuration settings, and bus parameters.

The Forlinx OK1126B-S development board, with its standardized directory structure and stable, reliable hardware design, greatly simplified this adaptation work and serves as an ideal platform for embedded developers.

When integrating third-party bridge chips, careful review of the vendor driver’s default configuration is essential, as some drivers enable only limited functional modes by default. In such cases, priority should be given to adapting the device tree or driver configuration instead of directly modifying the driver source code, which helps improve efficiency and reduce the risk of introducing new stability issues.

The Forlinx OK1126B-S development board, with its standardized directory structure and stable, reliable hardware design, greatly simplified this adaptation work and serves as an ideal platform for embedded developers.

1. Overview

In embedded Linux product development, Java continues to be valuable alongside traditional C and C++ methods. It is particularly useful for cross-platform applications, utility programs, and certain higher-level business scenarios. For developers aiming to deploy the Java Runtime Environment (JDK) on ARM platforms, it is essential to complete the installation of the JDK, configure environment variables, and validate program runtime. This process is a crucial step in assessing the usability of platform.

This article demonstrates how to deploy the Java Development Kit (JDK) on a Linux 6.1.36 system using the Forlinx embedded OKMX93xx series development board as a reference. It includes basic validation steps and more complex test cases to ensure that the Java Runtime Environment is functioning correctly. This guide is suitable for evaluating development environments, setting up systems, and porting applications. While other platforms can use this method as a reference, adjustments may be required based on their specific software environments.

2. Application Scope

This guide is specifically intended for the Forlinx OKMX93xx series platform operating on the Linux 6.1.36 operating system. Please note that variations in system configuration, directory structure, and software environment may exist across different platforms. Therefore, adjust the steps in this guide to fit your specific setups.

3. JDK Support

The installation and test packages used in this guide include:

jdk-8u381-linux-aarch64.tar.gz

jdk-8-linux-aarch64-demos.tar.gz

Among these, jdk-8u381-linux-aarch64.tar.gz is used for deploying the JDK runtime environment, while jdk-8-linux-aarch64-demos.tar.gz is used for further testing with example programs. According to the original documentation, these two compressed packages can be obtained from the JDK download page provided by Oracle.

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

4. JDK Deployment Steps

4.1 Installation Packages Preparation

First, prepare the two compressed packages:
jdk-8u381-linux-aarch64.tar.gz (used for JDK installation)
jdk-8-linux-aarch64-demos.tar.gz (used for demo program testing).

4.2 Installation Package Transfer to the Development Board

Copy the jdk-8u381-linux-aarch64.tar.gz package to the development board, for example, to the /home/root/ directory.

4.3 Extraction of the JDK Installation Package

In the terminal on the development board, execute the following commands:

root@ok-mx93:~# tar -xvf jdk-8u381-linux-aarch64.tar.gz
root@ok-mx93:~# ls

After extraction, the jdk1.8.0_381 folder will be created. This directory is the path that will correspond to the JAVA_HOME environment variable later.

4.4 Environment Variables Configuration

Append the following content to the end of the /etc/profile file:

JAVA_HOME=/home/root/jdk1.8.0_381
CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASSPATH PATH

JAVA_HOME specifies the JDK installation directory.
CLASSPATH specifies the Java runtime class library path.
PATH adds Java commands like java and javac to the system's environment variables for easy access.

4.5 Configuration Application

After configuring, execute the following command to make the environment variables effective immediately:

source /etc/profile

If this command is not executed, the newly added Java environment variables may not be recognized in the current terminal session.

4.6 JDK Version Check

Run the following command to verify if the JDK is installed successfully:

java -version

If the system can output the version information, it means the JDK installation and environment variable configuration are successful.

5. Basic Functionality Verification

Copy the test program to the current directory.

Then, execute the test program for verification:

The result is correct.

6. Advanced Program Testing

Once the basic verification is successful, the document further tests the Java environment using the example programs provided in jdk-8-linux-aarch64-demos.tar.gz. After extracting the package, a jdk1.8.0_341 directory is created, which contains two folders: sample and demo, for further Java environment verification.

6.1 Navigation to the Test Directory

Enter the directory:

root@ok-mx93:~# cd jdk1.8.0_341/sample/forkjoin/mergesort/

There are test files such as MergeDemo.java and MergeSort.java.

6.2 Test Program Compilation

Run the following command to compile the program:

root@ok-mx93:~/jdk1.8.0_341/sample/forkjoin/mergesort$ javac MergeDemo.java

After compiling, the following .class files will be generated in the directory:

MergeDemo$1.class
MergeDemo.java
MergeDemo$Configuration.class
MergeSort$MergeSortTask.class
MergeDemo$Range.class
MergeSort.class
MergeDemo.class
MergeSort.java

The results show that the javac compiler is operating correctly on the target platform, and the Java source code has been accurately converted into the corresponding bytecode files.

6.3 Test Program Execution

Execute the following command to run the example program:

root@ok-mx93:~/jdk1.8.0_341/sample/forkjoin/mergesort$ java MergeDemo

The program outputs as follows:

Default configuration. Running with parameters: 20000 20000 10 2 2 10
Time in milliseconds. Y-axis: number of elements. X-axis parallelism used.
2 4 6 8 10 12 14 16 18 20
20000: 7 8 9 5 7 8 6 7 6 5
40000: 9 9 11 11 11 12 11 10 13 14
60000: 13 14 15 15 14 16 16 17 16 15
80000: 19 20 21 21 22 23 22 21 22 23
100000: 24 25 26 25 28 26 28 27 28 26
120000: 28 29 31 31 31 31 36 33 32 31
140000: 34 35 40 35 38 42 38 42 37 38
160000: 53 58 54 57 57 56 45 46 46 47
180000: 61 61 61 64 63 65 63 60 62 52
200000: 68 65 65 66 68 73 73 69 75 67
Total: 316 324 333 330 339 352 338 332 337 318

The validation process outlined above indicates that the OKMX93xx platform has successfully completed the installation of the JDK, configured the environment variables, compiled Java source code, and executed a demo program. This means that the platform not only supports the Java Runtime Environment but also offers fundamental capabilities for Java development and verification. This makes it a valuable resource for future application porting and project evaluation.

7. Summary

By following the steps outlined in this guide, you can successfully complete JDK 8 deployment, configure environment variables, and test demo programs on the OKMX93xx Linux 6.1.36 system. This platform provides a clear and reproducible path for developers who are working on porting Java applications, validating functionality, or conducting preliminary technical assessments on ARM platforms. Therefore, the OKMX93xx serves as an important reference for future project

In the development of industrial HMI, including smart terminals, self-service kiosks, and embedded display systems, integrating display screens with touch input is a crucial engineering task. During fast-paced project cycles, developers often need to adapt and troubleshoot display modules of different sizes, interfaces, and touch controllers, depending on the specific hardware configurations.

1. Background

This guide offers a clear, step-by-step process for integrating a 15.6-inch Dual-LVDS display panel with an ILI2510 touch controller on the Forlinx Embedded OK6254-C SBC, operating on the Linux 6.1.33 kernel.

2. Display Configuration

2.1 Display

Modify the forlinx _ contorl node in/OK62xx-linux-kernel/arch/arm64/boot/DTS/Ti/OK62xx.dtsi as shown in the figure below:

2.2 Touchscreen

2.2.1 Adding the Device Tree Node

Refer to the schematic based on the hardware connection at P34 to confirm that the hardware is connected via I2C2.

Consult the chip manual to check its multiplexing functionality (since the default I2C2 interface is already configured, no modifications are necessary).

Perform the multiplexing in /OK62xx-linux-kernel/arch/arm64/boot/dts/ti/OK62xx.dtsi:

Comment out the original interface.

Add it to the usr_led_pins_default node and modify it as shown in the diagram.

AM62X_IOPAD(0x0e0, PIN_INPUT, 7) /* (V20) VOUT0_DATA10 /
AM62X_IOPAD(0x0e4, PIN_OUTPUT, 7) / (AA23) VOUT0_DATA11 */

Add a new node under the main_i2c2 node:

touchscreen: ilitek_251x@41 {
compatible = "ilitek,ili251x";
reg = <0x41>;
pinctrl-0 = <&usr_led_pins_default>;
interrupt-parent = <&main_gpio0>;
interrupts = <55 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&main_gpio0 56 GPIO_ACTIVE_LOW>;
wakeup-source;
status = "okay";
};

2.2.2 Loading the Kernel Driver

Enter Ok62xx-linux-kernel to configure menuconfig.

forlinx@ubuntu:~/62xx/OK62xx-linux-sdk$ cd OK62xx-linux-kernel/
forlinx@ubuntu:~/62xx/OK62xx-linux-sdk/OK62xx-linux-kernel$ make menuconfig ARCH=arm64

Load the driver under Device Drivers > Input device support > Touchscreens, selecting the driver in the red box.

Recompile the kernel and place the compiled Image and OK6254-C.dtb files in the /boot directory. Save and restart the development board. During the Uboot phase, select the screen configuration as follows:

2.2.3 Calibrating the Screen and Configuring Rules

1. View the node

card0-LVDS-1 corresponds to lvds1.

2. Set udev

root@OK62xx:/# vi /etc/udev/rules.d/touchscreen.rules
SUBSYSTEM=="input", ACTION=="change|add", ATTRS{name}=="ili210x_i2c", ENV{WL_OUTPUT}="LVDS-1"

Enter the following command to configure udev rules:

3. Use the command vi /etc/xdg/weston/weston.ini to open the screen calibration file and uncomment it. To enable the screen calibration tool.

root@OK62xx:/# vi /etc/xdg/weston/weston.ini

If the file does not exist, add the following content at the end:

[libinput]
touchscreen_calibrator=true

4. Screen Calibration

root@OK62xx:/# weston-touch-calibrator "LVDS-1" --debug -v

After entering the command, touch the red crosses on the screen in sequence to obtain the calibration values.

5. Configure the environment variable

root@OK62xx:/# vi /etc/udev/rules.d/ws-calibrate.rules

Delete the original content and add the following:

SUBSYSTEM=="input", ATTRS{name}=="ili210x_i2c", ENV{LIBINPUT_CALIBRATION_MATRIX}="1.014184 -0.032956 -0.007435 -0.008599 1.035186 0.004496", ENV{ID_INPUT_KEY}="1"

Save and reboot the device.

In the development of embedded display terminals, adapting touchscreens might seem like a minor feature, but it has a significant impact on the overall human-machine interaction experience. For developers who require screen customization, interface expansion, and project implementation, mastering the entire touchscreen adaptation process can greatly enhance product development efficiency and improve troubleshooting capabilities.

The Forlinx Embedded platform offers a reliable hardware foundation along with a comprehensive software development environment. This aids developers in efficiently integrating systems, from low-level drivers to high-level applications. If you are involved in the development of displays, HMI, or industrial terminal products, this article could be a valuable reference for adapting your project.

The rapid evolution of Large Language Models (LLMs) and Multimodal AI is pushing the limits of traditional edge computing. To address the growing demand for high-performance AI inference without the complexity of a full system redesign, Forlinx Embedded, a proud NXP Gold Partner, is excited to announce the global launch of the FAI-ARA240-M Edge AI Accelerator.

The Challenge: Scaling AI Performance at the Edge

As AI workloads move from simple object detection to complex Generative AI—such as Vision-Language Models (VLMs) and Vision-Language-Action (VLA) models—developers face a significant hurdle. Traditional embedded SoCs may not always provide the dedicated NPU power required for real-time, local inference.

Until now, upgrading AI performance often meant redesigning the entire hardware stack, leading to increased costs, longer development cycles, and higher project risks.

The Solution: A Decoupled AI Architecture

The FAI-ARA240-M introduces a "Decoupled AI Architecture." By separating AI acceleration from the host SoC, Forlinx allows developers to scale their system's "brainpower" independently.

Designed in a standard M.2 2280 form factor, the FAI-ARA240-M acts as a powerful co-processor. It can be easily integrated into existing platforms—such as those based on the NXP i.MX8M Plus or the next-generation i.MX95—via a simple M.2 M-Key interface. This modular approach significantly reduces time-to-market and allows legacy systems to evolve into AI-capable powerhouses.

Key Technical Highlights

Advanced Model Support: From Vision to Action

The FAI-ARA240-M is not just about raw numbers; it is about versatility. It supports a wide range of modern AI frameworks and architectures, enabling the next wave of industrial innovation:

• Generative AI: Real-time inference for LLMs and MMLMs.

• Multimodal Intelligence: Seamless handling of VLMs for complex environmental understanding.

• Robotic Interaction: Supporting VLA (Vision-Language-Action) models to bridge the gap between perception and physical execution.

• Mainstream Frameworks: Full compatibility with TensorFlow, PyTorch, and ONNX.

Built for the Toughest Environments

Forlinx Embedded understands that industrial applications demand more than just performance. The FAI-ARA240-M has undergone rigorous environmental testing to ensure reliable 24/7 operation. Its low-power design and optimized thermal architecture make it ideal for fanless, rugged systems where heat dissipation is a critical concern.

Target Applications

• Industrial Automation: Real-time defect inspection and multimodal sensory fusion.

• Healthcare: High-speed medical imaging and diagnostic assistance.

• Smart Transportation: Edge-based traffic analytics and autonomous navigation.

• Robotics: Drone and robotic systems requiring secure, on-device AI for critical operations.

The FAI-ARA240-M Edge AI Accelerator is available for order now. For more information, please visit the FAI-ARA240-M Product Page or contact our global sales team at sales@forlinx.com.

FET3588-C System on Module based on Rockchip RK3588

FET3588-C SoM

New Generation Advanced AIoT Processor RK3588

As a universal 8K supported SoC, RK3588 is outstanding in integer operations, floating-point arithmetic, RAM, low-power and even the outline.
Advanced 8nm processing, Big & Little core structure and L3 cache, which are all have been greatly improved its computing capability.

NPU With Processing Performance Up To 6 TOPS

RK3588 processor contains a triple-core NPU, supports co-work and work independently;
Supports INT4/INT8/INT16/FP16 hybrid operation and computing power is up to 6TOPs.
MAC utilization improved by more than 28% together with 2.0 RKNN TOOLkit2 can meet most demand for edge computing.

8K Encoder/ Decoders Exploring

The RK3588 supports 8K display output and features high-performance video decoding for H.265/VP9 at 8K@60fps, H.264 at 8K@30fps, and AV1 at 4K@60fps.
It serves as a powerful platform for intensive video applications, offering full compatibility with OpenGL ES 1.1/2.0/3.2, OpenCL up to 2.2, and Vulkan 1.2.
A dedicated 2D hardware engine with MMU maximizes display performance to ensure ultra-smooth operation.

Various Display Interfaces: Quad-Screen Playback with Diverse Content

Various display interfaces such as 2x HDMI 2.1, 2x eDP 1.3, 2x DP 1.4, 2x MIPI-DSI and BT.1120 are available.
Can support quad-screen playing together but with different content, up to 7680x4320@60Hz output, will take users fantastic visual experience.

New Generation ISP Substantially Boosts Image Quality

RK3588 introduces a new generation totally hardware-based maximum 48-Megapixel ISP3.0.
It implements a lot of algorithm accelerators, such as HDR, 3A, LSC, 3DNR, 2DNR, sharpening, dehaze, fisheye correction, gamma correction and so on.

Rich Ready-to-use Peripheral Source

User-Friendly Reference Files and Efficient After-Sale Technical Support

Multiplied Isolation Circuits: Trusting the Board as a Secure Platform

Diverse Application Scenarios Empower Multiple Industrial Sectors

RK3588 SoM & SBC Video

FET3588-C System on Module based on Rockchip RK3588

FET-MX9596-C System on Module Based on NXP i.MX95 Series Processor

FET-MX9596-C SoM

NXP New Flagship Chip

NXP i.MX95xx combines high performance application cores, independent MCU real-time domain, Energy Flex architecture, advanced security supported by EdgeLock® secure zone, and dedicated multi-sensor data processing engines (graphics, image, display, audio, and voice), to accelerate edge machine learning applications.

Safety Features

i.MX 95 series has safety features that comply with the ISO 26262 ASIL-B and IEC 61508 SIL-2 functional safety standards to support basic safety measures in automobiles and functional safety in industrial control systems.

Multicore Heterogeneous Architecture

i.MX95xx series features ARM Cortex-A55 high-performance cores along with a Cortex-M7 real-time core,delivering both high computing performance and precise real-time control.

High-performance GPU

The advanced ARM Mali-G310 GPU supports OpenGL® ES 3.2, Vulkan® 1.2, and OpenCL 3.0, delivering stunning graphics and exceptional computing performance.With the ability to manage two independent output streams, it offers versatile functions such as image rotation, resizing, color space conversion,blending, raster operations (ROP), scaling, distortion correction, and linear illumination.

High Computing Power to Empower Edge Applications

The i.MX95xx chip integrates a built-in Neural Processing Unit (NPU) with a high computing power of up to 2 TOPS, which enables excellent machine learning and deep learning capabilities, providing robust support for edge computing applications.

Rich CPU Interfaces

High Definition Decoding and Display Enhancement

The i.MX95xx chip supports H.264 encoding & decoding and H.265 decoding with resolutions up to 4K, easily meeting the demands of playing high-definition videos.At the same time, the chip also utilizes advanced display enhancement technology,which can further improve the contrast and color saturation of the picture, giving users a more stunning visual experience.

ISP Significantly Enhances Image Quality

The ISP technology integrated into the i.MX95xx chip supports various image sensors and is optimized for different application scenarios.Whether it's for industrial inspection, robot vision or autonomous driving applications, the i.MX95xx can provide clear and accurate image data.

Continuously Updated User Profiles

Broad Industry Applications

In multiple industries including industrial, medical, power, automotive transportation, environmental monitoring, smart cabins,and IoT, the FET-MX95xx-C SoM, with its high performance, multifunctionality, and industrial-grade advantages, coupled with Forlinx's competitive pricing and comprehensive after-sales technical support, will help your products quickly enter the market and stay ahead in the industry.

NXP i.MX9596 SoM&SBC Video

All-New FET-MX95xx-C System On Module Based on NXP iMX95 Processor