FireWire camera on Linux: get the kernel driver stack loaded

The 1394 card sits in lspci, the cable is new, and coriander still reports that no digital camera is on the bus. That combination is the classic state of a FireWire camera bring-up on an embedded Linux board, and it rarely means broken hardware. The PCI bus enumerates a controller with no driver at all, while the camera only appears once the kernel's FireWire stack is loaded, the /dev/fw* nodes exist, and your user account may open them.

The checks below run in the order they pay off — five commands, one udev rule, two boot lines. The last section gives the decision: when the module hunt is worth your afternoon, and when retiring the FireWire camera for a GigE or USB3 one is the better engineering trade. It is the same stage-by-stage habit as embedded camera bring up: isolate integration failures, aimed at one forgotten driver layer.

Why does lspci list my 1394 card but coriander finds no camera?

lspci proves the PCIe bus and power are fine, because enumeration reads the card with no driver involved; coriander fails because libdc1394 needs the firewire-ohci stack loaded and an openable /dev/fw* node, and a stock vendor image usually gives you zero of the three conditions.

PCI enumeration reads configuration space straight off the bus, so a card with no driver still lists cleanly. A camera is different: coriander never touches hardware directly. It calls libdc1394, and libdc1394 opens a character device — /dev/fw0, /dev/fw1 — that exists only after firewire-ohci has bound to the card and enumerated the camera. No driver, no node; no node, no camera.

Rank the causes before touching anything. On embedded boards they appear in this order: the modules exist but are not loaded, because vendor images rarely autoload them; the kernel was built without FireWire at all; the nodes exist but are root-only, so coriander dies on permissions; old configuration still points at the legacy raw1394 node; and, last, cabling or bus power. Each has a one-command test in the sections that follow.

Which kernel drivers does a FireWire camera need on Linux?

Two kernel modules run the whole show — firewire-core, the juju stack that creates the /dev/fw* nodes, and firewire-ohci, the driver for any OHCI-compliant controller card — while libdc1394 auto-detects which stack it finds and serves the camera through either.

firewire-core implements the bus protocol and creates one character device per node: fw0 is usually the controller itself, and the camera arrives as fw1. firewire-ohci serves any controller implementing OHCI, the Open Host Controller Interface. Because OHCI is a standard register-level interface, one driver covers every compliant card in a PCIe slot or ExpressCard — there is no vendor driver to hunt for, which is exactly why a missing module is quick to fix.

Older guides say 'load raw1394'. That legacy stack is gone from current kernels, so any recipe built around a raw1394 node applies to a kernel from another era; the fix below targets the current stack. For contrast, our frame grabbers speak GigE, 10GigE, 2.5GigE, CoaXPress, Camera Link, USB3 and XoFLink — FireWire is not among them, which is why this fix lives in the kernel configuration rather than in a card driver.

How do you test the card and camera in five commands?

Five checks, about a minute of typing, tell you which layer is broken: is the card enumerated, is a driver bound to it, are the modules loaded, do the device nodes exist, and what did the kernel log when the camera was plugged in.

1. lspci -nn | grep -i 1394 — the card is on the bus; note its PCI address, for example 01:00.0.
2. lspci -k -s 01:00.0 — a line reading Kernel driver in use: firewire-ohci means the driver is bound; an empty binding points at the module steps below.
3. lsmod | grep firewire — healthy output shows two rows, firewire_ohci and firewire_core; lsmod prints underscores where the module names carry hyphens.
4. ls -l /dev/fw* — no output means no stack; output shows owner, group and mode for the permission check.
5. sudo modprobe firewire-ohci, then ls -l /dev/fw* again — if nodes appear, the kernel had the driver all along and no rebuild is needed. dmesg | tail should now show the camera's ROM being read as the bus announces it.

If step 5 reports the module as not found, go to the kernel question below. If the nodes appear but coriander still balks, the fault is permissions, and the next section fixes it in one file.

Why can you see /dev/fw0 but coriander still fails?

If ls -l /dev/fw* shows root as owner and group, coriander fails on permissions rather than detection: fix it once with a udev rule that grants group video access in mode 0660 — the same arrangement the kernel project's FireWire migration documentation ships for dvgrab and coriander.

Confirm cheaply first: run coriander under sudo once. If the camera appears under sudo and disappears as your normal user, the drivers are perfect and only the file mode is wrong.

# /etc/udev/rules.d/99-firewire-camera.rules
KERNEL=="fw*", GROUP="video", MODE="0660"

Apply it with sudo udevadm control --reload-rules and sudo udevadm trigger, or unplug and reseat the camera so the node is regenerated. For everyday use, add your account to the group with usermod -aG video and log in again; a video group exists on effectively every distribution. The kernel project's own example rules for /dev/fw* grant exactly this — group video access for dvgrab and coriander — and the permission model is identical for USB cameras: Linux camera device permissions: video and media node checks covers the /dev/video* version of the same fight.

Do you have to rebuild the kernel to get FireWire support?

