CSI camera V4L2 no such device error: enable the interface first

You ran sudo modprobe bcm2835-v4l2, the shell answered ERROR: could not insert 'bcm2835_v4l2': No such device, and /dev/video0 never appeared, so OpenCV's VideoCapture has nothing to open. This failure is almost never a broken driver. The module file is present; its probe routine ran, asked the board's camera interface for a sensor, was told there was none, and returned the kernel's no-device error. The fix sits in hardware configuration: enable the camera interface, confirm the sensor is detected at boot, and re-seat the ribbon when it is not. The tests below run in order of probability, with the command for each and the point at which you stop debugging the ribbon and fit a camera with a proper interface instead.

What the error is really telling you

modprobe fails in two distinct ways, and the wording tells them apart. A module-not-found message means the name you typed matches no file on disk; that is a spelling problem, covered in Test 3. Your error is different: the module was found, its probe routine ran, found no hardware to bind to, and returned ENODEV (errno 19), which the loader prints as No such device.

On this family of boards the sensor is not wired straight into the kernel. The graphics processor's firmware owns the camera port, and the V4L2 module is a bridge: it asks that firmware for a camera and republishes what it finds as a video device node. When the firmware reports no camera attached, the bridge has nothing to register and refuses to insert. In kernel terms the sensor would appear as a V4L2 sub-device — sensors and camera controllers are the usual sub-devices in the media controller model — so a sensor the bridge never saw simply never becomes one.

Read the error as a detection result and work down this map:

Test 1: the camera interface is disabled

Fresh OS images ship with the camera port turned off, and that state alone produces exactly your error: the firmware only powers and clocks the port when the boot configuration tells it to, and the bridge loads only against a detected sensor. Check this first because it is the default, not a fault.

Run sudo raspi-config, open the Camera entry, enable it, and reboot when prompted. If the node still does not appear, do a full power cycle — shut down, remove power for a few seconds, reconnect — so the port is powered from a cold start rather than a warm restart. The manual route to the same end is an active camera line in /boot/config.txt followed by a reboot.

Then, before touching drivers again:

1. Run ls /dev/video*: on current images the node appears on its own once the interface is enabled and a sensor is detected.
2. On legacy stacks, load the bridge once with sudo modprobe bcm2835-v4l2, then add bcm2835-v4l2 to /etc/modules so it loads at every boot.
3. Re-open the config screen and read its camera detection line. A camera marked detected, with the node present, ends the incident.

Test 2: the ribbon is unreadable

Interface enabled and the loader still answers No such device? The ribbon is next, in this order of likelihood: contacts facing the wrong way, the plug not seated square and fully home, the latch not closed. Power the board down, re-seat both ends, and cold boot. Then run dmesg and search the boot output for the camera lines: when nothing mentions the camera, the firmware never saw the sensor, and the problem is mechanical, not software. A second, known-good camera on the same port separates the two cases — if it is not detected either, the port or the board is at fault and no driver work will change that.

For a hardware-first walk-through of this stage, see image sensor not detected: check the camera module connections. When the log names the sensor but no node appears, the failure has moved into the device tree — the separate case in sensor probes but no video node: fix the devicetree chain.

Test 3: the module name, the node index and /dev/fb0

The module name on the command line is written with a hyphen: bcm2835-v4l2. The insertion error prints the module's internal name with an underscore — 'bcm2835_v4l2' — and that is normal output, not an instruction to type it that way. An underscore in your command gives a module-not-found message instead, which is how you tell the two apart before wasting an afternoon.

Two neighbours of this error also get blamed on the driver:

• A module can refuse to load because it never needs loading: when the bridge is built into the kernel, /dev/video0 exists and modprobe has nothing to add. The same trap on the USB side is described in uvcvideo module not loaded: check for a built-in driver.
• /dev/fb0 is not a camera. It is the display framebuffer — memory the system renders to the screen with — and it will never deliver frames to VideoCapture. Count only /dev/video* nodes as cameras.

Bring the camera up in OpenCV

/dev/video0 exists and belongs to the sensor. Prove the pipeline end to end in this order:

1. List the nodes and pin the one you want in code: ls /dev/video*.

2. Open the camera with a check whose output you can read:

import cv2  # documented API: cv2.VideoCapture, cv2.CAP_PROP_FRAME_WIDTH

device: int = 0                      # illustrative value: first V4L2 node
capture = cv2.VideoCapture(device)   # or cv2.VideoCapture("/dev/video0")
opened: bool = capture.isOpened()
width: float = capture.get(cv2.CAP_PROP_FRAME_WIDTH)
grabbed, frame = capture.read()
print("opened:", opened, "| width:", width, "| frame is None:", frame is None)

A run that prints opened: True and frame is None: False proves node, driver and capture path together; the width value is simply the negotiated format.

3. Expect raw colour. Many CSI sensors deliver unprocessed Bayer data, so a grey or channel-swapped image means the pipeline works and the colour step is missing — see CSI camera with no ISP: what raw sensor output means.

4. Close everything else first. The node allows one process at a time, so viewers and test scripts must release it before your application opens it.

5. Inside containers, pass the media device nodes themselves, not only /dev/video0 — the details are in Camera in Docker: pass V4L2 media nodes.

From here the neighbours change character. A stream that opens but stalls is the case in MIPI sensor detected but streaming fails; controls that will not stick are covered in V4L2 exposure and gain settings a sensor driver ignores. Frames that arrive torn or striped point at signal integrity, not software — V4L2 CSI image artifacts on embedded boards works that case.

When to stop debugging the ribbon

Keep the CSI camera when the board and the sensor live together — a bench rig or one sealed enclosure, no relative movement, no door swinging the cable. Replace it when the camera rides on a machine: the flex connector is not a locking industrial connector, the cable has no strain relief, its reach is measured in centimetres, and the failure you just debugged costs line time on every recurrence.

Two replacements keep the compact form factor and lose the ribbon:

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera, IMX252, 1/1.8" global shutter, 120 fps, C-mount. The MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera, IMX296, 1/2.9" global shutter, M12 lens mount, mono. USB3 keeps the wiring to one short locked cable; GigE reaches 100 m per segment on standard copper cabling, so the camera can sit on the line while the host stays in the cabinet.

Where the camera moves with a fixture, use a drag-chain rated cable:

The LS-CBL-0219 is a 3 m USB3.0 camera cable built for drag-chain use; further lengths and connector styles are under camera cables.

Plan one software difference: OpenCV cannot open a GigE Vision camera directly, for the reasons in why OpenCV VideoCapture cannot open a GigE Vision camera — you connect through the transport layer instead. The wider choice of mounts, formats and sensors is in board-level cameras and in board-level camera selection for embedded vision machines; complete machine cameras are in area scan cameras and the camera finder. The same CSI-versus-USB decision on industrial controllers is laid out in CSI versus USB camera options on an industrial controller.

Prevention checklist

• Enable the camera interface before the first boot of a fresh image, and power-cycle after every change to /boot/config.txt.
• Keep one opener per node: close viewers before starting the application, and release the capture object in scripts that finish.
• Route the ribbon away from moving parts, keep the bend away from the connector, and re-check seating after any transport of the machine.
• Pin the node in code by path, not by index, whenever more than one capture device is connected.
• On legacy stacks, keep bcm2835-v4l2 in /etc/modules so a reboot cannot silently drop the node.

A stream that runs and later stops is a different failure: read a CSI camera that times out after a working period before swapping parts. If the port reports no camera with a second sensor and a verified ribbon, bring the boot log and the exact error line to the contact page and we will pin the failing stage with you.