Bringing Up an AR0521 Camera on the Digi ConnectCore 6
Overview
One of the first challenges I faced at MAB Labs was bringing up a camera sensor that had no upstream Linux driver. My client's product was built around a Digi ConnectCore 6 (CC6) system-on-module, and the design required image capture from an ON Semiconductor AR0521 — a 5MP rolling-shutter CMOS sensor with a MIPI CSI-2 interface. At the time, there was no mainlined Linux driver for this sensor.
The Starting Point
Digi's BSP for the CC6 ships with support for the OmniVision OV5640 MIPI camera sensor out of the box. The kernel configuration (CONFIG_MXC_CAMERA_OV5640_MIPI) is enabled by default, and the MIPI CSI-2 host controller on the i.MX6 is well-documented. So the V4L2 capture pipeline and MIPI D-PHY layer were already in place — my task was integrating a new, unsupported sensor.
The AR0521 driver had been in development on the linux-media mailing list. It would eventually go through seven patch revisions before being merged into mainline, but at the time, all that existed were early patches. I took one of those patches as a starting point and built a basic driver. I placed it in a separate Yocto layer I had created for my client's work — not in meta-digi itself — to keep the vendor BSP clean and upgradeable.
The sensor initialized successfully. I2C communication was working, the AR0521 responded to register reads, and the V4L2 device node appeared.
Then I tried to capture an image. Nothing.
Getting Stuck
The MIPI CSI-2 link between the AR0521 and the i.MX6 appeared to be up. The driver wasn't throwing errors. But frames weren't coming through. If you've done camera bring-up on embedded Linux, you know this particular flavor of failure: everything looks right, but the pipeline produces no data.
The debugging surface was enormous. It could have been lane configuration, clock timing, sensor register sequencing, D-PHY initialization, IPU CSI routing, or some combination. I spent a significant amount of time exploring the possibilities, but couldn't isolate the issue.
Konsulko Group
I was stuck, and I honestly didn't know how to proceed. Rather than keep burning my client's time and money thrashing on a problem I couldn't solve alone, I let them know I needed help. They were actually appreciative of the honesty. I started reaching out to embedded Linux experts who had experience with the i.MX media subsystem, and that's when I discovered Konsulko Group.
Konsulko has deep experience with embedded Linux media pipelines and i.MX platforms specifically. With their help, I was able to get the MIPI link functioning and frames flowing from the AR0521 into the capture pipeline.
This was the turning point. Once I could see an image — even if it wasn't configured correctly — the problem shifted from "is the plumbing broken?" to "what register settings does this sensor need?"
Using onsemi's Dev Board and Windows Tool
The AR0521 is a register-heavy sensor. Resolution, blanking, PLL, gain, exposure, and output format are all controlled through a large register map. The datasheet was frustratingly sparse, and not all registers were documented.
However, onsemi provides a development board for the AR0521 along with a Windows-based evaluation tool. This tool lets you configure the sensor graphically and observe the resulting register writes in real time. I used it to dial in the exact register settings I needed — resolution, timing, exposure — and captured the register addresses and values for each configuration.
Rather than reworking the kernel driver to apply all of these settings internally, I exposed the register interface through a /proc entry in the driver and wrote a userspace script that applied the register settings after initialization. This allowed me to iterate rapidly: adjust a value in the script, restart the pipeline, and check the image.
The Result
The system went into production. My client had a functioning camera pipeline on the CC6 with the AR0521 capturing at the resolution and quality they needed.
The original AR0521 patch I started with was eventually mainlined. My driver is nowhere near as capable or clean as the upstream driver, and my strategy for using the proc interface and a userspace shell script is not the greatest. But, after 5 years, that driver is still present in a real product!
Key Takeaways
Start from existing work: The pre-mainline patch gave me a functioning I2C and V4L2 skeleton. Building that from zero would have added weeks. Even incomplete upstream work has value — someone else has already figured out the device tree bindings, the basic register layout, and the subdev structure.
Initialization success doesn't mean the pipeline works: The sensor responding to I2C commands and the V4L2 device appearing are necessary but nowhere near sufficient. The real complexity in camera bring-up lies in the MIPI link — lane states, clock timing, and the handshake between the sensor and the CPU’s image subsystem.
Use every tool available: There's a temptation in embedded Linux development to stay purely in the open-source ecosystem. But onsemi's evaluation tool gave me ground truth that I couldn't have easily obtained any other way. Knowing the exact register values for a working configuration turned an open-ended debugging problem into a porting exercise.
Know when to ask for help: I lost time trying to debug the MIPI capture pipeline alone. Konsulko Group had seen these issues before and identified the problem faster than I could through trial and error. The engagement cost was a fraction of what continued thrashing would have cost my client in timeline slippage.
I build production embedded Linux systems and firmware for hardware companies at MAB Labs. If your team is working through a challenging embedded Linux problem, let's talk.