Rebuild only when the module file itself is missing: run find /lib/modules/$(uname -r) -name 'firewire-ohci*' and, if it prints nothing, the vendor kernel was compiled without FireWire support and no modprobe can conjure it.

A hit means the module ships with your running kernel and loading it is the whole fix — no rebuild, no cross-compile, no flashing. No hit means the kernel configuration needs the FireWire core and OHCI driver enabled as modules, then a build and flash through your board vendor's own procedure, because boot-chain details differ between board families and only the vendor documentation matches yours. Build them as modules rather than built-in: a module can be corrected later by copying one file, a built-in driver cannot.

Rebuilt vendor kernels fail for mundane reasons, and a kernel running with modules from a different build is the classic one — camera driver device tree mismatch: diagnose missing DTBs is the same class of mismatch on the device-tree side. For the build environment itself, this embedded Linux kernel, device tree and driver reference maps the pieces before you start.

How do you make the stack load on every boot?

Two lines in /etc/modules-load.d/firewire.conf — firewire-core, then firewire-ohci — make the init system load the stack on every boot, because a module you load by hand disappears at reboot along with the camera it served.

# /etc/modules-load.d/firewire.conf
firewire-core
firewire-ohci

Create the file, reboot, and re-run ls -l /dev/fw*: the nodes should exist before anyone logs in. Initramfs work is only needed when the camera must capture before the root filesystem mounts, which no inspection line does. Prevention is one habit: keep this file and the udev rule in the OS image recipe, so an image update re-applies them instead of silently dropping them, and re-run the five-command test after every update.

How do you verify the camera streams before the machine ships?

The run passes when coriander lists the camera, shows its video modes, and a one-minute capture comes back with zero dropped frames — and the bandwidth arithmetic below tells you before you ship whether the bus speed rating can carry the format you chose.

Work from the plug inward. Reseat and lock both cable screws first: a marginal connection produces either nothing or corrupt frames and costs minutes to rule out, and the locking, strain-relieved construction across the camera cables range is the standard a 1394 pigtail should meet too. Then let coriander open the camera, pick a video mode, and capture for one minute; zero dropped frames is the pass mark. When frames vanish mid-run, the layer-by-layer probe in blank image, no pixels: probe an acquisition pipeline stage by stage applies to 1394 as much as to GigE.

How much bus does your format really need?

The payload decides which speed rating the run needs, and it is arithmetic you can do before the camera even arrives on the bench: multiply image size by frame rate and compare the result with 400 or 800 Mbps.

An IEEE 1394a bus tops out at S400, 400 Mbps; a 1394b bus reaches S800, 800 Mbps. An lspci line announcing an IEEE-1394b controller means the card can run the faster rate when everything on the bus negotiates it. If the bus silently settles at 400 Mbps instead, FireWire camera bus speed: diagnosing a 400 Mbps limit walks that exact fault.

Worked example, monochrome: a 1280 × 960 camera, 1 byte per pixel, 30 fps gives 1,280 × 960 × 1 B × 8 × 30 = 294,912,000 bits/s ≈ 295 Mbps. That is 295 / 400 = 74% of an S400 bus and 295 / 800 = 37% of S800. The mono camera fits S400 with roughly a quarter of the bus left for packet overhead and a second device — a first-order figure, since the formula ignores protocol overhead.

Switch the same sensor to color at 3 bytes per pixel and the payload triples to 885 Mbps, above both ceilings. Decisions: monochrome at this format runs on S400; color at this format needs either a 20 fps cap — 885 × 20 / 30 = 590 Mbps, 74% of an S800 bus — or a narrower window, and no negotiation makes it fit S400.

When is a FireWire camera the wrong interface to keep?

If the camera can be replaced, replace it: the module and udev work above is a one-time fix, but it returns with every board swap and OS-image update, while a GigE or USB3 camera on a standard host controller joins the fleet with no kernel work at all.

Keep FireWire when the camera is irreplaceable — a multi-aperture stereo unit long out of production, or a validated station where re-qualification outweighs an afternoon of kernel work. Then freeze the OS image, ship the two configuration files with it, and re-run the five-command test after every update. Replace it when a current equivalent exists and the fleet is bigger than one bench: the return of this whole exercise at each image update is the recurring price.

A GigE retrofit needs one part on the board side: a dual-port PoE GigE NIC feeds the cameras and powers them over the same cable. For 10GigE cameras the MV-GT2104 is the matching copper NIC, and the MV-GU2204 adds a quad USB3.0 adaptor for cameras that speak USB3 Vision.

Host controllers for the modern retrofit path:

USB3 cameras enumerate through the kernel's UVC class or the vendor SDK, and when one of those comes up blank the diagnosis has the same three layers — driver, node, permission: fixing a UVC camera that is not recognized on an industrial Linux kernel works that case step by step.

Wherever you land, the parts are ordinary: the accessories finder filters host cards and cables by interface and length, the system configurator's accessory step builds the cable and controller list around your camera, and the systems guides collect the rest of the embedded Linux acquisition fixes. If the decision sits on the fence, contact the applications team with the camera model and kernel version.