INTRODUCTION

During the development of a Linux-based video system, the need arose to integrate and support multiple types of GMSL2 (Gigabit Multimedia Serial Link) cameras.

Note:

The solution described here was developed and tested on the i.MX8QM platform (a high-performance application processor from NXP, widely used in embedded and automotive systems). However, the methodology is universal and can be applied to other hardware platforms that support dynamic Device Tree modification via Device Tree Overlays.

About GMSL2:

GMSL2 is a high-bandwidth serial protocol for transmitting video, audio, and control data between cameras and processors over long distances with minimal latency and high reliability. It is widely used in automotive and industrial systems for its ability to deliver high-quality video over a single cable.

The default camera model in this system is the Leopard Imaging LI-AR0233-NVP2650-GMSL2, which features a 2.6MP AR0233AT CMOS image sensor (2048×1280 active pixels), HDR and LFM support, RAW data output, a 30° horizontal field of view, 1/2.5″ optical format, 3.0 μm pixel size, and integrated GMSL2 serializer.

However, different use cases demand cameras with different resolutions, frame rates, sensor technologies, or optical characteristics. While some require high dynamic range for challenging lighting conditions, others prioritize low latency or specific field-of-view optics. To address these diverse needs, a user-space application in C was developed. This solution allows users to easily add and configure various camera modules, making the system highly flexible and extensible.

TECHNICAL CHALLENGES

Integrating multiple camera types introduced several key challenges:

• Lack of native Linux drivers
  Some camera models lacked Linux drivers, requiring adaptation of drivers from other hardware platforms.
• Runtime configuration support
  The system needed to configure different camera types within a single running instance, without system downtime.
• Camera replacement at runtime
  It was necessary to replace or reconfigure camera types while the system was running, eliminating the need to rebuild or re-flash the system image.

The solution therefore needed a flexible runtime framework that could accommodate different camera models without interrupting operations or requiring image updates—ensuring faster adaptation to new hardware and simplifying long-term through-lifecycle system maintenance.

PROPOSED SOLUTION – DYNAMIC DEVICE TREE MANAGEMENT

The solution leverages dynamic Device Tree modification using Device Tree Overlays, enabling the addition or reconfiguration of cameras at runtime without rebooting or re-flashing. When a new camera is connected, the overlay applies to the running system, dynamically updating the Device Tree to immediately register the new hardware.

A dedicated user-space application was developed to provide a simple interface for selecting or specifying the camera type. Once requested, the application invokes a function that takes the camera type as input and applies the corresponding Device Tree Overlay, completing the device registration on-the-fly.

Ensuring seamless integration of new camera modules makes the platform flexible and adaptable to diverse hardware configurations.

IMPLEMENTATION

C-based user-space application exposes a modular, extensible API for camera management. Users and higher-level software can initialize, configure, and de-initialize cameras at runtime without rebooting or updating firmware.

The system uses Device Tree Overlay templates defining parameters for different camera configurations (number of ports, camera types, etc.). When a camera is selected, the application fills in the template with specifics—such as I2C addresses, compatible strings, and stream formats—before applying it.

Example Device Tree Overlay snippet (placeholders SERIALIZER_ADDR, SENSOR_COMPATIBLE_STRING, etc. replaced at runtime):

/* Example: Generic Device Tree Overlay for a Camera Port */

camera_serializer: serializer@SERIALIZER_ADDR {
    compatible = "SERIALIZER_COMPATIBLE_STRING";
    reg = <SERIALIZER_ADDR>;
    status = "okay";
    /* Additional serializer properties */
};

camera_sensor: sensor@SENSOR_ADDR {
    compatible = "SENSOR_COMPATIBLE_STRING";
    reg = <SENSOR_ADDR>;
    status = "okay";
    serializer = <&camera_serializer>;
    /* Camera-specific properties */
    port-config {
        src-csi-port = "SRC_PORT";
        dst-csi-port = "DST_PORT";
        num-lanes = <NUM_LANES>;
        streams = <STREAMS>;
        /* Additional stream or link properties */
    };
};

Once compiled and applied, the overlay registers the camera dynamically, making it immediately available.

DEVICE TREE OVERLAY WORKFLOW

The dynamic configuration process consists of three stages:

1. Initialization – Detect available hardware and prepare data structures.
2. Configuration – User or higher-level software selects the camera model per port.
3. Overlay Application – The system generates, compiles, and applies the overlay, updating the kernel Device Tree in real time.

This ensures new cameras become operational instantly, with all necessary kernel modules loaded—no reboot required.

Figure 1. Device Tree Overlay workflow

USER INTERACTION

The application is designed to be user-friendly and scriptable. Key functions can be invoked from the terminal (e.g., camera_init, camera_deinit, camera_prepare_port, camera_submit_configuration).

This enables easy integration into production scripts, automated test environments, or manual setup during deployment.

BENEFITS OF MODULAR ARCHITECTURE

This modular, runtime-driven architecture provides clear advantages:

• Rapid integration – Add new cameras without modifying firmware or rebuilding the system image.
• Runtime flexibility – Swap or reconfigure camera types during production or deployment without downtime.
• Scalability and maintainability – Simplifies updates, expansions, and long-term support.

SUMMARY

This solution combines Device Tree Overlays with a modular C-based API, enabling runtime configuration and seamless integration of various GMSL2 camera modules.

It provides:

• High flexibility for adapting to new hardware
• No downtime or firmware changes
• A scalable video system architecture suitable for automotive vision, industrial inspection, and customizable video pipelines

Future improvements could include hot-plug detection, automatic configuration, expanded support for USB/Ethernet cameras, and advanced monitoring/diagnostics, making the system even more versatile.