media0 with no video0 device node: the sensor driver never probed

You boot the board with the camera module seated, and Linux creates /dev/media0 but no /dev/video0. Every capture tool then finds nothing to open, and the camera looks dead. That pair of facts is a precise diagnosis rather than a mystery: the receiver side of the camera interface probed, and the sensor driver never bound. This page shows you how to read the boot trail to confirm which layer failed, the fix order for the common case, and the point at which switching to a USB3 or GigE board camera beats more driver work. Everything here runs from a shell on the target board, so you can work through it over a serial console.

What /dev/media0 proves, and what it does not

Two different kernel drivers create those two nodes. The CSI receiver, the silicon block that terminates the camera lanes, is a media controller: its driver registers /dev/media0 as soon as it probes at boot, whether or not a camera is connected. The video node is different. It appears only after a sensor driver binds to the receiver, registers its subdevice, and completes the capture pipeline. Only then does the kernel create /dev/video0.

So media0 with no video0 is the kernel telling you plainly: the receiver probed, and the sensor driver did not. The camera was never detected, because no driver ever asked for it.

Three related failures sit one layer apart, and they have different fixes:

• No media node and no video node at all: the receiver driver or the CSI interface itself is not enabled. Work through the CSI camera V4L2 no such device error: enable the interface first checks.
• The sensor probes but the video node is still missing: the driver bound and the pipeline is incomplete. That is the fault the sensor probes but no video node: fix the devicetree chain guide resolves.
• The wrong sensor driver claims the device: read camera loads the wrong sensor driver: read dmesg, fix the overlay to tell the signatures apart.

The empty trail is the first case, and it is the most common outcome when a module meets a board whose vendor never shipped that sensor's driver.

Read the dmesg trail first

One command separates "never probed" from "probed and failed". For an IMX219 module, the trail check is exactly what the module name suggests:

dmesg | grep imx219

On any other sensor, grep its part number instead, because the driver's probe lines carry it. Read the result against three signatures:

• Empty output: the driver never ran its probe function. The camera side of the story has not started, so the fix is driver or device-tree work, covered below.
• Probe lines ending in a failure with a negative error code: the driver ran and was refused, typically over power, a clock or the I2C link. Follow the MIPI camera probe failed error -121: read the dmesg trail sequence.
• A clean probe line and a bound subdevice, with capture still failing: the sensor is in. Move to the MIPI sensor detected but streaming fails: power, clocks, device tree checks.

Reseating the ribbon cable does nothing for the empty trail. The media node is the evidence: the receiver, the part the cable plugs into, probed fine.

Why the sensor driver never probed

A sensor driver runs its probe only when two things are true at once: the driver is present in the kernel, and a device-tree node exists for it to bind to. Miss either one and the boot log stays silent.

• Driver missing: the SoC vendor's board-support package decides which sensor drivers are built in or shipped as modules. A sensor the package does not know simply has no code on the board.
• Node missing: the device tree must describe the sensor on the correct I2C bus, with the address and the compatible string the driver matches, and with status enabled. Vendors ship this as an overlay, and the module vendor's instructions are explicit that you edit the device tree file for your hardware setup before boot.
• Pairing mismatch: an overlay built for a different module or a different camera connector leaves the node where no driver looks. The camera device tree overlay CSI mapping troubleshooting guide shows how the connector mapping goes wrong in practice.

None of these is a hardware fault, which is why the cable, the connector and the module usually turn out to be fine.

Fix it in this order

1. Name the sensor. Take the part number from the module's data sheet; it is the string your grep and your device tree both need.
2. Ask the module vendor for the driver package for your exact board. It should contain the sensor driver and a matching overlay. If the vendor publishes no package for your board, that answer decides the rest of the project; the worked example below turns it into a decision.
3. Apply the overlay the package ships, editing the device tree for your hardware setup exactly as the package's own instructions describe. Change one variable at a time; do not hand-edit a vendor overlay for a different module first.
4. Reboot and rerun the grep. You now expect probe lines that name the sensor and end in a successful bind.
5. List the video nodes again. The video node appears once the sensor subdev binds to the receiver and the pipeline completes.
6. Query the node: point v4l2-ctl at it with -d /dev/video0 and read the format the driver reports. Then capture one frame and look at it.
7. If frames arrive but look wrong, raw, green or shifted, the sensor layer is done and the faults move downstream. The CSI camera with no ISP: what raw sensor output means guide explains the raw case.

