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.

In the current global AI ecosystem, over 99% of applications focus on PC-based office automation. However, in the embedded Linux space, the challenge of seamlessly enabling AI to control GPIO, UART, or industrial sensors still remains.

With the OK1126B-S development board's powerful edge computing capabilities, OpenClaw is bridging this gap through its Skills framework. This article will break down the core logic behind Skills and demonstrate how a standardized "manual" allows AI to control hardware with the precision of an experienced engineer.

1. OpenClaw Skills Ecosystem

If the model itself is the "brain," then Skills serve as the "experience + action guidelines.” By creating Skills, we can transform OpenClaw from a passive responder into an active AI that can autonomously complete complex tasks based on predefined rules.

As of today, ClawHub's community has released over 26,000 Skills. However, over 99% of these Skills are designed for Windows, x86 Linux, or Mac platforms, focusing mainly on office and web automation. Few Skills are developed for embedded Linux, and those that exist are not mature enough, often lacking standardized encapsulation and driver adaptation for embedded peripherals (GPIO, UART, SPI, I2C, sensors, motors, cameras). Additionally, there is a significant gap in specialized Skill sets designed for edge computing, low-power, and real-time applications in fields like industrial control, robotics, smart homes, and automotive systems.

So, does the embedded field not deserve "lobster" too?

In this article, we will demonstrate a simple example—controlling the blink pattern of an LED on the OK1126B-S development board—and gradually break down the design and usage of Skills, starting from the basics.

2. What Are Skills?

In essence, Skills are like an "operating manual." They don't directly perform tasks for AI but tell AI when, how, and what to do.

Let's simplify it with an analogy: In a shooting game, the player's goal is to defeat enemies. The gun, as a tool, has a simple role:

• Input: Pull the trigger

• Output: Fire

Where the bullet lands is not the gun's concern. The Skill, however, functions as the "tactical guide." It tells AI:

• When to shoot (detecting an enemy)?

• When not to shoot (friendly forces ahead)?

