-
OK1046A-C Development Board VLAN Configuration Guide
04/13/2026 at 02:22 • 0 commentsI. 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...
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 commentsIn 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...
-
How to Enable Core Dump for Debugging on RK3568 with Buildroot (Linux 5.10 Kernel)
03/09/2026 at 05:54 • 0 commentsRead more »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.
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
4.2 Set directory permissions
Allow any process to write to it during debugging:
chmod 777 /userdata/core
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.
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...

Lutetium
Rui Santos
Thane Hunt
Max.K
Michiel Spithoven
Radu Motisan
Stephane
dev-lab
CNLohr
1BarConnection
Xylitol
Alex M Sunny
STEAL-THIS-HARDWARE
Makerfabs
Adrian Prinz