MIPI camera probe failed error -121: read the dmesg trail

An embedded board boots, your capture stack reports No cameras available, and dmesg ends the camera's story with probe of ... failed with error -121. That one number settles the diagnosis: the kernel's I2C subsystem got no acknowledgement at the sensor's address, so the module was electrically silent at boot. Reinstalling the camera stack will not move it. This guide is for anyone bringing up a MIPI CSI-2 board camera on an embedded Linux board. You will read the probe trail line by line, test the physical causes in order of likelihood, and recognize the one branch where the fault really is in the device tree.

What error -121 actually means

On the ARM64 and x86 kernels that embedded vision boards run, errno 121 is EREMOTEIO, the remote I/O error. Within the I2C subsystem it has one meaning: the target did not acknowledge. The controller clocked out the address, waited for the sensor to pull SDA low for the ninth bit, and nothing came. Some adapters also report it when a data byte goes unacknowledged, but the common case is the address NACK: nobody answered at that address.

A timeout is a different error. On the same kernels it is -110, ETIMEDOUT, and it usually means a bus line is held low while the adapter waits out its budget. Keep the two apart, because the tests differ: -121 sends you to power, clock, wiring and address; -110 sends you to a wedged line.

Because the probe failed, the driver never bound. No subdev registers, no /dev/video* node, so the capture stack reports No cameras available or its equivalent. A MIPI module, unlike a USB camera, does not enumerate when you plug it in: the nodes appear only when a driver probes successfully at boot. That is why reinstalling userspace changes nothing - the failure happened on the bus, about a second and a half into the boot, before any application ran.

Read the dmesg trail first

Boot once and grep the log for the sensor's name - the sensor part number is the usual driver name:

sudo dmesg | grep -i ov5693

A failing boot prints a trail in this shape; the sensor name, bus and address vary with your module:

[    1.500781] ov5693 2-0036: probing v4l2 sensor.
[    1.509215] ov5693 2-0036: sensor driver bound (version 2.0.6)
[    1.534412] ov5693 2-0036: could not read otp bank
[    1.534421] ov5693 2-0036: Error -121 reading otp data
[    1.538667] ov5693 2-0036: board setup failed
[    1.540438] ov5693: probe of 2-0036 failed with error -121

Read it line by line. The first line proves the device tree matched: a driver prints it only once it has claimed a node. The second is the driver's own banner; keep it, because it names the driver version your logs refer to. The third and fourth are the first register reads over I2C - module ID and OTP data, which sensor drivers read to identify what they are driving - and they failed with exactly the -121 NACK. The fifth is the driver abandoning board setup, and the last is the kernel recording the failed probe in its standard form.

That last line also names the client: 2-0036 means I2C bus 2, address 0x36 (54 decimal, 7-bit). You will need both numbers in the next sections.

Now the arithmetic that rules out a hang: 1.540438 - 1.500781 = 0.039657, so the whole failed probe took about 40 ms. That is an instant NACK, not a stuck bus; a genuine timeout lands only after the adapter has burned its whole timeout budget, commonly around a second per transfer. The trail has already decided the first fork for you: the banner printed, so the device tree is present and formatted correctly; the bus answered with silence, so the fault is electrical or structural. Work through the physical causes first.

The causes, in order of probability

With the software side cleared, test these in order. The first three cover almost every -121 at boot; the rest are rarer.

Power sequencing deserves a word of its own. MIPI modules typically combine a 2.8 V analog rail, a 1.8 V I/O rail and a lower core rail, and a sensor with a dead I/O rail cannot answer even a correctly addressed read. Meter at the module's connector, not at the regulator, so the measurement includes the flex.

The master clock is the usual silent culprit. Sensor master clocks commonly run between 6 and 27 MHz, and some sensors gate their whole I2C interface on that clock: no clock, no acknowledgement, even with perfect power. A flat clock line during boot is as often a device-tree problem as a hardware one, because the clock starts only if the node assigns it to a provider the kernel controls.

