MIPI camera not detected: I2C bus and device tree checks

You installed the camera vendor's driver package on your carrier board, the script finished cleanly, and then nothing happened: no video device nodes, no probe line in the boot log, and no sensor address on any I2C bus you scan. That combination is not a configuration mistake you can reinstall away. It is the signature of a camera the kernel has never been told exists, because the carrier's device tree never declares the sensor, its I2C address or its CSI lane mapping. This guide is for engineers bringing MIPI camera modules onto system-on-module carrier boards. In ten minutes you will be able to tell a dead flex from a missing power rail, a bus-number mismatch from a missing device-tree node, and decide whether to obtain the carrier's camera overlay or move the camera to USB3 or GigE.

The signature: a clean install and total silence

Work the evidence in this order:

1. The install exits 0. The script copied driver files and rebuilt modules. That is all it did; an installer cannot prove hardware exists.
2. No video nodes appear. A bound sensor driver creates V4L2 video nodes under /dev/video*. An unchanged list means nothing bound.
3. The boot log is silent. Filter dmesg for the sensor's part name. A healthy boot prints a probe line naming the I2C bus and the address. Silence means the kernel had no node to probe, so no attempt was ever made.
4. Every I2C bus scan comes back empty. Not one address anywhere, not even a wrong one.

Points 3 and 4 together are the fork that matters. A broken link or an unpowered sensor on a carrier whose camera support is published still produces probe attempts that fail with timeouts or a wrong chip ID. Total silence is a different failure: the description of the camera never reached the kernel, so there is nothing for a driver to fail against.

Read the scan correctly

i2cdetect probes a bus address by address and prints what answers. Three outcomes per cell: an address such as 34 means a device acknowledged there; UU means a bound driver has already claimed it; -- means nothing answered. Scan the bus your camera connector is wired to, and when in doubt scan all of them in one pass:

for b in /dev/i2c-*; do i2cdetect -y -r ${b#/dev/i2c-}; done

The ${b#/dev/i2c-} strips each path down to the bus number i2cdetect expects. Run the scan twice, module unplugged and then plugged in: the address that appears is your sensor.

Silence or errors: two different failures

The fork decides where to spend your time.

• Probe attempts with errors. The tree declares the sensor and the driver is talking, but answers never arrive: repeated timeouts, an I2C error -121 (remote I/O failure) on the probe, or a chip ID that reads all zeros. The physical link or the power is broken. Work the seating, flex and rail checks in I2C error -121 on a camera sensor probe: fix the physical link, then the identification checks in MIPI camera sensor ID mismatch: diagnose the wrong I2C probe.
• No probe attempt at all. The kernel has no node describing the sensor, so no driver is ever matched to it. This is the failure this article is about, and no amount of driver work repairs it.

The same fork prices the repair: a link error on a carrier with published camera support is minutes of bench work; a carrier with no camera documentation is a design problem measured in weeks. Once an address does answer and the node binds, downstream failures have their own guide — start with MIPI sensor detected but streaming fails: power, clocks, device tree when no frames arrive.

Prove the module is alive first

Put the same module, the same flex and the same driver package on a host that is known to support it: the SoM vendor's development kit, or the carrier the camera kit is validated against. If it enumerates there, the module is good, and everything after this point concerns your carrier's device tree.

If no second host exists, measure. Most sensor modules run from a 2.8 V analog rail and 1.8 V digital rails; the carrier schematic lists which connector pin carries which. With the module removed and the system booted, probe each supply pin. A rail stuck at 0 V means the enable GPIO never fired — a device-tree regulator problem, not a camera problem. A scope on the master-clock pin should show the clock frequency the overlay requests; a dead clock leaves the sensor unable to answer even a correct scan.

Reseat the flex in both connectors before any of this. A half-seated flat flex produces exactly this silence, and eliminating it costs nothing.

Likely causes, in order of probability

With a clean install, a silent log and empty scans, test the causes in this order:

Two refinements. If a probe line exists but names a different driver than you expect, node and driver disagree — that is a binding problem with its own diagnostics in camera driver device tree mismatch: diagnose missing DTBs and camera loads the wrong sensor driver: read dmesg, fix the overlay. Probe errors that do appear are worked step by step in camera I2C communication failure: diagnose sensor probe errors.

Why reinstalling the driver cannot help

On a device-tree platform a driver never hunts for cameras. At boot, the kernel matches each node's compatible string against each driver's table; a match instantiates the device and calls the driver's probe function. No node means no match means no probe call, however many times you reinstall or rebuild. That is why the vendor script completes and changes nothing: it delivered software for a device the kernel has never been introduced to.

The sensor's I2C address is not the driver's to guess either. It lives in the reg property of the node, next to the lane mapping, the master clock and the power GPIOs. Manually loading the module hits the same wall: the driver waits for a device that never appears. The repair is a node — an overlay from the carrier vendor that describes the sensor, its address, its lanes, its clock and its GPIOs. Nothing else creates that description.

The decision: documented overlay or a different interface

Commit to one of three paths, based on what the carrier vendor can put in front of you:

1. The carrier documents your camera kit and ships an overlay. Install it as written and re-check the three evidence points. Expect a probe line within one boot. Done — stop modifying vendor files.
2. The carrier has the connector but no overlay for your sensor. Ask the vendor for one before writing anything yourself. If it arrives, timebox a day to validate. If it will not, you are on path 3.
3. The carrier never declared camera support. Do not hand-build the tree for a machine that has to ship. A correct node needs the schematic's lane mapping, the enable GPIO numbers, the clock wiring and a driver matched to the sensor's register set — typically weeks of bring-up, with a real chance of over-powering the sensor on the first attempt. Change the interface instead.

Changing the interface removes the whole class of failure. A USB3 or GigE board camera is handled by the host's standard vision stack: enumerate, calibrate, run. No overlay, no lane mapping, no sensor node. If the MIPI modules are already bought and must stay, a converter is the middle road — read MIPI CSI to USB UVC bridge: what a converter board must include before ordering one.

The board-level cameras range covers both interfaces. The LS-BCM-0003 delivers 3.1 MP at 120 fps with a global shutter on USB3, so it also handles moving parts. The MV-CB060-10UM-B is a 6 MP bare-board module for tight spaces, and the LS-BCM-0020 covers distance: 6.3 MP rolling shutter in a CS-mount on GigE. For reach, GigE runs to 100 m on standard cabling; USB3 is a desk-length interface of a few metres.

Size the rest of the chain in the camera finder or start the camera configurator to match lens and cable in one pass. The full selection method is in board level camera selection for embedded vision machines.

Before the next carrier: four checks that prevent this

1. Ask for the overlay before you buy. A vendor who supports cameras can name the I2C bus and the address your sensor will appear on. If they cannot name both, the camera will be invisible — this article, seen in advance.
2. Check the sensor against the SoM vendor's supported list. The driver must exist before any overlay can reference it.
3. Count the CSI lanes per connector. Modules come in 2-lane and 4-lane versions, and a connector wired for two lanes will not carry a 4-lane module as built. What a lane budget does to frame rate is quantified in MIPI camera lane bandwidth: what limits frame rate.
4. Run the difference scan at first boot. Prove the sensor answers on day one, before the mechanical build hides the connector.

The complete verification list is in CSI camera carrier board compatibility: what to verify, and the board camera evaluation checklist for inspection systems extends it to optics, lighting and throughput.

If your carrier cannot produce an overlay, send its documentation through the contact page and we will confirm whether camera support exists before you spend a day on it. If the answer is to change interface, in-stock items ship within one business day.