Move a CSI camera to a new compute module: compatibility checks

You qualified a MIPI CSI-2 board camera on one compute module, and the next machine uses a different system-on-module in the same family. The bench question is always the same: does the camera carry over, or do you wait for a camera built for the new module? In most cases it carries over. The sensor speaks a defined standard and does not care which module reads it. What changes is everything around the sensor: the driver package, one or two connector nets that are renamed or re-assigned between module generations, and the lane budget on the new module. The checks below decide the move, the lane arithmetic tells you whether the frame rate survives, and the fallback is a USB3 board camera that removes the per-module driver work.

The short answer

Reuse the camera when three checks pass. One: the camera maker publishes a driver release package that names the new module. Two: the two connector pin tables match net for net. Three: your lane budget fits inside the lanes the new module routes to the connector.

Port the driver yourself when no release package exists but you have board-support source access and the camera is already optically qualified — count on days for a port of a documented driver, weeks for a fresh bring-up.

Change the interface when the new module runs a locked image, or the connector family or lane routing simply does not fit. A USB3 board camera keeps your optics and removes the per-module driver work entirely.

What must match, and what never carries over

The sensor never blocks the move. MIPI CSI-2 defines the lanes, the clock channel and the packet format, and those are identical on both sides of any compliant link. Everything the module maker builds around that standard is where compatibility is won or lost.

The last row is the one engineers underestimate. "Designed for" a module means the camera vendor wrote and tested a sensor driver and a device-tree overlay against that module's capture engine, regulators and clock tree — not that the sensor itself is unusual. For the same check viewed from the carrier side of the cable, the CSI camera carrier board compatibility guide walks the connector-level items.

The lane budget: does the frame rate survive?

Every CSI-2 data lane carries up to roughly 2.5 Gbit/s in common embedded implementations, and four lanes together reach about 10 Gbit/s. The payload shares the link with packet framing and line blanking, so plan at 1.2 times the raw pixel rate and keep each lane at or below about 80% utilisation.

Worked example — a 6 MP camera, 3072 × 2048 pixels, 30 fps, RAW10:

• 3072 × 2048 = 6,291,456 pixels per frame
• 6,291,456 × 30 = 188,743,680 pixels per second
• 188,743,680 × 10 bit = 1,887,436,800 bit/s ≈ 1.89 Gbit/s of payload
• 1.89 × 1.2 = 2.26 Gbit/s to plan for
• One lane: 2.26 ÷ 2.5 = 90% utilisation — nothing left for burst and blanking variance
• Two lanes: 2.26 ÷ 5.0 = 45% — comfortable

Decision: this camera needs two data lanes. A module that routes only one lane will not hold the full 30 fps, and no driver setting recovers bandwidth the link does not have. The reverse mismatch is worse: a camera that declares four lanes on a module that routes two fails to probe at all. Both signatures are covered in the 2-lane vs 4-lane probe failure article, and what limits frame rate on a MIPI camera extends this arithmetic to binning and ROI.

Pin tables: the one or two nets that break bring-up

Module generations often keep the same FFC receptacle while re-purposing one or two nets. The camera design guides list the two connector tables side by side, and the differences concentrate in three places: an I2C controller swap that moves the sensor to a different bus number, a camera power-enable line that lands on another GPIO, or a spare general-purpose line re-assigned as a camera error input. Power and ground usually stay put, so the assembly boots and looks correct — then the sensor probe fails for no visible reason.

Put both tables side by side and tick every net: data lanes 0–3, clock lane, I2C SCL and SDA, power enable, error or interrupt, grounds. Then update the device-tree overlay to the new bus number and GPIO references. The overlay is where a renamed pin becomes a one-line fix instead of a hardware change.

When the sensor is detected but no frames arrive, the failure has moved past the pin table into power sequencing, clocks or the overlay itself; the sensor detected but streaming fails article walks that order. An error on the I2C leg alone has its own test sequence in the camera I2C communication failure article.

The driver package: written per module, carried over never