Verify the fix held

Three checks, in order, and each one gates the next:

• The grep now returns the sensor's probe line. An empty trail after a driver change means the overlay did not apply; check the bootloader stage applied it before blaming the driver.
• The video node exists where your capture application looks. If the kernel sees the sensor but your libcamera-based stack still lists nothing, the gap between kernel and user space is what the kernel detects the sensor but libcamera lists no camera device guide addresses.
• One captured frame opens and shows the scene. Boards whose ISP needs its own driver make this step literal: a walkthrough of capturing raw IMX219 frames during ISP driver setup shows what a working raw path looks like before the ISP is in place.

Record what worked. The sensor part number, the kernel version and the overlay file belong on one line of your build notes, because the next board you image will need the identical triple.

Worked example: a 12 fps belt need met by a 120 fps USB3 board camera

Suppose the vendor answer at step 2 comes back empty: no driver for your board, none in the board-support package, none planned. The decision is now build versus switch, and the inspection rate sets the terms.

Inputs:

• Belt speed 0.3 m/s with one part every 25 mm: example line values, typical of small-part sorting.
• One frame per part, parts moving while exposed: the shutter must be global.
• Candidate replacement: a USB3 board camera, because its bring-up is USB enumeration rather than device-tree work.

Rule in words: the camera must deliver at least one frame per part, so its frame rate must meet the parts-per-second rate, and motion rules out a rolling shutter.

On the switch side, the LS-BCM-0003 prints 120 fps at 3.1 MP on a 1/1.8" global-shutter IMX252 sensor with a C-mount. The margin is 120 fps / 12 fps = 10x, which absorbs a belt speed up to 3.0 m/s before the rate binds again, and the global shutter answers the motion constraint. Bring-up becomes a USB enumeration problem: the host controller's own stack, no overlay, no kernel rebuild.

Decision: with no sensor driver available, switch the interface rather than port the driver. This example's line needs 12 fps and the USB3 module provides 120 fps, ten times over.

When switching interfaces beats more driver work

The rule from the worked example generalizes: the interface question is decided by driver availability first, and only then by cable length and bandwidth.

• USB3 board cameras for short runs. The host controller enumerates the camera through its own stack, with no overlay and no kernel rebuild, and USB3 carries multi-megapixel streams at industrial frame rates. The MV-CB060-10UM-B ships as a bare board: a 6 MP USB3 camera on an IMX178 mono sensor with no lens mount, so you fit the optics the machine needs. The failure modes move to user space too; the UVC camera not detected: identify the device node first checks are configuration work, not kernel work.
• GigE board cameras for long runs. A CSI ribbon run is short, while a GigE link runs 100 m over copper as 1000BASE-T defines it. The MV-CB016-10GM-M-W covers that case: a 1.6 MP GigE board camera on a global-shutter IMX296 sensor with an M12 mount.
• Full-size cameras when the module's sensor or optics no longer fit the task. Industrial cameras speak GigE or USB3 natively, so the CSI driver question disappears; compare in the area scan cameras category. The MV-CS200-10UM is a 20 MP USB3.0 camera on a 1" IMX183 sensor with a C-mount and a rolling shutter.

Browse the board-level cameras category for the other module options, or filter by interface and shutter in the camera finder.

Prevention for the next project

Driver availability is a purchasing question, so ask it before the purchase:

• Put the sensor-and-board-support-package question first in the evaluation. The board camera evaluation checklist for inspection systems makes it an explicit line item, and the board level camera sensor compatibility: match the host before you buy guide covers the pairing from the sensor side.
• Prefer interfaces the host already speaks when the schedule is tight. The board level camera selection for embedded vision machines guide weighs CSI against USB3 and GigE for exactly this reason.
• Record the triple that made it work, sensor part number plus kernel version plus overlay file, next to the camera's hardware revision. The board-level camera hardware revision compatibility: before you reorder guide explains why that revision line matters at reorder time.

More diagnostics from this area sit on the systems topic page. If you want a second opinion on the driver question for a specific module-and-board pairing, ask through the contact page before you order: expert support comes with every order, and it costs far less than a week of kernel archaeology. To move straight to a chain that enumerates without overlay work, start the camera configurator at the camera step.