• When to stop (enemy's health reaches zero)?

With these rules, AI transitions from being a mechanical tool that executes commands to one that possesses decision-making abilities, thinking and reasoning in a more human-like manner.

2.1 Basic Structure of a Skill

In OpenClaw, a Skill is essentially a structured directory, typically found at:

~/.openclaw/workspace/skills/${SKILL_NAME}

A complete Skill is composed of four parts:

Naming rules:

The directory name of a Skill must follow the naming convention, or it will not be recognized:
Only lowercase letters, numbers, and hyphens (-) are allowed.
Example: gpio-led-control

This convention, though simple, is crucial in actual development. Many issues with loading Skills are often caused by violations of this rule.

2.2 Detailed Explanation of SKILL.md

The SKILL.md file is the heart of the Skill, akin to a "manual + behavior guide." It consists of two parts:

① Metadata (Preliminary Information)

Enclose with --- to define the basic information of the Skill. This information serves to:

• Help OpenClaw recognize the Skill

• Provide semantic matching (keywords to trigger the Skill)

For example:

name: gpio-led-control # Required
description: description: GPIO LED control for development boards # Required
(Some options are listed below for reference only)
user-invocable: true # Optional: Whether it can be called directly by the user

② Main Content (Action Guidelines)

The main content serves as the specific action guide, which can be organized flexibly based on requirements. To illustrate, here's a simplified version of the SKILL.md for "gpio-led-control":

# GPIO LED Control - Development Board LED Control
Control the system LEDs (e.g., work/net) on boards like the OK1126B-S.
## Quick Start
### View Available LEDs
### Control LED On/Off
## Example Usage
## Permissions
## Notes

In practice, the SKILL.md file can be extended based on specific needs, such as adding logic for execution conditions (when to run), error handling, parameter explanations, and example inputs/outputs. In addition to the core SKILL.md file, the other three directories serve auxiliary roles, each with its distinct function.

scripts/: This directory is mainly used to store executable script files. It's suited for scenarios where the execution logic is fixed and doesn't require frequent changes, such as tasks like controlling the on/off state of an LED. These scripts can be directly invoked, which reduces the need for redundant code generation and increases overall execution efficiency and stability.

references/: This directory is used to organize various reference materials, such as API documentation, database structure explanations, or operation manuals. These materials are not loaded all at once; instead, they are brought in as needed based on context. This approach helps avoid unnecessary resource consumption and ensures that AI has access to deeper, more professional knowledge at critical moments.

assets/: This directory is where various resource files, such as templates, images, and other media, are stored. Unlike references, the contents here are not part of the model's contextual reasoning but serve to enhance the final output, such as providing report templates or images for the output. These resources elevate the presentation and completeness of the Skill's results.

2.3 Process of Writing a Custom Skill

Once we understand the structure, it's time to start writing our own Skill. The process can be summarized as:

Requirement Analysis → Resource Planning → Initialization → Writing → Packaging → Testing

Step 1: Requirement Analysis

Before diving in, clearly define:

• What problem the Skill will solve?

• What is the usage scenario?

• How will users trigger it?

• What are the inputs and outputs?

Trigger conditions must be clearly defined, otherwise, the Skill may fail to be invoked or be incorrectly triggered.

Step 2: Resource Planning

Decide if you need:

• scripts (Do you need executable code?)

• references (Do you need documentation?)

• assets (Do you need resources?)

Proper planning upfront helps avoid structural confusion and redundancy caused by repeated revisions later on.

Step 3: Writing and Debugging

We can leverage OpenClaw to automatically generate a standardized initial template for a Skill in a designated directory, which can then be further refined. However, it's important to note that this auto-generated Skill is just a "starting point" and usually doesn't meet actual requirements right away. To truly deploy it, the content still needs to be gradually adjusted and tested iteratively based on the specific scenario, ultimately refining it to achieve the desired functionality.

3. Real-World Skill Example

To better understand, we've created a simple Skill for controlling two LEDs on the OK1126B-S development board. Once the Skill is connected, OpenClaw:

1. ① Recognizes the user's intent

2. ② Matches the appropriate Skill

3. ③ Executes actions according to SKILL.md rules

4. ④ Calls the necessary scripts and returns results

This entire process runs autonomously, enabling true “natural language control of hardware.”

4. Conclusion

By breaking down the core concepts of Skills and demonstrating them with a simple LED control example, we've highlighted the practical application of Skills. Even for basic hardware control scenarios, this example demonstrates the core value of Skills: turning complex processes into reusable, standardized capability units.

The design philosophy behind Skills is to enable streamlined command execution and standardized actions. After the Skill is built, a single command is all it takes for AI to execute tasks according to predefined rules. This not only eliminates redundant development and debugging but also ensures stability and consistency across various scenarios. Skills offer tremendous value in embedded development, automated operations, and smart device management.

The embedded space is a key breakthrough area for the OpenClaw ecosystem. It is essential for real-time hardware interaction, edge intelligence deployment, and represents the most promising growth area with the highest demand for quality capabilities. By continuously building a rich, user-friendly, and reliable embedded Skills pool, OpenClaw can break free from its desktop tool limitations and evolve into a comprehensive smart execution framework that spans the entire "cloud-edge-device" chain.

Amid the profound transformations of Industry 4.0 and the energy transition, core computing units are confronted with unprecedented challenges: harsh physical environments, complex protocol interoperability, and growing uncertainty in global material supply chains. Today, the FCU1501 Industrial Gateway is officially released. It is not only a high-performance communication hub but also a long-term supply commitment for global industrial customers. With deep control over underlying technology, the FCU1501 ensures stable delivery and reliable operation throughout the entire project lifecycle, safeguarding your business from external fluctuations.

Underlying Architecture Resilience: High-Performance Industrial-Grade Hardware and Supply Assurance

The success of industrial projects often depends on 5-10 years of smooth operation. A highly controlled material system is established for the FCU1501, with each component rigorously evaluated for long-term supply, ensuring stability and eliminating risks of disruption due to external factors, providing vital business continuity for power, transportation, and other infrastructure projects.

• High-Performance Industrial Main Control: Equipped with Rockchip RK3506J processor, three-core Cortex-A7 architecture, up to 1.5GHz, low power consumption, and high computational capability, handling industrial protocol conversion, edge data cleaning, and local logic control tasks effortlessly.
• Flexible Storage Configuration: Available with 256MB/512MB DDR3 memory and 256MB NandFlash/8GB eMMC storage options, supporting large-scale historical log storage, offline data continuation, and frequent remote firmware upgrades (OTA).
• Electrical Safety and High Availability: Supports DC 9-36V wide voltage input with reverse and overcurrent protection, adapting to complex power environments in industrial sites. Built-in hardware watchdog and high-precision RTC ensure 24/7 stable operation.
• Latest Mainstream Kernel: Pre-installed with the stable Linux 6.1 operating system, providing enhanced security and broader hardware driver support, simplifying secondary development.

Industrial-Level Physical Protection: Full-Temperature and Extreme Environment Stability

Every design detail of the FCU1501 is built to withstand harsh industrial environments:

• Extreme Temperature Immunity: Passed full-temperature cycling tests from -40°C to +85°C, ensuring stable output in cold polar or hot desert environments.

• Triple Electromagnetic Protection: Follows industrial-grade EMC standards, maintaining stability in environments with high electromagnetic interference.

• Physical Lossless Cooling: Utilizes a fanless passive cooling solution, eliminating mechanical failures and dust accumulation, significantly reducing maintenance costs.

Flexible Interfaces: Architecture Consistency for Seamless System Upgrades

FCU1501 innovatively achieves "the same physical size, two interface configurations" architecture consistency.

• Basic Version: Efficient and suitable for standardized connection needs.
• Extended Version: Abundant interface resources, including 8x RS485, 2x CANFD, 8x DI/DO, etc.
• Seamless Evolution: Easily switch between models without altering the control cabinet structure, reducing system integration time.

Smart Operation and Maintenance System: Modern Software Ecosystem and Visual Management

The core value of industrial gateways lies in protocol conversion and convenient maintenance. The FCU1501 excels in this, bridging OT and IT data silos for easier device interconnectivity.

• Protocol Support: Built-in Modbus, MQTT, TCP/IP, SSH, OpenVPN, and other mainstream protocols, covering most industrial communication needs;

• Web Visual Management: Provides a web management interface that can be accessed via a browser to complete network setup, communication parameters, and system status monitoring, improving maintenance efficiency by 50%;

• Out-of-the-Box: Integrated functions such as one-click recovery, 4G status indicator, external power output, and USB flash write, allowing quick deployment without additional accessories, significantly shortening on-site implementation time.

Full-Scene Business Empowerment: Industrial Connectivity Hub Compliant with Global Standards

With powerful performance, rich interfaces, and high reliability, FCU1501 can be widely used in various industrial scenarios, becoming the core hub for digital upgrades.

• Power and Energy Storage: Energy Management Systems (EMS), battery monitoring, new energy site data forwarding.
• Rail Transportation: Roadside equipment monitoring, bridge health management.
• Smart Manufacturing: Production line data collection, PLC remote control, edge logic computing.

The CE, FCC, and RoHS certification process for the FCU1501 has commenced, ensuring compliance with global market safety and environmental standards. With its diverse installation options (such as DIN rail mounting and hanging brackets), it truly achieves "global compatibility, ready to use out of the box."

In edge AI development, hardware selection often determines the fundamental stability and development timeline of a project. To help developers bypass lengthy parameter comparisons, this article will break down key technical points in just 3 minutes, providing an in-depth look at the Forlinx Embedded FET1126-S SoM. Designed based on Rockchip RV1126BJ, this module is specifically engineered to overcome performance bottlenecks and optimize power efficiency for on-device AI deployment. This guide enables a swift evaluation of how well the solution fits project requirements.

Click above to explore the FET1126BJ-S SoM in detail

Overview of FET1126BJ-S Key Features

To enable rapid evaluation of hardware compatibility, the four core technical advantages of this Rockchip RV1126BJ-based System-on-Module (SoM) in edge AI applications are summarized:

• Balanced Performance & Power: 3 TOPS @ INT8 AI computing power, capable of running 2B-parameter models locally, with low-power design suitable for portable and embedded devices.

• Complete Software Ecosystem: Comprehensive BSP support, compatibility with mainstream frameworks, enabling quick onboarding for beginners and shorter development cycles.

• Powerful Vision Processing: Commercial-grade hardware delivering industrial-grade performance, requiring no customization, with controllable mass production costs.

• Industrial-Grade Reliability: Wide operating temperature range (-40℃ to 85℃), electromagnetic interference resistance, suitable for extreme environments such as factory floors and outdoor applications.

1 Minute to Lean Key Specifications

• Core AI Performance: Built-in independent NPU with 3 TOPS @ INT8 computing power, supporting mixed-precision operations and Transformer model optimization. Capable of running 2B-parameter LLMs and multimodal models locally, eliminating cloud dependency, and well-suited for diverse edge AI scenarios.

• Processor Performance: Rockchip RV1126BJ quad-core ARM Cortex-A53, up to 1.6GHz, ensuring smooth multitasking.

• Image Processing: VPU supports 4K@30fps H.264/H.265 hardware decoding, AI-ISP supports 8M@30fps input with denoising, HDR, etc., without consuming NPU resources.

• Storage & Size: LPDDR4 memory (1/2/4GB optional), eMMC storage (8/16/32/64GB optional). Commercial-grade chips cover wide-temperature range; compact 40mm × 40mm form factor, combined with stamp hole and LGA connectors, featuring 237 pins for excellent expandability, saving space in end devices.

1 Minute to Learn Application Scenarios

Forlinx Embedded FET1126BJ-S SoM avoids ''over-engineering'' and focuses on precise fit for mainstream use cases, ensuring every advantage translates into practical applications across popular smart domains:

• Smart Security: Suitable for IP cameras, facial access control systems. Leveraging 3 TOPS AI power to perform real-time facial recognition and anomaly detection without cloud dependency. Fully compatible with offline facial recognition SDK, widely applied in subway facial access and smart community systems.

• Smart Industry: Embedded in industrial inspection equipment, utilizing rich industrial bus interfaces and AI computing for defect detection and equipment failure prediction.

• Smart Construction Sites / Campuses: Paired with edge terminals to enable safety detection (e.g., helmet compliance, intrusion detection) with fast local inference for timely alerts, ensuring construction and campus safety.

• Automotive Aftermarket: Wide-temperature and low-power characteristics make it ideal for dashcams, driver behavior analysis, and other in-vehicle terminals, ensuring stable operation.

Final Minute: Why Choose Forlinx Embedded?

While many RV1126BJ-based solutions exist in the market, for developers focused on project implementation, hardware is just the beginning—reliable ecosystem support and long-term supply are the real necessities:

• Simplified Development: Pre-installed Linux 6.1 OS, complete BSP packages, compatibility with TensorFlow, PyTorch, and other mainstream frameworks. Includes RKNN toolkit and AI algorithm examples, eliminating the need to develop drivers or port models from scratch, significantly shortening R&D cycles.

• Industrial-Grade Quality Assurance: All Forlinx Embedded products undergo rigorous industrial environment testing in labs to ensure stable, reliable quality, with 10–15 years longevity and guaranteed long-term supply.

• Proven Industry Expertise: With 20 years of embedded technology experience, Forlinx Embedded serves over 40,000 enterprise clients worldwide. As a professional supplier with in-house smart manufacturing lines and full-chain R&D capabilities, Forlinx offers not just SoMs, but end-to-end support from development evaluation to mass production.

OK—just 3 minutes!

Centered on the Rockchip RV1126BJ processor, the Forlinx Embedded FET1126BJ-S SoM delivers a balanced combination of computing power, energy efficiency, reliability, and cost-effectiveness. It is an optimal choice for edge AI deployment, suitable for both entry-level developers and enterprises scaling to mass production across a variety of popular smart application scenarios.

I. Overview

VLAN Concept: Virtual Local Area Network, which creates multiple ''virtual'' mini-switches on a single physical switch. Each mini-switch, or VLAN, acts as a separate broadcast domain, isolating network traffic between them at Layer 2 (the data link layer), similar to how they would operate if connected to different physical switches.

To implement this functionality, the key is to insert a 4-byte VLAN tag into a standard Ethernet frame. This tag includes a 12-bit VLAN ID that identifies the specific VLAN to which the frame belongs. Devices that support VLANs use this ID to differentiate and manage traffic from various virtual local area networks (VLANs).

II. Configuration Steps

1. Create a VLAN Virtual Interface

This file is used to create a virtual VLAN network device at system startup. In this case, "Name=vlan100" is the name assigned to the VLAN interface, and "Id=100" is the VLAN ID.

root@localhost:~# vi /etc/systemd/network/vlan100.netdev
[NetDev]
Name=vlan100
Kind=vlan
[VLAN]
Id=100

2. Configure the IP Address for the VLAN Interface

This file is used to assign IP addresses to the VLAN device that was created previously and to activate the configuration. If the VLAN needs to access an external network, you can configure a gateway. For example: Gateway=192.168.0.1.

root@localhost:~# vi /etc/systemd/network/vlan100.network
[Match]
Name=vlan100
[Network]
Address=192.168.0.70/24

3. Configure the Parent Interface

To enable VLAN traffic to pass through the physical network interface card, make sure that the parent interface (i.e. fm1-mac3) is active but does not have an IP address assigned to it (unless the interface has the IP address of the native VLAN). This step is very important as it informs the systemd-networkd network service that the primary function of the fm1-mac3 interface is to carry VLAN vlan100.

root@localhost:~# vi /etc/systemd/network/fm1-mac3.network
[Match]
Name=fm1-mac3
[Network]
VLAN=vlan100
# Key Point: Do not configure an IP address; instead, declare that this interface carries VLANs.
# If the physical interface needs to carry multiple VLANs in the topology, write: VLAN=vlan100,vlan200

4. Apply the Configuration

After creating the configuration files, restart the systemd-networkd service to activate the settings.

root@localhost:~# systemctl restart systemd-networkd

III. Verification

1. Configuration Information Declaration

VLAN configuration for Development Board 1

VLAN configuration for Development Board 2

2. Same VLAN ID Test

Now, connect the two network ports (192.168.0.78 and 192.168.0.70), which both have a VLAN ID of 100, directly using an Ethernet cable. Test them by pinging each other.

3. Different VLAN ID Test

The test shows that even IP addresses within the same subnet cannot respond to each other if their VLAN IDs differ.

In summary, testing VLAN functionality requires creating a virtual VLAN interface and linking it to a physically existing network port. This physical port can carry multiple VLAN interfaces. Subsequently, configure different VLAN IDs as needed to verify VLAN behavior.

IV. Capturing Packets to View VLAN Tags

When devices with the same VLAN ID communicate, the VLAN-tagged data frames can also be observed using tcpdump, as shown in the image below.

1. VLAN Identifier

The prominent vlan 100 in each line clearly indicates that the packet belongs to the virtual LAN with VLAN ID 100.

2. 802.1Q Tag

The ethertype 802.1Q (0x8100) in each line indicates that the Ethernet frame uses the 802.1Q protocol, which is the IEEE-defined standard for VLAN tagging. The hexadecimal value 0x8100 is the ''TPID'' embedded in the Ethernet frame header, signaling to network devices that ''this frame carries a VLAN tag.''

V. Setting VLAN ID on a PC

If you need to perform VLAN testing between a Windows PC and the development board, follow these steps to manually specify the VLAN ID for the network adapter:

1. Access Network Connections

Open the Control Panel, go to ''Network and Sharing Center,'' and click ''Change Adapter Settings'' on the left. Locate the physical network interface card connected to the development board.

2. Open ''Network Card Properties''

Right-click the network adapter icon and select ''Properties.'' In the pop-up window, click the ''Configure (C)...'' button.

3. Edit ''Advanced Settings''

In the network adapter settings window, switch to the ''Advanced'' tab. Scroll down in the ''Properties (P)'' list on the left to find ''VLAN ID''.

4. Set the VLAN ID

In the ''Value (V)'' input field on the right, enter the VLAN ID that matches the development board (for example, 100). Click ''OK'' to save the settings. The network adapter will then reload, applying the VLAN tags.

NUREMBERG, Germany—March 10, 2026—Forlinx Embedded presents its latest range of embedded modules and application-ready solutions at embedded world 2026 (Booth 3-561).

Pin-to-Pin Compatible SoMs & Edge AI Demos

At the show, we showcase diverse embedded modules including system-on-module, single-board-computer and embedded PCs. Many engineers are looking for high-scalability module to reduce their time and cost. To address this need, we introduced our new Pin-to-Pin compatible SoM series——UP4 Family.

With this UP4 P2P series, you can directly replace an older one without requiring changes to the baseboard design, wiring, or software. This means products can easily scale across performance tiers, allowing the same carrier board to support different SoMs depending on project requirements.

Highlights are below:

• LCC + LGA 487 available pins

• 40mm×40mm 1.2mm thickness

• One carrier board works for multiple SoMs

• SoC cross-brand compatible

• Various peripheral interfaces ready-to-use

• 48 reserved pin-outs

  

At embedded world 2026, we returned to the event with a strong focuses on real-world AI inference, industrial networking, and multi-display ARM computing, designed for industrial automation, smart energy, intelligent security, and edge AI applications.

• High-Performance AI Pipeline: A collaboration with NXP featuring the i.MX 95 applications processor and the Ara240 Discrete NPU. By combining the 8 eTOPS Neutron NPU with a 40 eTOPS accelerator, this solution handles complex multi-modal queries for industrial security.

• 360° Surround-View: An RV1126B-based solution that stitches four AHD camera feeds into a seamless panoramic view, optimized for power efficiency.

• Face Recognition & Tracking: An RV1126B 3TOPS NPU-driven system for instant feature extraction and local database matching.

• Edge Intelligence: The FCU3501 embedded computer demonstrates local video analytics. With a 6TOPS NPU, it can process up to 16 camera streams simultaneously for real-time surveillance.

• Intelligent Display Solution: The i.MX 94x solution features a built-in TSN switch and Cortex-M7/M33 real-time cores. It is designed for edge computing tasks that require both high-speed control and functional safety.

• Battery Management (BMS): A dedicated solution for Energy Storage Systems (ESS) using the T536 SoC, supporting 8×CAN interfaces for large-scale battery data acquisition.

• EV Charger HMI: A UI demo using the TI AM62L32 and LVGL library, showing fluid animations and data visualization while maintaining low power consumption.

  

Strategic Ecosystem: NXP & ROCKCHIP & CRA

As a Gold Partner of NXP Semiconductors, Forlinx continues to deepen its collaboration by expanding the i.MX 95 ecosystem with high-performance inference modules. At the heart of our presence at the show is the jointly multimodal industrial security demo based on the i.MX 95 processor and Ara240 computing card, enabling secure, AI-ready, and scalable edge solutions ranging from different industrial applications.

Forlinx also maintains a long-term partnership with Rockchip. At Embedded World 2026, we showcased our latest system on modules based on the Rockchip RK3588, Rockchip RV1126, and Rockchip RK3506 platforms at both Rockchip booth and Forlinx booth, highlighting our close collaboration in embedded AI solutions.

To address growing cybersecurity regulations such as the EU Cyber Resilience Act (CRA), Forlinx presented its CRA-ready embedded platform, the FCU2601. With dual IEC 62443 certifications, the platform helps device manufacturers accelerate compliance with global cybersecurity regulations while ensuring robust industrial-grade security.

Having gone through the entire certification process ourselves, we are deeply familiar with the complex documentation and compliance workflow. This experience allows us to share proven practices with customers and help simplify the path to market, especially for products targeting the European market.

Global Dealership Showcases

Quad-Screen Display Solution built on the OK3588 single board computer from DATA MODUL in Germany: Powered by the Rockchip RK3588 processor, the system supports four independent displays with different video content from a single embedded board, eliminating the need for multiple boards or external graphics processors.

AI Image Recognition Solution built on the OK3576 single board computer from Demsay in Turkey: Demonstrating efficient local object recognition using YOLOv5 on the 6TOPS NPU of the RK3576 platform.

About Forlinx Embedded

Forlinx Embedded is a leading designer and manufacturer of ARM-based embedded solutions, including System-on-Modules (SOMs), Single Board Computers (SBCs), and industrial embedded PCs. Partnering with top System-on-Chip vendors such as NXP, Texas Instruments, Rockchip, and Allwinner, we deliver high-quality products compliant with CE, FCC, and RoHS standards. With in-house production certified to ISO 9001, ISO 13485, ISO 45001, and ISO 14001, as well as dedicated environmental and EMC laboratories and SMT lines, we ensure reliable manufacturing with an annual System-on-Module output of 1 million units.

Contact us for UP4 Family Details

In embedded Linux development, serial port debugging is commonly favored for its simplicity and accessibility. However, when deploying applications in an AMP-based real-time environment, these limitations become significantly more pronounced—namely poor real-time capability, high system overhead, and limited debugging depth. These drawbacks are especially evident in multi-core collaborative workflows, where tasks such as precisely analyzing inter-core synchronization mechanisms, interrupt timing behavior, or shared-resource conflicts often exceed the capabilities of traditional serial debugging methods.

JTAG Debugging Technology: A Precision Solution to This Pain Point

JTAG (Joint Test Action Group) debugging technology is an internationally standardized technology widely used in embedded system development and hardware testing. It possesses deep interaction and real-time control capabilities, allowing users to set breakpoints online and perform single-step debugging, while also supporting the real-time viewing and modification of register and variable values. More critically, its non-intrusive debugging mode eliminates the need to insert print statements into the code, preserving the original program logic and operational performance to the greatest extent. It can also pause the CPU at any time to accurately capture the complete system state at a given moment, enabling the rapid localization of various complex debugging challenges.

Solution Architecture: An Integrated JTAG Debugging Workflow

Here, we use the Forlinx OK3568-C development board (based on the Rk3568) for the demonstration:

Forlinx delivers a tightly integrated toolchain that enables seamless JTAG debugging within a Windows environment.

There are three key layers: the Development Host, the Hardware Interface, and the Target Device.

The development host layer is based on Eclipse IDE, integrates CDT development tools and GNU MCU Eclipse plug-ins, and provides a friendly graphical interface. Debugging instructions are generated by GDB, converted by OpenOCD protocol, and finally communicated with RK3568 chip through J-Link hardware interface.

The key strength of this architecture lies in its integration and transparency. Developers can focus entirely on code logic and problem-solving without dealing with low-level communication complexities.

Debugging in Practice: A Visual and Interactive Workflow

1. Breakpoint Control

With Forlinx's JTAG solution, breakpoint debugging is intuitive. Engineers can set breakpoints by double-clicking on the left side of the code, where program execution automatically pauses, making it easy to check the state of all core variables, registers, and memory at the moment.

(1) Set a breakpoint: Double-click the left side of the code. When a "blue ball" appears, it indicates that there is a breakpoint here. The program will stop here.

(2) Cancel the breakpoint: Double-click the "blue ball" on the left side of the code. When the ball disappears, it means that the breakpoint here is cancelled.

(3) Ignore all breakpoints: At this time, all breakpoints are cancelled and the program can run at full speed.

2. Single-step and Multi-step Execution

There are several modes of single-step execution: Step Over can skip the function call, Step Into can go deep inside the function, and Step Return can quickly execute the rest of the current function.

Multi-step execution: including "Run to the cursor" and "Continue to run" to meet the needs of different scenarios.

3. Variable Inspection

(1) Local Variables update in real time within the current function scope and can be modified directly.

(2) Global Variables remain accessible throughout the session, providing a live view of system-wide state when paused.

4. Memory Inspection

(1) Direct Access and Modification

Using the Memory Browser, engineers can read any memory or register address to inspect content or verify configurations.

(2) Live Editing

Values can be written directly to specified addresses, enabling dynamic data changes or peripheral register updates.

The JTAG debugging solution outlined above, tailored for AMP multi-core collaborative scenarios, significantly lowers the technical barrier to entry for real-time core debugging. By visualizing the debugging process and enabling simultaneous monitoring of AMP real-time core states, it makes actions like program jumps and task switching much clearer. We hope this solution will be helpful to your development work.

Background

In a Linux system, when two network interface cards (NICs) are configured with IP addresses within the same subnet, the default routing table generally utilizes only the most recently activated NIC interface. Consequently, the other NIC may be unable to communicate as intended. To address this issue, policy routing can be implemented. This allows each network interface to operate independently, effectively preventing routing conflicts.

Kernel configuration

First, confirm that policy routing support is enabled in the kernel. By default, this feature is not activated, so manual configuration is required:

Access the kernel source directory at /62xx/OK62xx-linux-sdk/OK62xx-linux-kernel/ and run the following command:

forlinx@ubuntu:~/62xx/OK62xx-linux-sdk/OK62xx-linux-kernel$ 
. /opt/arago-2023.04/environment-setup-aarch64-oe-linux 
forlinx@ubuntu:~/62xx/OK62xx-linux-sdk/OK62xx-linux-kernel$ make menuconfig 

Based on the following screenshot, locate the policy routing configuration path.

Select the indicated option with the arrow, press the Y key to compile it into the kernel.

Then select Save.

Click OK.

Repeatedly press ESC to exit

Next, navigate to the directory ~/62xx/OK62xx-linux-sdk and begin compiling the kernel based on the core board parameters:

forlinx@ubuntu:~/62xx/OK62xx-linux-sdk$ sudo ./build.sh kernel hsfs 2g

Enter N when prompted.

If the following message appears, press and hold the Enter key:

Development Board Configuration

Once compilation is successful, move the Image file from the /62xx/OK62xx-linux-sdk/images directory to the /boot/ directory on the development board.

Execute

root@OK62xx:/# sync
root@OK62xx:/# reboot

Configuring Routing Tables

After rebooting, open the routing table configuration file /etc/iproute2/rt_tables:

root@OK62xx:/# vi /etc/iproute2/rt_tables

Add two routing tables:

100 eth0table

200 eth1table

Save.

Configuring Policy Routing

Next, set up routing policies for each network interface. Assuming eth0 has IP address 172.20.2.131 and eth1 has 172.20.2.132, execute the following commands to configure routing policies:

Add routing policies for eth0:

root@OK62xx:/# ip route add 172.20.2.0/24 dev eth0 table eth0table
root@OK62xx:/# ip route add default via 172.20.2.254 dev eth0 table eth0table
root@OK62xx:/# ip rule add from 172.20.2.131 table eth0table

1. First command: Specify that network segment 172.20.2.0/24 should use eth0 as its egress interface.

2. Second command: Set the default gateway for external network access (adjust gateway IP as needed).

3. Third command: Route all traffic from IP 172.20.2.131 through routing table eth0table.

Add routing policies for eth1:

root@OK62xx:/# ip route add 172.20.2.0/24 dev eth1 table eth1table
root@OK62xx:/# ip route add default via 172.20.2.254 dev eth1 table eth1table
root@OK62xx:/# ip rule add from 172.20.2.132 table eth1table

Test

At this point, you can verify whether the configuration is successful by using the ping command on a PC:

When the Ethernet cable is connected to eth0, you should be able to reach 172.20.2.131. When connected to eth1, you should be able to reach 172.20.2.132.

Both IP addresses should be ping-able.

Persistent Configuration

Policy routing configurations, like network settings, are not retained after reboot—they need to be automatically applied on startup. Therefore, a service that runs at boot must be added.

Create a startup service for this purpose.

root@OK62xx:/# vi /etc/systemd/system/persistent-routes.service

Add the followings:

[Unit]
Description=Persistent Static Routes and Rules
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/bin/persistent-routes.sh
[Install]
WantedBy=multi-user.target

Add script.

root@OK62xx:/# vi /usr/bin/persistent-routes.sh

Add the followings:

#!/bin/sh
sleep 5
# Add Routes and Rules
ip route add 172.20.2.0/24 dev eth1 table eth1table
ip route add default via 172.20.2.254 dev eth1 table eth1table
ip rule add from 172.20.2.132 table eth1table
ip route add 172.20.2.0/24 dev eth0 table eth0table
ip route add default via 172.20.2.254 dev eth0 table eth0table
ip rule add from 172.20.2.131 table eth0table

Give permission to the script:

root@OK62xx:/# chmod 777 /usr/bin/persistent-routes.sh

Enable the service

root@OK62xx:/# systemctl enable persistent-routes.service

This way, the configuration is automatically applied upon every system startup.

Summary

Through the steps above, dual network interfaces in the same subnet have been successfully configured, with policy routing avoiding routing conflicts. After configuration, both network interfaces can operate stably for network debugging or data transmission, providing reliable support for high‑availability embedded applications.

Through the steps above, dual network interfaces in the same subnet have been successfully configured on the OK6232 development board, with policy routing effectively avoiding routing conflicts. After configuration, both network interfaces of the FET6232-C core board (based on the TI AM62x processor) can operate stably for network debugging or data transmission, providing reliable support for high‑availability embedded applications developed by Forlinx Embedded.

March 10, 2026 — embedded world 2026, the premier annual global event for embedded technology, kicked off grandly at the Nuremberg Exhibition Centre in Germany.

At the exhibition (Booth NO.3-561), Forlinx Embedded made a strong return, unveiling a series of cutting-edge products and integrated solutions designed for diverse scenarios. This showcase highlighted the innovative strength and competitive edge of China's embedded technology sector, reinforcing Forlinx's commitment to accelerating its global footprint

01 Comprehensive & Diversified

At the exhibition, Forlinx Embedded showcased a diverse product lineup, including embedded SoMs, development boards, industrial computers, and edge computing gateways,based on leading chip platforms from NXP, Rockchip, Allwinner, and TI.

The demos highlighted the high performance and reliability of its solutions in edge AI, industrial automation, smart displays, and EV charging. They emphasized Forlinx's collaboration with leading global chip manufacturers and its expertise in hardware R&D and integrated solution development.

02 Full-Scenario & Engaging

Multiple first-launch dynamic demo at the booth:

• i.MX 9596 + Ara240 perception and understanding platform

• i.MX 94x smart display solution

• FCU3501 edge computing gateway (RK3588J-based) with 16 x AI video processing

• RV1126B four-camera panoramic stitching system

• T536 8 x CAN technology module

• TI AM62L interactive EV charger solution

These cutting-edge platforms attracted keen interest and engagement from attendees.

Swipe Right to View More > >

Also on display is the FCU2601 embedded control unit—already certified with IEC 62443-4-1 and IEC 62443-4-2 security standards—and EN 18031 (RED) cybersecurity certification. This ensures compliance with regulations such as the EU Cyber Resilience Act (CRA) and supports secure, compliant deployments worldwide.

03 Ecosystem Collaboration, Co-Exhibition Experience

At embedded world 2026, Forlinx Embedded continued to strengthen cooperation with chip manufacturers. Partners including NXP, Rockchip, and TI provided valuable joint exhibition opportunities. At their respective booths, Forlinx SoMs, development boards, and dynamic demos—developed around each partner's leading products—drew strong interest from international visitors.

04 Persistent Dedication & Innovation

With over 20 years of dedication to embedded technology, Forlinx Embedded is committed to innovation, quality, and customer success. Forlinx's presence at embedded world Germany was more than a branding display; it represented a strategic advance in forging international partnerships and accelerating global market growth.

Looking forward, Forlinx Embedded will maintain its commitment to innovation, prioritize customer needs, and continuously refine its products. By deepening collaboration with global partners, Forlinx aims to deliver advanced embedded solutions that empower industries worldwide and drive sustainable growth in the embedded ecosystem.

Join us at Booth NO.3-561 on March 11–12 for more insights, demonstrations, and conversations about the future of embedded technology.

Together, we build what's next.

The global premier event for embedded systems — Embedded World 2026 — will take place in Nuremberg, Germany, from March 10 to 12. As a Gold Partner of NXP® Semiconductors, Forlinx will be present at Booth H3-561 to showcase breakthroughs and real-world applications of AI in industrial security and beyond.

During the event, Forlinx will showcase a diverse range of embedded products including System on Modules (SoMs), development boards, and embedded PCs based on NXP's applications processors, including the i.MX 9, i.MX 8, and i.MX6 processors, Layerscape® processors, and i.MX RT crossover MCU series. Dynamic demos will cover multiple scenarios such as edge AI, smart industry, and smart cities.

A highlight will be the debut of a Multi‑Modal Demo for Industrial Security based on the NXP i.MX 95 applications processor and Ara240 Computing Card, co‑developed by Forlinx and NXP. The solution establishes an efficient dual‑hardware inference pipeline by integrating the 8 eTOPS eIQ® Neutron NPU in NXP's i.MX 95 applications processor with the up to 40 eTOPS Ara240 Discrete NPU (DNPU) accelerator, thereby closing the perception‑inference‑action loop and advancing industrial security.

The demo illustrates three core advantages:

• Hybrid NPU Acceleration for Efficient Dynamic Task Allocation: Achieving efficient task division and collaboration between the i.MX 95 applications processor and Ara240 DNPU for real‑time video analysis and multi‑modal query tasks.
• Edge‑End Collaboration with High Efficiency & Reliability: Leverages an integrated edge‑to‑end inference architecture to ensure on‑device recognition and search tasks are performed with both low latency and high reliability.
• Multi‑Modal Generalization: Empowering industrial scenarios to achieve zero-shot recognition and understanding vision and language.

Since first collaborating in 2014, Forlinx and NXP have developed over 20 embedded solutions utilizing NXP chips, driving intelligent transformation across various industries globally. Moving forward, Forlinx is committed to strengthening the collaborative partnership with NXP, dedicated to providing global customers with superior and highly reliable embedded products and services, and working together to foster a thriving and dynamic industry ecosystem.

We warmly invite industry peers, partners, and media friends to join us at the Forlinx booth (H3-561) during Embedded World 2026 for face‑to‑face communication. Let's explore the future of embedded intelligence and AI integration—see you in Nuremberg!

Recently, Forlinx Embedded has achieved a significant milestone with its FCU2601 embedded control unit securing dual IEC 62443 certifications:

IEC 62443-4-1 for secure development processes and IEC 62443-4-2 for component security. This accomplishment underscores the establishment of a comprehensive product security lifecycle system in industrial control and edge computing, positioning the company to proactively meet upcoming regulations such as the EU's Cyber Resilience Act (CRA).

Following the EN 18031 (RED) cybersecurity certification earned in February of this year, this achievement represents another milestone breakthrough for Forlinx Embedded in the field of industrial and critical infrastructure cybersecurity, demonstrating that its security development framework and product security capabilities now stand at an internationally leading level.

Certifications: IEC 62443-4-1 & IEC 62443-4-2

Why Is IEC 62443 the ''Gold Standard'' for Industrial Cybersecurity?

As Industry 4.0 and smart manufacturing accelerate, industrial control systems are increasingly exposed to cyber threats such as ransomware and advanced persistent threats (APTs), which can disrupt operations, compromise infrastructure, and pose serious safety risks.

The IEC 62443 series—jointly developed by ISA and IEC—is globally regarded as the defining cybersecurity framework for industrial automation and control systems. Often described as the ''constitution'' of industrial cybersecurity. It covers the entire lifecycle—from product development and system integration to operation and maintenance—and imposes stringent technical requirements on embedded devices, network equipment, and more.

By achieving these certifications, the FCU2601 demonstrates compliance with international top-tier standards in key areas including:

• Secure development lifecycle (SDL)

• Access control and authentication

• Data integrity and confidentiality

• Vulnerability management and patch governance

This provides a robust, certified foundation for deploying secure embedded control solutions in sensitive and critical environments.

Click the image above to learn more about the FCU2601 embedded control unit.

CRA Compliance Is Now Imminent！Non‑Compliance Risks Heavy Fines & Market Bans

The EU Cyber Resilience Act (CRA) entered into force in December 2024 and will become fully applicable by December 11, 2027. Under the CRA, all hardware and software products containing digital elements must comply with mandatory cybersecurity requirements throughout their lifecycle to obtain CE marking and access the EU market.

Penalties for non‑compliance are severe: Serious breaches may lead to fines of up to €15 million or 2.5% of worldwide annual turnover (whichever is higher). Non‑compliant products will be banned from sale in the EU market.

The CRA classifies products into three categories: General, Critical Class I, and Critical Class II. Industrial control systems, energy storage gateways, smart meters, and similar equipment are considered critical and require independent third‑party certification. For businesses aiming to operate globally, CRA compliance is no longer optional — it is a mandatory gateway to international markets.

Key CRA Compliance Deadlines

With less than six months until vulnerability reporting becomes mandatory on September 11, 2026, time is pressing.

A complete IEC 62443 certification process typically takes 6–9 months. Delaying your preparation now could result in missed deadlines, failure to demonstrate compliance to EU regulators, and significant legal and commercial exposure.

Forlinx Embedded: Your Partner for Streamlined CRA Compliance

As a specialist in embedded intelligent device core platforms, Forlinx Embedded understands the compliance challenges faced by globally expanding enterprises. Forlinx dual IEC 62443 certifications not only validate Forlinx internationally recognized security capabilities but also enable us to share proven methodologies with customers—helping them meet CRA and other global cybersecurity regulations efficiently and cost‑effectively.

What Forlinx Can Do

1. Secure Development Lifecycle (SDL) Consulting

   Full-cycle security development framework aligned with IEC 62443-4-1, covering requirements, design, coding, testing, and maintenance.

2. Product Security Design & Assessment

   Threat modeling, security architecture design, penetration testing, and vulnerability scanning for embedded devices, gateways, controllers, and more, following IEC 62443-4-2.

3. SBOM Generation & Management

   Automated Software Bill of Materials generation, risk analysis, open‑source vulnerability tracking, and timely security update response in compliance with CRA requirements.

4. Vulnerability Management & Security Updates

   Established vulnerability response processes and secure update/patch mechanisms for ongoing product lifecycle protection.

5. Pre‑Certification Testing & Compliance Guidance

   Leverage our certification experience to conduct pre‑testing, identify issues early, shorten certification cycles, and reduce overall compliance costs.

The IEC 62443 certifications reflect more than just product compliance—they represent a globally recognized validation of Forlinx end-to-end security development processes and technical maturity.

Built upon this robust and proven framework, Forlinx systematically replicate these capabilities across customized projects, empowering customers to achieve CRA compliance efficiently for PLCs, gateways, HMIs, RTUs, industrial computers, and other platform products—accelerating their entry into international markets.

Security Is the Baseline—and Your Accelerator to Global Markets

From EN 18031 to IEC 62443, every step Forlinx Embedded takes in industrial cybersecurity is deliberate, rigorous, and outcome-driven. Forlinx recognizes that the future of Industry 4.0 hinges not only on operational efficiency but also on resilient, secure infrastructure. With the full enforcement of the EU CRA approaching, partnering with Forlinx Embedded provides a compliant, reliable, and low-risk pathway to global expansion.

If you are planning to enter or expand in international markets—or seek practical, experienced guidance on CRA and IEC 62443 certification—reach out today. With deep certification expertise and a partner-oriented approach, Forlinx Embedded is ready to support your globalization journey and explore global opportunities together.

This technical guide provides professional methods for integrating user product files, applications, and shared libraries into the OK3562-linux-source. By leveraging the Buildroot fs-overlay mechanism, you can compile custom assets directly into the system image, which effectively avoids the need to separately copy programs to the OK3562-C ARM development board after burning the firmware.

Modification Method

Method 1: Compile directly into the source code

Location path:

User programs can be copied to the/OK3562-linux-source/build root/board/forlinx/ok3562/fs-overlay/usr/bin directory.

The configuration file can be copied to the/OK3562-linux-source/build root/board/forlinx/ok3562/fs-overlay/etc directory.

The library file can be copied to the/OK3562-linux-source/buildroot/board/forlinx/ok3562/fs-overlay/lib directory.

You can also create your own folders in the/OK3562-linux-source/buildroot/board/forlinx/ok3562/fs-overlay/directory to store their own files.

This article takes copying aarch64-buildroot-linux-gnu _ sdk-buildroot. tar. gz compressed package as an example.

1. Copy the file to the specified path

Create a directory called test at/OK3562-linux-source/buildroot/board/forlinx/ok3562/fs-overlay/. Place the aarch64-buildroot-linux-gnu _ SDK-buildroot. tar. gz archive in this directory:

2. Source Code Compilation

Execute the full compilation command

./build. sh all

3. Development Board Verification

Using the update.img generated by compilation, boot the device. You can see a directory named test exists in the file system.

In summary, the test was successful.

This configuration is a one-time setup. The added files will be automatically included in all future image compilations, even after modifications to the source code’s device tree or drivers.

4. Removing the Added Files

When deleting, in addition to the files added in
OK3562-linux-source/buildroot/board/forlinx/ok3562/fs-overlay/,
you also need to search whether there are any in
OK3562-linux-source/buildroot/output.
For example, when compiling the above compressed package,
test/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz was also created in
OK3562-linux-source/buildroot/output/OK3562_Linux/target/,
and this also needs to be manually deleted.

After deleting, a recompilation is required.

Method 2: Mounting rootfs.ext2

Once the source code is compiled, or for temporarily adding files to a single image instance, you can directly mount the rootfs.ext2 file.

rootfs.ext2 path：OK3562-linux-source/buildroot/output/OK3562_Linux/images

1. After mounting rootfs.ext2, transfer files into it

forlinx@ubuntu:~/work/OK3562-linux-source$ cd buildroot/output/OK3562_Linux/images
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ ls
rootfs.cpio rootfs.cpio.gz rootfs.ext2 rootfs.ext4 rootfs.squashfs rootfs.tar
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ mkdir rootfs
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ sudo mount rootfs.ext2 rootfs
[sudo] forlinx password:
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ cd rootfs/
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images/rootfs$ ls
bin busybox.fragment dev etc home info lib lib64 linuxrc lost+found media mnt oem opt proc root run sbin sys test tmp userdata usr var
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images/rootfs$ sudo cp /mnt/hgfs/share/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz ./
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images/rootfs$ cd ..
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ sudo umount rootfs

In summary, the file can be directly placed into the image generated by compilation.

Note: The default size of rootfs.ext2 is 1.7G. If you place files that are too large using this method, an error will occur: cp: Error writing './aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz': No space left on device. You can expand rootfs.ext2 using the following commands before placing files. Make sure to unmount rootfs.ext2 before executing these commands:

forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ dd if=/dev/zero bs=1M count=0 seek=2000 of=rootfs.ext2 // This command does not write any data to rootfs.ext2; it only expands the file size to 2G.
0+0 write in
0+0 write out
0 bytes copied, 0.000348683 s, 0.0 kB/s
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ e2fsck -f rootfs.ext2
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: 9137/70128 files (0.1% non-contiguous), 249143/280320 blocks
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ resize2fs rootfs.ext2
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on rootfs.ext2 to 512000 blocks (4k per block).
The filesystem on rootfs.ext2 is now 512000 blocks (4k per block).
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ ls -lh
Total 3.5G
drwxrwxr-x 2 forlinx forlinx 4.0K January 7 09:30 rootfs
-rw-r--r-- 1 forlinx forlinx 906M January 7 11:13 rootfs.cpio
-rw-r--r-- 1 forlinx forlinx 385M January 7 11:15 rootfs.cpio.gz
-rw-r--r-- 1 forlinx forlinx 2.0G January 7 11:21 rootfs.ext2
lrwxrwxrwx 1 forlinx forlinx 11 January 7 11:15 rootfs.ext4 -> rootfs.ext2
drwxrwxr-x 2 forlinx forlinx 4.0K January 7 10:02 rootfs_old
-rw-r--r-- 1 forlinx forlinx 383M January 7 11:15 rootfs.squashfs
-rw-r--r-- 1 forlinx forlinx 920M January 7 11:16 rootfs.tar
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ sudo mount rootfs.ext2 rootfs
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ cd rootfs/
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images/rootfs$ sudo cp /mnt/hgfs/share/aarch64-buildroot-linux-gnu_sdk-buildroot.tar.gz ./
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images/rootfs$ cd ..
forlinx@ubuntu:~/work/OK3562-linux-source/buildroot/output/OK3562_Linux/images$ sudo umount rootfs

2. Image Updates

forlinx@ubuntu:~/work/OK3562-linux-source$ ./build.sh updateimg

3. Development Board Verification

Development Board Verification

In summary, the test was successful.

Note: This method only takes effect for the current build. The modifications will be overwritten if the source code is recompiled, requiring the process to be repeated.

Join Us in Nuremberg

From March 10–12, 2026, NürnbergMesse will once again become the global meeting point for the embedded community. Forlinx Embedded invites you to join us on-site to explore industrial-grade embedded platforms and gain practical insights for your next embedded project.

What to Expect at Booth 3-561

• Explore Industrial-Grade Embedded Platforms
  Get hands-on with our latest SoMs, SBCs, and embedded computers built on leading silicon platforms from NXP, Texas Instruments, Rockchip, and Allwinner.
• Discover Real-World Edge AI & Industry Solutions
  Experience live demos showcasing cutting-edge solutions for Industrial Automation, Edge AI, IoT, Smart Medical, and Intelligent Transportation.
• Engage in Face-to-Face Technical Exchange
  Consult directly with Forlinx’s engineering experts to discuss system architecture, performance optimization, and long-term platform planning for your next product.

Exhibition Information

Opening Hours

Tuesday, 10.3.2026: 09:00 – 18:00

Wednesday, 11.3.2026: 09:00 – 18:00

Thursday, 12.3.2026: 09:00 – 17:00

Why embedded world 2026?

As the No. 1 global hub for the embedded community, embedded world brings together leading experts, silicon vendors, system integrators, and industry decision-makers from around the world.

Forlinx Embedded has participated in embedded world for three consecutive years, building deep experience and long-term partnerships across the ecosystem. We are committed to collaborating with industry partners, customers, and developers to explore the next frontier of embedded technology. Let’s drive industry progress together.

Request Your Free Visitor Ticket

Don’t miss out on the industry's premier event! Forlinx Embedded is offering a limited number of complimentary voucher codes for our partners and customers. Use the code below to secure your free entry and join us for a technical consultation.

Apply for Your Free SoM Kit

This article provides a detailed guide on successfully porting the Mobilenet_V3 model for handwritten digit recognition on the OKMX8MP development board under the Linux 5.4.70 environment. Through specific steps—including dataset import, model training, validation, and conversion to TensorFlow Lite format—this tutorial will help you efficiently implement image recognition tasks on embedded systems.

Copyright

All depictions of the eIQ® Toolkit, eIQ® Portal interface, and related trademarks appearing herein are the property of NXP B.V.

TensorFlow™ is a trademark owned by Google LLC.

This tutorial is intended solely for technical exchange and to demonstrate the AI inference capabilities of the OKMX8MP development board.

1. Import Dataset

Before model training, the dataset must be prepared. If no ready-to-use dataset is available, one may select *Import dataset* to choose from the tool's built-in example datasets. If a custom dataset is prepared, select *Create blank project* and import it directly, as shown in the figure below.

The dataset used in this article comes from the tool and is loaded via TensorFlow, as shown below.

From the dropdown menu in the top-left corner, you can select from various common TensorFlow datasets. This article uses the MNIST dataset, which includes 60,000 handwritten digits as the training set and 10,000 handwritten digits as the validation set. Furthermore, the tool provides three other optional datasets:

• cifar10: Color images of 10 classes, with 50,000 images as the training set and 10,000 images as the validation set.
• horses_or_humans: 2 classes—humans and horses. There are 1,027 human images and 1,027 horse images.
• tf_flowers: 5 classes, totaling 3,670 images of flowers.

In the top-left corner, there is also a Problem type dropdown menu for selecting the task type. The current version of the tool offers two types: Image Classification and Object Detection. For object detection tasks, only the coco/2017 dataset is currently provided, capable of detecting 80 types of objects, with 118,287 images as the training set, 5,000 images as the validation set, and 20,288 images as the test set.

After selecting the dataset, click the IMPORT button, choose a save directory, and wait for the import to complete, as illustrated below:

Select Save Directory

Waiting for Dataset Import

Once imported, you can view the MNIST dataset: the left panel displays category and quantity statistics for each image, while the right panel shows specific images from the dataset. Selecting an image allows you to view its details in the section below.

2. Model Training

After importing the dataset, the next step is to select a model. As shown in the figure below, click the SELECT MODEL button.

The model selection interface is shown below. The left side of this interface presents three different options with the following functions:

• RESTORE MODEL: Load the model used in the previous session.
• BASE MODELS: Select from the foundational models provided by the tool.
• Choose models created or imported by the user.

  The right side of the interface displays models for different task types, such as classification models, image segmentation models, and object detection models.

This article uses the foundational model provided by eIQ Portal, therefore BASE MODELS is selected, as shown in the figure below.

The following figure shows several foundational models provided by the tool. This article employs the lightweight mobilenet_v3 model. The detailed architecture of different models can be viewed using the MODEL TOOL function on the tool's main interface.

After selecting the model, the process proceeds to the training stage, with the interface shown below. The left side of the interface displays the key hyper parameters adjustable during training, including learning rate, batch size, and number of epochs. You can adjust these based on task requirements and hardware constraints. The right side of the interface is used to display relevant information during training, such as curves tracking the model's accuracy and loss values.

The parameter configuration used for this training is shown below. After configuration, click ''Start Training''.

The training process is as follows. You can intuitively view the model's accuracy and loss value on the right side.

The model training is completed as shown in the figure below. You can set different ranges to view the steps information.

3. Model Validation

After model training is completed, the model needs to be validated. Select VALIDATE to enter the model validation phase. As shown in the figure below.

The validation interface also requires setting parameters, including Softmax Threshold and some quantization parameters.

The parameters set in this document are as follows. After configuration, click Validate as shown below.

Then, the interface will display the model's confusion matrix and accuracy, as shown below.

4. Model Conversion

After training and validation, to run the model on OKMX8MP, it must be converted into a .tflite format file. Click DEPLOY to enter the conversion interface. As shown in the figure below.

In the left dropdown menu, select the export type. This document exports in TensorFlow Lite format. For lightweight deployment, both input and output data types are set to int8. The parameters are set as shown below.

After setting the parameters, select EXPORT MODEL to export the .tflite model, which can then be deployed to OKMX8MP.

5. Model Prediction

Before performing predictions, the following files need to be prepared:

• mobilen_v3.tflite
• Handwritten digit image files for prediction
• Python script for loading the model and image preprocessing

The .tflite file can be exported after model validation. Handwritten digit images can be selected from the dataset or manually created, then converted into 28x28 black-background white-digit images. This document uses the following 30 images for prediction, named in the format ''group_number_label'' As shown below.

Group 1:

Group 2:

Group 3:

Write the Python script.

import numpy as np
from PIL import Image
import tflite_runtime.interpreter as tflite
# ---------------- Configuration ----------------
MODEL_PATH = "/home/root/mobilenet_v3.tflite"
IMAGE_PATHS = [
"/home/root/1_0.jpg",
''/home/root/1_1.jpg",
''/home/root/1_2.jpg",
''/home/root/1_3.jpg",
''/home/root/1_4.jpg",
''/home/root/1_5.jpg",
''/home/root/1_3.jpg",
"/home/root/1_7.jpg",
''/home/root/1_8.jpg",
''/home/root/1_9.jpg",
"/home/root/2_0.jpg",
''/home/root/2_1.jpg",
''/home/root/2_2.jpg",
''/home/root/2_3.jpg",
''/home/root/2_4.jpg",
''/home/root/2_5.jpg",
''/home/root/2_3.jpg",
"/home/root/2_7.jpg",
''/home/root/2_8.jpg",
''/home/root/2_9.jpg",
"/home/root/3_0.jpg",
''/home/root/3_1.jpg",
''/home/root/3_2.jpg",
''/home/root/3_3.jpg",
''/home/root/3_4.jpg",
''/home/root/3_5.jpg",
''/home/root/3_3.jpg",
"/home/root/3_7.jpg",
''/home/root/3_8.jpg",
''/home/root/3_9.jpg",
]
# ---------------- Load Model ----------------
interpreter = tflite.Interpreter(model_path=MODEL_PATH)
interpreter.allocate_tensors()
input_details = interpreter.get_input_details()
output_details = interpreter.get_output_details()
# Model input information
input_shape = input_details[0]['shape'] # [1, H, W, C]
height, width, channels = input_shape[1], input_shape[2], input_shape[3]
input_dtype = input_details[0]['dtype'] # np.float32 或 np.int8
# Quantization parameter (if it is int8)
scale, zero_point = input_details[0]['quantization']
# ---------------- Prediction ----------------
for img_path in IMAGE_PATHS:
# Open the image and convert it to RGB (3 channels)
img = Image.open(img_path).convert('RGB')
img = img.resize((width, height))
# Convert to numpy array
img_array = np.array(img, dtype=np.float32)
# If the training data is white background with black text, it can be reversed.
#img_array = 255 - img_array
# Normalize to 0~1
img_array = img_array / 255.0
# Adjust the shape to [1, H, W, 3]
img_array = img_array.reshape(1, height, width, channels)
# If the model is quantized to int8, then convert
if input_dtype == np.int8:
img_array = img_array / scale + zero_point
img_array = np.round(img_array).astype(np.int8)
# Set input
interpreter.set_tensor(input_details[0]['index'], img_array)
# Inference
interpreter.invoke()
# Get output
output_data = interpreter.get_tensor(output_details[0]['index'])
predicted_label = np.argmax(output_data)
print(f"Image {img_path} prediction results: {predicted_label}")

Copy all three files into OKMX8MP, as shown below.

Enter the following command to run the prediction:

python3 demo.py

The output is as follows:

Based on the output results, it can be observed that the image 3_9.jpg has a true label of 9, but the model predicts it as 7. All other images are predicted correctly. The image 3_9.jpg is shown below:

From the prediction results, it can be concluded that the trained model achieves high accuracy and maintains good performance when deployed on OKMX8MP

In embedded systems and Linux development, boot time is a critical performance metric, especially when devices need to respond and operate quickly. The boot time directly impacts user experience and the market competitiveness of the device. Below are methods to reduce boot time on the Linux 5.10.198-based T536 platform:

Before:

Platform: T536, system: Linux 5.10.198, the original boot time is 14.50 seconds.

Specific Modification Methods:

1. Adjust Log Level

During system booting, a large amount of debug information is output by default. While this information is helpful for debugging, it prolongs the boot time. By setting the log level to 0, most unnecessary log outputs can be disabled, thereby speeding up the boot process.

2. Disable U-Boot Menu Wait

By default, U-Boot waits for user input to select the boot menu. By setting bootdelay to 0, this waiting time can be eliminated, allowing the system to boot directly.

diff --git a/device/config/chips/t536/configs/OKT536-C/buildroot/env.cfg b/device/config/chips/t536/configs/OKT536-C/buildroot/env.cfg
index fa2b7d37..db902cc4 100755
--- a/device/config/chips/t536/configs/OKT536-C/buildroot/env.cfg
+++ b/device/config/chips/t536/configs/OKT536-C/buildroot/env.cfg
@@ -8,7 +8,7 @@ mmc_root=/dev/mmcblk0p4
 nor_root=/dev/mtdblock1
 init=/init
 rdinit=/rdinit
-loglevel=8
+loglevel=0
 coherent_pool=16K
 #reserve_list=30M@64M,78M@128M,200M@512M
 mac=
@@ -34,7 +34,7 @@ boot_recovery=sunxi_flash read 0x4007f800 recovery;bootm 0x4007f800
 boot_fastboot=fastboot
 #uboot system env config
-bootdelay=1
+bootdelay=0
 #default bootcmd, will change at runtime according to key press
 #default nand boot
 #bootcmd=run setargs_nand boot_normal
diff --git a/device/config/chips/t536/configs/OKT536-C/sys_config.fex b/device/config/chips/t536/configs/OKT536-C/sys_config.fex
index 892bdaf7..c8e36d5c 100644
--- a/device/config/chips/t536/configs/OKT536-C/sys_config.fex
+++ b/device/config/chips/t536/configs/OKT536-C/sys_config.fex
@@ -4,7 +4,7 @@
 ; Description of GPIO format: Port: [Port number] + [Sequence number within the group]
 ;-----------------------------------------------------------------------------------------
 [platform]
-debug_mode = 1
+debug_mode = 0
 ;----------------------------------------------------------------------------------
 ;[target] system bootup configuration

3. Kernel Fast Boot Optimization

Adjustments were made to the configuration of kernel boot parameters, with modifications implemented in the random.c file. Optimizing RNG initialization logic decreases boot wait time without sacrificing security. Modifications:

diff --git a/linux-5.10-origin/drivers/char/random.c b/linux-5.10-origin/d
rivers/char/random.c
index b54481e66..df2b49008 100644
--- a/linux-5.10-origin/drivers/char/random.c
+++ b/linux-5.10-origin/drivers/char/random.c
@@ -79,7 +79,8 @@ static enum {
 CRNG_EARLY = 1, /* At least POOL_EARLY_BITS collected */
 CRNG_READY = 2 /* Fully initialized with POOL_READY_BITS collecte
d */
 } crng_init __read_mostly = CRNG_EMPTY;
-#define crng_ready() (likely(crng_init >= CRNG_READY))
+//#define crng_ready() (likely(crng_init >= CRNG_READY))
+#define crng_ready() (likely(crng_init > 0))
 /* Various types of waiters for crng_init->CRNG_READY transition. */
 static DECLARE_WAIT_QUEUE_HEAD(crng_init_wait);
 static struct fasync_struct *fasync;

4. System Service Boot Sequence Adjustment

Adjusting the service startup sequence can prevent non-critical services from delaying boot. The optimized system boot process enables more efficient initialization of critical services while minimizing the waiting time for non-critical ones. By this method, the boot time can be further reduced.

Effect After Modification

Optimizations in kernel configuration, boot parameters, log levels, and U-Boot settings reduced the T536 platform's boot time from 14.50 seconds to 7 seconds, improving both boot efficiency and user experience. Such improvements not only enhance the boot efficiency of the device but also significantly improve the user experience.

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

FET62xx-C SoM

FET62xx-C SoM is powered by TI Sitara Cortex-A53 features AM62 series processors with running speeds up to 1.4GHz
and various peripheral interfaces such as Ethernet with TSN, USB2.0, LVDS, RGB parallel, UART, OSPI, CAN-FD, camera, audio, etc.
FET62xx-C is compatible with single core AM6231, dual-core AM6232 and quad-core AM6254 pin2pin, providing maximum scalability to users.

TI AM62x: Your Next-Generation HMI Solution

AM62x is a new generation of MPU family which is more scalable and extensive than AM335x,
it's designed to address the requirements and goals of Industry 4.0 for factories of the future.

Heterogeneous Multi-core, More security

AM62x is a hybrid processor family integrated with Cortex-A53 core and Cortex-M4F core;
Cortex-M4F with dedicated device level interconnect for security.

CAN-FD Empowers Industrial Automation and Vehicle Applications

AM62x supports 3 CAN-FD up to 5Mbps connecting to industrial networking stably,
providing functional reinforcements for industrial automation and vehicle applications.

GPMC for Parallel Host Interface to An External ASIC/FPGA

AM62x is enabled with GPMC with read/ write rating up to 100MB/s; Besides,
multiple chip-selection provides maximum flexibility for multi-communicating with external peripherals.

Exclusive Triple-display Output

FET62xx-C SoM support two display controllers with different output. Exclusively, it is capable of simultaneously driving three displays.

Target Applications

The SoM could be widely used in Human Machine Interfaces (HMI), Industrial computer,
Edge computing, Retail automation, Driver Monitoring System (DMS/OMS) / In-Cabin Monitoring (ICM),Telematics Control Unit (TCU),
Vehicle to Infrastructure / Vehicle to Vehicle (V2X / V2V),3D Re-configurable automotive instrument cluster, Appliance user interface and connectivity, Medical equipment.

▊ Product Video

Video Demo of AM62x Development board/Kit

Rockchip RK3572 System on Module - 8-Core AIoT Platform with 4 TOPS NPU

FET3572-C SoM

Rockchip RK3572, an AIoT SoC that balances high performance, low power consumption, and full-stack AI capability.

Rockchip Strategic Partnership
Delivering Enterprise-Grade AIoT Solutions

As a strategic partner of Rockchip, Forlinx Embedded has won multiple awards, including the Rockchip 2024 Outstanding Cooperation Award and 2025 Best Contribution Award.
Over the years, it has developed a series of mature embedded SoMs based on processors like RV1126B, RK3576, RK3562, RK3506, RK3588 , RK3568, and RK3399.
Building on this collaboration, Forlinx Embedded now introduces the FET3572‑C SoM, marking a new phase in its partnership with Rockchip.
Facing the opportunities of the mobile intelligence era, we will continue to work together to deliver superior products and services, creating greater value for customers and the industry.

Octa‑Core High‑Performance Ultra‑HD Decoding AI Chip

RK3572 is an octa-core SoC based on 8nm technology launched by Rockchip in 2026. With a 4 TOPS NPU, 8K decoding, industrial-grade interfaces and low power consumption, it fills the mid‑range performance gap between RK3568 and RK3576, offering a cost-effective solution for AIoT and edge computing.

Rich Display Capabilities

RK3572 supports versatile display interfaces including HDMI, eDP, RGB, EBC, and MIPI DSI, enabling dual-screen setups such as 4K@60 Hz + 2K@60 Hz. HDMI and eDP support up to 4K@60 Hz, RGB supports 1920×1080@60 Hz, and EBC resolution reaches 1872×1404.

4TOPS NPU Empowering AI Capabilities

Equipped with an in-house 4 TOPS NPU that supports mixed precision (INT4/INT8/INT16/FP4/FP8/FP16/BF16) and W4A16 asymmetric MAC operations. It is compatible with mainstream AI frameworks (TensorFlow, Caffe, TFLite, PyTorch, ONNX, Android NN, MXNet) and backed by the user-friendly RKNN toolchain.

DSMC Parallel Bus
Seamless FPGA Integration

Supports 16‑bit/32‑bit bus widths, delivering high data throughput and read/write rates. It enables stable, high-speed communication between ARM and FPGA, simplifies hardware/software integration, and meets demanding embedded applications requiring large data transfers and low-latency real-time exchange.

Ultra-Low Power Consumption
Down to 1.3W

Based on an 8 nm process and smart big-little core scheduling, RK3572 doubles the performance of the previous-generation mid-range platform.With dynamic voltage scaling, its idle power consumption can drop to as low as 1.3W under no-load conditions. Typical-scenario power consumption is reduced by over 50%, making the SoC well-suited for fan-less designs and battery-powered devices.

Enhanced System Security

RK3572 features a built-in TEE that isolates secure computing resources, along with a hardware encryption engine supporting mainstream cryptographic algorithms. A complete secure boot mechanism validates firmware integrity, preventing tampering and unauthorized flashing to protect device operation and user data.

ISP Improves Image Quality

The RK3572 integrates a professional 12 MP ISP supporting up to 4096×3072 HD imaging. Enhanced by hardware-software synergy, it drives advanced computational photography—including AI-HDR, intelligent noise reduction, and super-resolution—delivering next-level audiovisual performance for premium AIoT smart devices.

Continuously Updated User Resources

Broad Industry Applications

It is versatile, suitable for industrial control , power & new energy, AIoT, medical, and other sectors.
With high performance, extensive interfaces, industrial-grade reliability, competitive pricing, and full after-sales support, it accelerates product time-to-market.

SoM Mechanical Dimensions

RK3572 SoM&SBC Video

First to Market: Forlinx Launches FET3572-C SoM Powered by Rockchip RK3572

FET-MX9352-C i.MX93 System on Module based on NXP i.MX9352 with Dual Cortex-A55 & Ethos-U65 NPU

FET-MX9352-C SoM

Cortex-A55+ Cortex-M33 for Multi Tasks Processing with Low Latency

The i.MX9352 hybrid processor integrates dual Cortex-A55 cores up to 1.7 GHz and a Cortex-M33 real-time core, combining host and slave control in a single compact SoC for multi-task processing and cost-effective system design. High-speed on-chip bus communication between the A-core and M-core ensures efficient and reliable real-time data exchange.

0.5 TOPS NPU: Empowering Low Cost and Light AI Applications

i.MX9352 processor contains an innovative ARM Ethos U-65 microNPU, each cycle with 256 MAC, 0.5 TOPS can meet the demand for high efficient, fast and safe machine learning at edge side.

TSN and CAN-FD: Meeting Digitizing Demands for Industries and Automotive

FET-MX9352-C supports two Gigabit Ethernet ports with one enabled with TSN, in addition to ensuring clock accuracy, it will promote communication between IT and OT, helping to build network with low latency.

Industrial Grade Materials: Fit for Harsh Environments

All materials including capacitor, resistor and connector on FET-MX9352-C system on module are industrial grade, can support the SoM to work in -40℃~+85℃ operating environment very well.

Various Peripheral Interfaces with High Scalability

Long-Term Availability

i.MX 93 family processors was launched in 2023 and is scheduled with long-term supply, the availability will be at least 15 years.

i.MX 9352 SoM & SBC Video

i.MX 93 Demo | FET-MX9352-C SoM & OK-MX9352-S SBC

FET1126Bx-S (Rockchip RV1126B/RV1126BJ) Industrial System on Module / Computer on Module

Functional Diagram

Full Upgrade

Compared to the RV1126, it offers three major enhancements: boosted CPU and NPU performance, plus an upgraded OS. Enjoy a more powerful, intelligent, and seamless device AI journey.

Comprehensive Pinout & Rich Connectivity

Stamp hole + LGA connection. All functional pins of the RV1126B/RV1126BJ are fully led out, including display interfaces (MIPI-DSI, RGB LCD),
network interfaces (Gigabit RGMII, 100Mbps Ethernet), and various peripherals (CAN FD, UART, SPI, I2C, PWM, ADC, etc.).
The GPIO layout is fully compatible with the Raspberry Pi 40-pin standard.

3TOPS NPU Empowers Edge AI Inference

Independent built - in NPU , providing up to 3TOPS@INT8 AI computing power, supporting INT8/INT16 mixed - precision operations,
and can efficiently run typical edge AI target recognition models such as face detection, safety helmet recognition, fire and smoke alarm,
and area intrusion, realizing local real - time decision - making without relying on the cloud.

Powerful Vision & Multi-channel Video Analytics

-40°C to +85°C Stable 24/7 Operation

The FET1126BJ - S SoM supports - 40°C~+85°C operation, delivering excellent reliability and environmental adaptability in complex settings.

LPDDR4 Memory Design for More Scenarios

An LPDDR4 memory design for lower power consumption. DDR4 commercial-grade chips operate at 0°C - 70°C, while LPDDR4 ones cover - 20°C - 85°C.
With RV1126B (- 20°C - 85°C) and eMMC (- 25°C - 85°C)'s wide-temperature features, the commercial-grade SoM works at - 20°C - 85°C, offering low cost and wide-temperature performance.
It combines low cost with wide-temperature characteristics.

Full Software Ecosystem & Rapid AI Deployment

Equipped with the Linux 6.1 OS, it's a major upgrade from the previous - generation RV1126. It offers full BSP support, including kernel source code, file system, drivers, and the RKNN toolchain. It's also compatible with model conversion of mainstream deep - learning frameworks like TensorFlow, PyTorch, Caffe, and MXNet.

RPi 40-Pin GPIO Compatible for Quick Start

The compact development board features 2 x network ports, display, USB and Wi-Fi interfaces, plus pins matching Raspberry Pi 40-Pin GPIO for testing FET1126B-S/FET1126BJ-S SoM functions and AI development.

Compact Development Board with Complete Interfaces

Compact size, measuring only 120mm×75mm, offers interfaces like network ports, 2 x MIPI - CSI, 1 x MIPI - DSI, and 40Pin GPIO (with UART, SPI, IIC).
It can flexibly expand peripherals and sensors, ideal for embedded vision, edge computing, AIoT, and AI inference.

The Choice for High - End Applications

RV1126B/RV1126BJ SoM&SBC Video

All New FET1126BJ-S SoM: Cost-Effective Edge AI Solution

i.MX6Q Core Board With Ultra-thin Connectors

The core board uses 4 sets of ultra-thin 80P board-to-board connectors,
which are only 2mm high and 40mm x 70mm gold size ratio, so that the product design is not limited to any mechanical structure

12-layer PCB Gold Deposition Process

i.MX6Q core board adopts the 12-layer PCB deposition process design,
taking full account of electromagnetic compatibility and signal integrity design, to ensure the stable operation of the system!

The CPU pins are all drawn out to meet the different functional requirements of different products in various fields

i.MX6Q core board leads all pins out of the CPU, supporting gigabit Ethernet, DVP, MIPI camera s, audio, SDHC, and more.
It also supports MIPI cameras, MIPI screens, MLB buses, EIM BUS 27-bit addresses, 32-bit data buses, and more.

Supports a variety of display screen interfaces and image collectors

FETMX6Q-C SoM Supports Dual-screen Synchronous Display, Dual-screen Asynchronous Display

Forlinx embedded i.MX6Q core board supports dual-screen synchronous display, dual-screen asynchronous display.
Asynchronous display supports LVDS and LCD, HDMI and LVDS, HDMI and LCD, LVDS0 and LVDS1.

CE FCC RoHS certified

▊ OKMX6Q-C Development Board

FETMX6Q-C supporting carrier board OKMX6Q-C is rich in interface resources, including mainstream interfaces such as Gigabit Ethernet, CAN-bus, camera, WIFI & Bluetooth, and also introduces CPU-specific functions such as MIPI, MLB, and EIM BUS. The module is ready to run Linux, Android and can support industrial operating temperature range from -40 to +85 Celsius.

Forlinx kindly provides related optional modules for OKMX6Q single board computer/ development kit testing, such as 4.3 inch Resistive LCD Module, 7.0-inch LCD Module with MIPI display, 7.0-inch TFC LCD Module with Capacitive Touch Panel, 7.0-inch TFT LCD Module with Resistive Touch Panel, 10.1-inch LVDS Display with Capacitive Touch Panel, etc.

For More Information

Rockchip RK3572 Single Board Computer

OK3572-C SBC

Rockchip RK3572, an AIoT SoC that balances high performance, low power consumption, and full-stack AI capability.

Rockchip Strategic Partnership
Delivering Enterprise-Grade AIoT Solutions

As a strategic partner of Rockchip, Forlinx Embedded has won multiple awards, including the Rockchip 2024 Outstanding Cooperation Award and 2025 Best Contribution Award.
Over the years, it has developed a series of mature embedded SoMs based on processors like RV1126B, RK3576, RK3562, RK3506, RK3588 , RK3568, and RK3399.
Building on this collaboration, Forlinx Embedded now introduces the FET3572‑C SoM, marking a new phase in its partnership with Rockchip.
Facing the opportunities of the mobile intelligence era, we will continue to work together to deliver superior products and services, creating greater value for customers and the industry.

Octa‑Core High‑Performance Ultra‑HD Decoding AI Chip

RK3572 is an octa-core SoC based on 8nm technology launched by Rockchip in 2026. With a 4 TOPS NPU, 8K decoding, industrial-grade interfaces and low power consumption, it fills the mid‑range performance gap between RK3568 and RK3576, offering a cost-effective solution for AIoT and edge computing.

Rich Display Capabilities

RK3572 supports versatile display interfaces including HDMI, eDP, RGB, EBC, and MIPI DSI, enabling dual-screen setups such as 4K@60 Hz + 2K@60 Hz. HDMI and eDP support up to 4K@60 Hz, RGB supports 1920×1080@60 Hz, and EBC resolution reaches 1872×1404.

4TOPS NPU Empowering AI Capabilities

Equipped with an in-house 4 TOPS NPU that supports mixed precision (INT4/INT8/INT16/FP4/FP8/FP16/BF16) and W4A16 asymmetric MAC operations. It is compatible with mainstream AI frameworks (TensorFlow, Caffe, TFLite, PyTorch, ONNX, Android NN, MXNet) and backed by the user-friendly RKNN toolchain.

DSMC Parallel Bus
Seamless FPGA Integration

Supports 16‑bit/32‑bit bus widths, delivering high data throughput and read/write rates. It enables stable, high-speed communication between ARM and FPGA, simplifies hardware/software integration, and meets demanding embedded applications requiring large data transfers and low-latency real-time exchange.

Ultra-Low Power Consumption
Down to 1.3W

Based on an 8 nm process and smart big-little core scheduling, RK3572 doubles the performance of the previous-generation mid-range platform.With dynamic voltage scaling, its idle power consumption can drop to as low as 1.3W under no-load conditions. Typical-scenario power consumption is reduced by over 50%, making the SoC well-suited for fan-less designs and battery-powered devices.

Enhanced System Security

RK3572 features a built-in TEE that isolates secure computing resources, along with a hardware encryption engine supporting mainstream cryptographic algorithms. A complete secure boot mechanism validates firmware integrity, preventing tampering and unauthorized flashing to protect device operation and user data.

ISP Improves Image Quality

The RK3572 integrates a professional 12 MP ISP supporting up to 4096×3072 HD imaging. Enhanced by hardware-software synergy, it drives advanced computational photography—including AI-HDR, intelligent noise reduction, and super-resolution—delivering next-level audiovisual performance for premium AIoT smart devices.

Continuously Updated User Resources

Broad Industry Applications

It is versatile, suitable for industrial control , power & new energy, AIoT, medical, and other sectors.
With high performance, extensive interfaces, industrial-grade reliability, competitive pricing, and full after-sales support, it accelerates product time-to-market.

SoM Mechanical Dimensions

RK3572 SoM&SBC Video

First to Market: Forlinx Launches FET3572-C SoM Powered by Rockchip RK3572

Forlinx OK3588-C Rockchip RK3588 SBC | 8K Video & Quad-Screen Single Board Computer

OK3588-C SBC

Rich Ready-to-use Peripheral Source

8K Encoder/ Decoders Exploring

RK3588 supports 8K display output and high-performance decoding (H.265/VP9 @ 8K60, H.264 @ 8K30, AV1 @ 4K60). It is fully compatible with OpenGLES 1.1/2.0/3.2, OpenCL 2.2, and Vulkan 1.2, making it ideal for massive video playback. A dedicated 2D engine with MMU ensures maximized display performance and 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.

Multiplied Isolation Circuits: Trusting the Board as a Secure Platform

User-Friendly Reference Files and Efficient After-Sale Technical Support

RK3588 SoM&SBC Video

FCU1501 Industrial Embedded Control Unit

Vertically Integrated Architecture for Long-Term Supply Stability

Two Interfaces, Same Dimensions

It features dual interface configurations within the same form factor, allowing flexible selection for different applications—no installation changes required.
With highly integrated and rich interfaces, a single unit can replace multiple traditional gateways, significantly improving deployment efficiency and system integration.

Industrial Wide-Temp & Level-3 EMC

It is tested for industrial environments from -40°C to +85°C and designed to meet Level 3 EMC standards, ensuring reliable operation in extreme temperatures and strong electromagnetic interference.
It meets the stringent requirements of industries such as power, rail transit, and smart manufacturing for high reliability and environmental adaptability.

Robust Software Ecosystem with Linux 6.1 and Industrial Protocol Support

Powered by Linux 6.1, it integrates mainstream protocols and middleware such as Modbus, TCP/IP, SSH, OpenVPN, Nginx, and reverse proxy.
This enhances system security and compatibility while flexibly supporting industrial communication, remote maintenance, and edge service applications.

Web-Based Visual Management for Effortless O&M

Access the configuration interface directly through a web browser to intuitively manage network settings, communication parameters, and system status.
No additional software or specialized tools are required, significantly reducing maintenance complexity and enabling more efficient, streamlined device management.

Rich Features, True Plug-and-Play Efficiency

Integrated practical features: one-click parameter reset, 4G status indicators, versatile interfaces, power output, and USB firmware upgrade.
No extra accessories needed—enabling rapid deployment, easy maintenance, and higher on-site efficiency.

Flexible Mounting for Any Scenario

Multiple installation methods -- DIN rail mounting, wall mounting, and front-facing bracket mounting—ensuring easy deployment across diverse industrial environments.

Comprehensive Certifications for Reliable Use

CE, FCC, and RoHS certified, with environmental testing to ensure safety, quality, and global compliance.

Application Scenarios

Widely used in power automation, energy storage (EMS), renewable energy, structural monitoring, energy management, residential HEMS, and industrial data acquisition.

FCU1501 Interface Overview

It is an industrial-grade 4G IoT gateway designed for harsh environments (-40°C to +85°C), supporting DIN rail mounting for easy integration.
With dual Ethernet , multiple RS485 ports, and CAN bus, it enables flexible device connectivity and supports Modbus TCP/RTU protocol conversion and passthrough.
Built-in edge computing ensures efficient local processing and reliable remote data acquisition, making it ideal for industrial IoT, smart devices, remote maintenance, and energy applications.

FCU1501 Industrial Embedded Computer Video

FCU1501 Embedded PC: Industry-Grade Data Communication Gateway

OK1126Bx-S (Rockchip RV1126B/RV1126BJ) Edge AI Single Board Computer

Functional Diagram

Full Upgrade

Compared to the RV1126, it offers three major enhancements: boosted CPU and NPU performance, plus an upgraded OS. Enjoy a more powerful, intelligent, and seamless device AI journey.

Comprehensive Pinout & Rich Connectivity

Stamp hole + LGA connection. All functional pins of the RV1126B/RV1126BJ are fully led out, including display interfaces (MIPI-DSI, RGB LCD),
network interfaces (Gigabit RGMII, 100Mbps Ethernet), and various peripherals (CAN FD, UART, SPI, I2C, PWM, ADC, etc.).
The GPIO layout is fully compatible with the Raspberry Pi 40-pin standard.

3TOPS NPU Empowers Edge AI Inference

Independent built - in NPU , providing up to 3TOPS@INT8 AI computing power, supporting INT8/INT16 mixed - precision operations,
and can efficiently run typical edge AI target recognition models such as face detection, safety helmet recognition, fire and smoke alarm,
and area intrusion, realizing local real - time decision - making without relying on the cloud.

Powerful Vision & Multi-channel Video Analytics

-40°C to +85°C Stable 24/7 Operation

The FET1126BJ - S SoM supports - 40°C~+85°C operation, delivering excellent reliability and environmental adaptability in complex settings.

LPDDR4 Memory Design for More Scenarios

An LPDDR4 memory design for lower power consumption. DDR4 commercial-grade chips operate at 0°C - 70°C, while LPDDR4 ones cover - 20°C - 85°C.
With RV1126B (- 20°C - 85°C) and eMMC (- 25°C - 85°C)'s wide-temperature features, the commercial-grade SoM works at - 20°C - 85°C, offering low cost and wide-temperature performance.
It combines low cost with wide-temperature characteristics.

Full Software Ecosystem & Rapid AI Deployment

Equipped with the Linux 6.1 OS, it's a major upgrade from the previous - generation RV1126. It offers full BSP support, including kernel source code, file system, drivers, and the RKNN toolchain. It's also compatible with model conversion of mainstream deep - learning frameworks like TensorFlow, PyTorch, Caffe, and MXNet.

RPi 40-Pin GPIO Compatible for Quick Start

The compact development board features 2 x network ports, display, USB and Wi-Fi interfaces, plus pins matching Raspberry Pi 40-Pin GPIO for testing FET1126B-S/FET1126BJ-S SoM functions and AI development.

Compact Development Board with Complete Interfaces

Compact size, measuring only 120mm×75mm, offers interfaces like network ports, 2 x MIPI - CSI, 1 x MIPI - DSI, and 40Pin GPIO (with UART, SPI, IIC).
It can flexibly expand peripherals and sensors, ideal for embedded vision, edge computing, AIoT, and AI inference.

The Choice for High - End Applications

RV1126B/RV1126BJ SoM&SBC Video

All New FET1126BJ-S SoM: Cost-Effective Edge AI Solution

FAI-ARA240-M Edge AI Accelerator