The sensor driver and its device-tree overlay are written against one module family: the capture engine's API, the regulator enables, the clock tree. The overlay encodes exactly what the pin table states — lane count, I2C bus and address, power GPIOs, sensor clock. Move the camera to another module and that pair must be rebuilt even when the sensor part number is identical.

So the first document to read is the camera maker's release notes, not the sensor data sheet. Board-camera vendors publish per-module release packages; when your module family appears in one, you install that package and the camera behaves like a native part of the machine. When it does not appear, ask the vendor — support for new modules is added continuously — and meanwhile read what the old module actually loaded: the wrong sensor driver, read from dmesg article shows the boot messages to compare between the two modules.

One module-side limit sits outside the driver: the capture pipeline must list the sensor's resolution and pixel format. A camera can be electrically perfect and still be capped because the pipeline lacks the format, so MIPI CSI camera resolution limits: verify the host belongs in the same pass as the driver check.

When to change the interface instead

CSI buys low power and a short, fixed cable; it charges a per-module driver for the privilege. When the porting effort is not justified — locked module image, no release package, mismatched connector family — a USB3 board camera plugs into the port the compute module already has:

The LS-BCM-0003 is a 3.1 MP USB3 board camera with a global shutter and a C-mount lens mount. The MV-CB060-10UM-B is a 6 MP bare-board USB3 camera with a rolling shutter and no lens mount, for builds that carry their own optics. The LS-BCM-0020 covers the same resolution class over GigE when the camera sits too far from the module for a USB cable.

Size the swap with the same payload math. A USB 3.0 link runs at 5 Gbit/s and delivers about 4 Gbit/s of payload after encoding overhead, so the 2.26 Gbit/s camera in the worked example fits easily, while a four-lane, 10 Gbit/s-class sensor does not. What you buy back: enumeration is standardized, so there is no overlay and no lane budget, and the same C-mount lens usually transfers unchanged.

If you are choosing rather than migrating, the board camera selection guide for inspection machines works the whole decision, and CSI versus USB camera connections on a controller runs the same trade from the controller side.

Checks before you commit

Run this list before the camera ships to the machine:

1. Both pin tables, net by net — the same receptacle is not the same pinout.
2. The release package names your module family and loads on your carrier, not just the module chip.
3. Lane budget from the worked example fits the lanes routed to your connector.
4. The capture pipeline lists your sensor's resolution and pixel format.
5. I2C address free on the new bus — two cameras at one address answer together and neither probes cleanly.
6. Input rail voltage and inrush current inside the carrier's supply budget.
7. FFC length in the 15–30 cm range the camera makers ship; much longer invites lane errors.
8. A 24-hour soak on the new module before you qualify the machine. A stream that dies after hours of running is a different failure from one that never starts; CSI camera timeouts after a long working period covers that signature.

If the camera still refuses to stream after all eight, restart from the beginning of the no-images troubleshooting sequence rather than from the middle.

When the usual answer is wrong

"Just port the driver" is wrong when the new module's pipeline caps the sensor: the same camera can run 60 fps on one module and be held to 30 fps on another, so never promise a cycle time before the rate test on the actual module.

"Wait for the vendor" is wrong when you have board-support source and an optically qualified camera — a documented port is then the faster path, and it keeps the optics you have already qualified.

"Same connector, so it fits" is wrong for dual-camera designs. Running two cameras through one module is a driver feature, not a wiring fact: the old module's release package may cover a sensor pair that the new one does not yet list. And a camera that is detected while delivering no frames is the signature of a lane-map or capture-path fault; a CSI camera detected but delivering no frames works that case to the capture engine.

Which case are you in

• Release package names your new module — reuse the camera, install that package, run the 24-hour soak.
• No package, source access, optics already qualified — port the driver: days for a documented port, weeks for a fresh bring-up.
• Locked image, connector mismatch or too few routed lanes — change the interface: a USB3 board camera behind the same lens, or a CSI camera already listed for the new module.

Then size the chain as one build: the camera finder filters by interface, sensor format and shutter, and the configurator below steps through camera, lens and light together. The cameras topic page collects the embedded-camera guides around this one.