Prove the bus with a runtime scan

With the board fully booted, ask the bus directly whether the module answers now.

1. Take the bus number from the client name: 2-0036 means bus 2. The same entry sits under /sys/bus/i2c/devices/2-0036 even after a failed probe, because the client is registered whether or not a driver bound to it.
2. Confirm the matching /dev/i2c-2 node exists; on most boards the bus number is also the N in /dev/i2c-N.
3. Scan the bus with sudo i2cdetect -y 2. On a bus that also carries a PMIC or another live device, add -r so the scan uses read-byte probes, and never scan while the sensor is streaming.
4. Interpret the result against this table.

The middle row is the valuable one. A module that answers a runtime scan but NACKed at boot was not alive yet when the driver knocked: the regulator came up late, the enable line fired late, or the clock provider had not started. The kernel has a mechanism for exactly this - a driver whose supplies and clocks are wired to real providers gets its probe deferred until they exist, instead of failing at 1.5 s. Forcing the rails always-on is a legitimate bench test to prove that diagnosis; it is not a fix to ship.

If the scan is empty with rails measured present and a clock visible on the scope, swap in a known-good module. When the known-good module probes cleanly in the same slot, the first module's I2C pads are the fault, and that is the end of the trail for that board.

What the device tree must get right

If the trail printed the probing banner, the compatible string matched and the node's basic form is correct, so resist the urge to rewrite the driver or the framework. Four node details still produce a -121, and all of them starve the bus rather than break the format:

• reg - the 7-bit address. 2-0036 means the kernel knocks at 0x36; if your module answers at another address, every read is a NACK.
• Supplies - the analog, I/O and core supplies must point at regulators the kernel controls, so they are on before the probe and can hold the probe back if they come up late.
• Clocks - the master clock must be assigned from a provider the kernel starts; an unassigned clock may never run.
• Status and placement - cat /proc/device-tree/<bus-node>/<sensor-node>/status should read okay, and the node must sit under the controller the module is physically wired to. On the failing board in the example, the node i2c@3180000/ov5693_c@36 and its okay status were both fine, which is exactly why the trail reached the bus at all.

Lane count lives in this layer too. A module wired for two data lanes that the node declares as four can fail the probe as well as the stream, because the stack validates the configuration when it sets the sensor up. The 2-lane vs 4-lane mode guide covers that branch.

Error -121 versus its neighbours

A probe can fail in ways that look similar and are not. Match your trail against these signatures before touching hardware:

When the trail matches yours but the physical link itself is the suspect - corroded contacts, a cracked flex, a pad lifted by a reseat - the companion guide to fixing the physical link takes over where this one stops.

Bring-up order that prevents the next -121

Prevention is mostly sequence discipline. A bring-up that measures before it configures never spends a day chasing a dead probe:

• Measure the rails at the module connector, flex unplugged and then plugged, before the first boot.
• Scope or otherwise check the master clock before pointing a driver at the module.
• Run i2cdetect on the camera bus before configuring the sensor node; a silent module found at this stage costs minutes, not days.
• Save every boot's dmesg to persistent storage or a serial console, and keep the trail of a known-good boot beside it.
• Change one thing per boot - module, flex, rail, device tree. Two changes make a passing boot useless as evidence.

When the probe passes

The trail you want ends with the sensor bound: the same first two lines, then the driver reading its ID without the -121, then the camera framework registering its nodes and the capture stack finding them. From there the bring-up moves downstream to lane configuration, pixel formats and streaming, which the guides linked above cover.

If you are specifying hardware rather than repairing it, apply the same checks at purchase time: pick the sensor and module first, then the carrier's camera support. Start from the board-level cameras, filter them in the camera finder, or step through the camera stage of the configurator. The systems topic page collects the rest of the bring-up guides, and our applications team answers bring-up questions through the contact page when an order needs a second pair of eyes.