Integrating an External Arducam Camera with the Nitrogen95 SMARC SOM

 What You Start With

The Nitrogen95 SMARC Evaluation Kit (EVK) is a complete development platform. Everything is intended to work together out of the box. That matters because most camera issues happen at the boundaries between vendors.

Enabling the camera in software

For full specific step-by-step instructions, refer to the Quick Start Guide: Nitrogen95 SMARC Beta Evaluation Kit . The overview below is a condensed version focused on showing how straightforward camera integration is when using Ezurio and Arducam together.

Instead of modifying device trees manually, the required configuration is already provided as a device tree overlay.

From U-Boot, you just ensure the camera overlay is included:

setenv dtbos "imx95-nitrogen-smarc-dsi.dtbo imx95-nitrogen-smarc-nx611.dtbo imx95-nitrogen-smarc-csi0-pivariety.dtbo"
saveenv
reset

This enables the CSI camera interface with a known-good configuration. No kernel rebuild and no guesswork.

Verifying detection

Once the system boots, you can confirm the camera is detected through Linux and Boot2Qt Yocto successfully. Running dmesg | grep -E '.*arducam.*' should return something like:

[11.650954] arducam-pivariety 12-000c: sensor id: 0x0A56
[11.651249] arducam-pivariety 12-000c: firmware version: 0x0010

At this point:

• hardware connection is confirmed
• driver is loaded
• the camera pipeline is present

You’re ready to move on.

Running the camera

By default, the system boots into the Boot2Qt demo environment, which uses the display stack. After the system has booted, stop Weston and terminate the QTLauncher to enable camera output by executing the following via the debug UART interface or over SSH:

killall weston; killall qtlauncher

Once the display is released, you can capture images and take pictures using GStreamer with WaylandSink.

HD streaming (1280 x 720)

root@nitrogen95:~# gst-launch-1.0 libcamerasrc src::stream-role=still-capture ! 'video/x-raw,width=1280,height=720' ! waylandsink fullscreen=true

Capture an image

root@nitrogen95:~# gst-launch-1.0 libcamerasrc src::stream-role=still-capture ! 'video/x-raw,width=1280,height=720' ! identity sync=true ! jpegenc ! multifilesink location="hd.jpg"

The same approach works for higher resolutions like Full HD and 4K. The key point: you’re starting from a working pipeline, not building one from scratch.

Why the Arducam xISP module helps on Nitrogen95

On most embedded platforms, camera integration breaks down around the ISP and image pipeline, not the sensor itself. Typical problems include ISP support being incomplete and hard to access, image tuning, inconsistent output quality, and spending time debugging pipelines instead of building your application. The Arducam xISP module avoids a lot of that.

It includes an external ISP that is already tuned for the sensor so image processing is handled on the camera module and there is no need to tune the ISP to get a stable image. On the Nitrogen95, it shows up as a clean detection and able to work with the libcamera / GStreamer pipeline immediately. 

Where the partner ecosystem makes a difference

Most of the time savings don’t come from one big feature, they come from a lot of small things already being handled. On many platforms, camera bring-up starts with hardware issues. You end up checking CSI lane configuration, verifying power sequencing, or troubleshooting connector mismatches. It’s not complicated work, but it adds up quickly. With the Nitrogen95 and Arducam setup, that layer is already sorted. The camera and carrier are designed to work together, so you can skip that step.

Device tree support is usually the next hurdle. Without it, you’re editing DTS files, configuring endpoints and clocks, rebuilding, and testing repeatedly just to get the camera detected. In this case, the required overlay is already provided and validated.

Driver compatibility is another pain point. Camera drivers depend on the kernel version, BSP, and media framework. When something doesn’t work, it’s not always clear if the issue is hardware, software, or configuration. Here, that combination has already been validated. The driver loads, the sensor is recognized, and the pipeline works.

You also start from a working pipeline. Instead of building a GStreamer or libcamera pipeline from scratch, you have examples that already run. That avoids common issues like incorrect formats, wrong device nodes, or broken pipelines. You can start with something and modify it as needed.

All of this means you get to application work faster. On less integrated setups, it’s normal to spend days just getting a stable image, and longer to get acceptable quality. With this setup, the camera connects and streams quickly, so you can move on to actual development.

That’s the difference compared to other competitor approaches, where hardware, BSP, and camera modules come from different sources. In those cases, integration becomes part of your workload. Here, most of that work has already been done.

Bottom Line

The value isn’t just that the camera works with the Nitrogen95. It’s that the hardware interfaces are already validated, the BSP already includes camera support, and the image pipeline products actual, usable output. Instead of spending time getting the camera setup, you can focus on building your application. 

To learn more about the Ezurio validated Arducam cameras, visit: https://www.ezurio.com/partners/technology/arducam

To learn more and order samples of Ezurio's Nitrogen95 SMARC EVK (Evaluation Kit), visit: https://www.ezurio.com/product/nitrogen95-i-mx95-evaluation-kit