• OK1046A-C Development Board VLAN Configuration Guide

    04/13/2026 at 02:22 0 comments

    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

    OK1046A-C Development Board 1 VLAN interface status and network configuration details

    VLAN configuration for Development Board 2

    OK1046A-C Development Board 2 initial network configuration check

    OK1046A-C Development Board 2 VLAN interface address assignment

    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.

    Successful ping response between Board 1 and Board 2 using VLAN 100

    Bi-directional ping verification showing successful connectivity on VLAN 100

    3. Different VLAN ID Test

    Failed ping attempt from Board 1 due to mismatched VLAN ID

    Failed ping attempt from Board 2 confirming isolation between different VLAN IDs

    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.

    Tcpdump packet capture showing 802.1Q tagging and VLAN ID 100 in the Ethernet header

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

    Read more »

  • Edge AI Selection Guide: Assess the Technical Advantages of the FET1126BJ-S SoM in 3 Minutes

    03/27/2026 at 07:35 0 comments

    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.

    Forlinx Embedded FET1126BJ-S SoM product appearance and core positioning

    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.

    Four core technical pillars of FET1126BJ-S including performance, ecosystem, vision, and reliability

    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.

    Detailed hardware architecture and technical parameters of the RV1126BJ-based SoM

    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.

    Visual representation of FET1126BJ-S applications in security, industry, and smart campuses

    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...
    Read more »

  • How to Enable Core Dump for Debugging on RK3568 with Buildroot (Linux 5.10 Kernel)

    03/09/2026 at 05:54 0 comments

    1. Overview

    In embedded Linux product development, debugging, and delivery, crashes like segmentation faults and stack overflows are common. Serial logs alone often cannot pinpoint the exact failure scenario.

    Core Dump is a crucial debugging mechanism provided by the Linux operating system: when a process terminates abnormally, the system saves the key runtime state of the process at the moment of the crash (including memory image, registers, call stack, etc.) into a file. Developers can use debugging tools like gdb to perform offline analysis on this file, enabling them to quickly identify the root cause of the issue.

    This article uses the OK3568 platform (Linux Kernel 5.10 + Buildroot) as an example to provide a detailed explanation of how to enable Core Dump functionality and offers practical debugging methods, applicable to scenarios such as application development, system integration, and customer issue analysis.

    2. Core Dump Concepts

    Core Dump may be triggered when an application exits abnormally due to the following situations:

    • Accessing illegal memory (Segmentation Fault)
    • Null pointer or wild pointer access
    • Stack overflow
    • Illegal Instruction
    • Program actively calling abort()

    The generated core file is essentially a snapshot of the process’s address space at the moment of the crash, mainly including:

    • The virtual memory content of the process (code segment, data segment, heap, stack)
    • CPU register states
    • Thread information
    • Signal information (the type of signal that caused the crash)

    With the core file, issues can be reproduced without the target board, significantly improving the efficiency of problem analysis.

    3. OK3568 Buildroot System Default Operation Description

    In the default Buildroot system for OK3568 (Linux kernel 5.10), core dump is disabled.

    Core Dump default function is disabled.

    When an application crashes, no core file is generated automatically.

    To enable in-depth debugging or scenario reproduction, please manually enable this function.

    4. Steps to Enable Core Dump

    On the 3568 Linux 5.10 board, core dump is disabled by default.

    Checking the default core dump status on RK3568 board

    To enable it on the board:

    4.1 Create a core dump directory

    It is recommended to save the core file under a persistent partition that the user can read and write, such as /userdata

    mkdir -p /userdata/core

    Creating a directory for core dump files on RK3568

    4.2 Set directory permissions

    Allow any process to write to it during debugging:

    chmod 777 /userdata/core

    Setting 777 permissions for the core dump directory

    Note: For production systems, restrict permissions according to security policy. 777 is not recommended for long-term use.

    4.3 Set core file directory

    Configure the kernel to save cores with a descriptive name in the directory:

    echo "/userdata/core/core.%e.%p" > /proc/sys/kernel/core_pattern

    Parameter description:

    %e:executable name

    %p:process PID

    Example generated file:

    core.myapp.1234

    4.4 Allow core dump generation

    Lift the core dump size limit for the current shell:

    ulimit -c unlimited

    Note: This setting is session‑specific. To apply permanently, add the command to your startup script.

    4.5 Verify if core dump is enabled

    After enabling, use the ulimit -c command to check whether the dump feature is active.

    If the output is 0, it indicates that the dump function is disabled.

    If the output is unlimited, it indicates that the dump function is enabled.

    Verifying ulimit settings to confirm core dump is enabled

    5. Verify core dump generation

    After completing the setup above, run your target application.

    When the program crashes (e.g., due to a segmentation fault), a core file will be generated in the configured directory (/userdata/core/) with the following naming pattern:

    core.<program_name>.<process_pid>

    6. Debug with GDB

    6.1 Basic debug command

    Use a matching GDB (typically...

    Read more »