Two camera overlays on one CSI port: probe failed, fix the config

A camera module that is wired perfectly can still come up dead because two software entries claim the same port. The signature is specific: the camera test tool reports no cameras available, and dmesg shows a driver reaching the camera's I2C address and then logging probe failed. In the case behind this guide, the boot configuration carried two camera overlay lines at once — one for the fitted 12 MP IMX708 sensor and one for a module family the sensor does not belong to. The sensor was never faulty; the extra overlay kept the port from ever getting a working driver. Here you will learn to read that log, decide which overlay owns the port, make the one-line fix in config.txt, and verify the camera came back.

What the log says when two overlays fight

Start with what the tool message does and does not mean. no cameras available means the capture stack found no configured sensor to open; it says nothing about the cause. dmesg holds the diagnosis. The failing driver first read a module ID over I2C — here 0x0301 — and then stopped:

11-000c: probe failed

The fragment before the colon decodes as I2C bus 11, device address 0x0c: the control bus assigned to that camera connector, and the sensor's 7-bit address on it. The name printed before that fragment is the driver that failed, and it matches one of the dtoverlay= lines in the boot configuration.

Read the two lines together and the hardware is already cleared. A driver that reads an ID over I2C has a working ribbon, working power and a live control bus. The failure sits in which driver was declared, not in the cable. In the logged case the module had never been detected on any boot, which is typical: the wrong declaration sits in the file from the first power-on.

One port, one overlay: the rule that was broken

The dtoverlay option tells the boot firmware to merge a named overlay into the device tree the kernel receives. Every camera overlay writes a sensor declaration into the same device-tree slot for a given connector: one driver, one I2C address, one sensor. Load two camera overlays for one connector and they compete for that slot. The port keeps at most one binding. When the surviving driver is written for a different module family, its identification read fails, and the connector ends up with no camera at all. That is the entire failure in this case: a 12 MP IMX708 behind a driver that belongs to another module family.

The decision rule that prevents the whole class of problem takes one look at the module. A bare sensor module takes the overlay named for its sensor; a module with its own image co-processor takes the vendor's overlay, which loads the vendor driver instead of the sensor's. The fitted module here is a bare sensor, so imx708 was the only camera line that belonged in the file. The second line enabled an overlay for a different module family, and it had no business claiming bus 11.

Two devices wired to one I2C address fail the same way from the hardware side; Two image sensors with the same I2C address: bus options that work covers that variant. When the overlay and the fitted chip disagree about the sensor itself, follow Camera loads the wrong sensor driver: read dmesg, fix the overlay.

Likely causes, in order of probability

Work down this list; the first three live in one file.

1. Two camera overlays enabled for one connector. The most likely cause when the failing driver's name matches a line you added on purpose. Test: count the camera lines in the boot configuration; two is one too many.
2. Overlay written for a different module. Someone followed a setup page for a different camera or an older board generation, so the declared driver never matches the silicon. Test: compare the failing driver's name with the part number printed on the module.
3. Edit made to a file the firmware never reads. Current OS images keep the boot configuration at /boot/firmware/config.txt; older instructions point at the previous path, and edits there look applied but never load. Test: confirm the file you edited is the one the firmware reads.
4. Ribbon or connector. Least likely here, because the log shows live I2C traffic. Test: reseat both ends of the ribbon and check contact orientation against the connector's drawing. When a sensor never answers at all, Camera I2C communication failure: diagnose sensor probe errors walks the physical link.

The fix: keep the overlay that matches the sensor

1. Open the boot configuration at /boot/firmware/config.txt.
2. List every overlay line with grep -n "dtoverlay" /boot/firmware/config.txt; the line numbers keep the count honest.
3. Decide which line matches the fitted sensor. Read the part number off the largest chip on the camera board: a 12 MP IMX708 takes dtoverlay=imx708. A module that carries its own co-processor takes the overlay named in that module's documentation.
4. Delete the other camera line, or comment it out by starting the line with # and noting which module it served, so nobody re-enables it next week.
5. Save and reboot. Overlays are merged at boot and at no other time; nothing needs reinstalling.

In the case behind this guide the file went from two camera lines to one:

# CAM 1: 12 MP IMX708 module
dtoverlay=imx708

The first boot after the edit bound the sensor to its own driver, and the capture tool listed the camera immediately.

Worked example: two lines, one address

The whole diagnosis is a chain of identifiers you already have:

• 0x0301 answered over I2C → ribbon, power and control bus all work → suspect software.
• 11-000c → bus 11, address 0x0c → one sensor sits at that address.
• Two dtoverlay= camera lines → two declarations competing for one connector's slot → at most one binding survives.
• The failing driver's name matches the vendor-family overlay; the fitted chip reads IMX708 → that line is the wrong declaration → remove it.
• One camera line remains and it names the fitted sensor (imx708) → declaration now matches silicon → reboot and expect a clean bind.

One address, one driver, one line that names the chip on the board: the decision takes less time than reflashing the OS, which is what most people try first.

How to verify the camera is back

Re-run dmesg first: the probe failed line should be gone, and a search for the sensor name should show its driver binding without a failure. Then run the capture stack's test tool — the device list should replace the no cameras available message. The confirmation that closed this case was the still-capture utility started with a zero timeout (-t 0), which opened a live preview from the sensor. If the tool now lists the camera but frames tear or drop, the port is fine and the problem has moved downstream; MIPI sensor detected but streaming fails: power, clocks, device tree is the next ladder.

Keep it from happening on the next module swap

• One camera overlay per connector, always. When a module is removed, comment its line out with a note naming the module it served.
• Match the overlay to the chip, not to the brand. Read the part number on the board before typing any line into the boot configuration.
• Check the setup page's board generation. Pages written for older boards name overlays and file paths that do not apply to the newest generation.
• Grep before you power on. One command lists every overlay the next boot will load; a five-second look beats a wasted cycle.
• Verify compatibility before purchase, not after. MIPI CSI-2 camera compatibility: beyond the connector and Camera module interface compatibility: what to verify list the checks that matter.

When the port is not worth another hour

If exactly one correct overlay still fails after a clean reboot, run the one-swap test: a second known-good module of the same type, same ribbon, same connector. A clean boot with the spare condemns the first module; the same log with the spare condemns the file or the board, and Camera driver device tree mismatch: diagnose missing DTBs covers the deepest software layer left.

If you control the bill of materials, remove the failure class instead of debugging it. A USB3 or GigE board-level camera enumerates as a USB or network device: no overlay to declare, no I2C address to share, and the driver ships with the camera. This 3.1 MP USB3 board-level camera — a 1/1.8" global-shutter module with a C-mount that streams 120 fps — comes up with a cable and a library, not a device tree.

On a moving axis, pair it with drag-chain-rated camera data cables, and choose interface and shutter with Board level camera selection for embedded vision machines. The camera finder filters board-level cameras by interface, resolution and shutter type, and the configurator matches lens and cable to the camera you pick. If a port fight is eating project time, contact us with the board and the frame rate you need, and we will spec the camera side around what you already run.