TCA9548 I2C multiplexer for multiple MIPI cameras in the device tree

Your carrier board follows a six-camera reference design: six MIPI camera modules, a bank of CSI-2 receivers, and one host I2C bus that reaches each sensor through a TCA9548A multiplexer. The device tree you started from was written for a different switch — a GPIO-selected mux assumed to sit at 0x77 — so the multiplexer either never binds, or it binds and only cam0 ever streams. The fix is small and mechanical: move the mux node to its real address, describe the six downstream channels with the sensor's 7-bit address inside each, and drive every PWDN and RESET line to the level that powers its module. The sections below give the edits, the control bytes, the bus numbering and the command-line proof for each channel.

Why does one I2C bus need a multiplexer to serve six cameras?

Six identical camera modules answer at the same 7-bit address, so a plain shared bus sees six devices at 0x10 and every sensor read collides; a TCA9548A multiplexer splits one host bus into eight downstream channels and opens them one at a time.

The multiplexer sits between the host SDA/SCL pair and the six downstream pairs. Its control interface answers at one address: parts in this family span 0x70 to 0x77, set by three hardware address pins, and this carrier's part sits at 0x70. A one-byte write to that address opens or closes channels. Video never crosses the switch — each module's CSI-2 lanes run directly to the receiver bank — so the switch carries register access only, and a 100 or 400 kHz I2C bus never becomes a video bottleneck.

Two live guides cover the ground rules: two image sensors with the same I2C address works the clash itself, and multiple camera modules on one host quantifies what a shared bus costs. When two different devices are instead stuck on one fixed address, the multiplexer is the same cure, and troubleshooting I2C multiplexer conflicts with duplicate-address sensors walks that failure mode end to end.

Which device tree changes make the TCA9548 replace the reference GPIO mux?

Three edits do the job: put the mux node under the correct controller with reg = <0x70>, describe channels i2c@0 through i2c@5 with the sensor node at reg = <0x10> inside each, and drive every PWDN and RESET pin to its powered level.

Work the steps in order; each has a command-line proof in the sections that follow.

1. Find the camera bus. Run i2cdetect -l and note the bus wired to the camera connectors — i2c-2 on this wiring. Place the mux node under the I2C controller node that owns that bus, and take the controller node's own address from your SoC's base device tree: the include you copied from belongs to a different SoC family, and its controller node address decodes nothing on your silicon.

2. Move the mux node to its real address. Rename the node to tca9548@70, set reg = <0x70>, and leave the compatible string untouched — the pca954x mux driver binds this chip through the pca9548-family entry the include already carries.

3. Keep the fixed-design properties. The include sets skip_mux_detect and force_bus_start = <CAMERA_I2C_MUX_BUS(0)>. Your channel layout is hard-wired, so keep both lines and the macro behind them.

4. Describe the six channels. Under the mux node, add i2c@0 through i2c@5, each with its channel number in reg, #address-cells = <1>, #size-cells = <0> and i2c-mux,deselect-on-exit. Inside each channel, add the camera module node with reg = <0x10> — the sensor's 7-bit address — plus that camera's reset-gpios entry.

5. Hog the power pins. In the GPIO controller node, add one hog per camera holding PWDN at the level that powers the module, following the include's pattern:

camera-control-output-low {
    gpio-hog;
    output-low;              /* the level that powers the module — measure it once */
    gpios = <CAM0_PWDN 0>;
    label = "cam0-pwdn";
};

6. Build, boot, prove camera 0. Rebuild the DTB, install it, reboot, and run the checks in the next three sections for camera 0 before describing camera 1.

Why does the multiplexer node fail to bind?

A multiplexer that i2cdetect never shows has one of three mismatches: reg points at an address the chip does not answer, the node sits under a controller that does not exist on your silicon, or the rail named in vcc-supply never powers up on your carrier.

Address first. The reference include declares the mux at 0x77; your chip answers at 0x70. The address pins set that value in hardware, so the device tree must match the pins, not the reference: set reg = <0x70> and name the node tca9548@70 so the node address and reg agree. Controller second. An include carried across SoC families brings a controller node address your silicon does not decode, so graft the mux node into the controller node from your own base device tree. Supply third. The include points vcc-supply at a named 1.8 V rail; if your carrier generates that rail under a different regulator, repoint the property, or the multiplexer stays unpowered however correct the addresses are.

The proof is one line: after the fix, i2cdetect -y 2 shows 0x70 on the camera bus. If the mux shows up but sensor probes still fail, work through the camera I2C communication failure and sensor probe errors guide.

How are the downstream buses numbered and mapped to sensor IDs?

With the include's mapping, mux channel n becomes bus 0x1E + n: force_bus_start = <CAMERA_I2C_MUX_BUS(0)> and the macro CAMERA_I2C_MUX_BUS(x) = 0x1E + x put channels 0 through 5 on buses 30 through 35, and the streaming stack reaches camera n as sensor-id n.

0x1E is 30, so channel 0 lands on bus 30 and channel 5 lands on 30 + 5 = bus 35. After boot, the bus list should show one bus per enabled channel child. The sensor-id the streaming stack uses follows the order of the enabled module nodes in the camera group: the module under i2c@0 is sensor-id 0, the module under i2c@1 is sensor-id 1, and so on across all six.

That ordering is also the trap. Testing sensor-id=1 while the only described module sits under i2c@0 stalls the pipeline and looks exactly like a dead camera. A module that answers on the wrong index is its own diagnosis, covered in MIPI camera sensor ID mismatch: diagnose the wrong I2C probe. Bring channels up in order and the index cannot drift.

Which control byte selects each camera channel?

The switch takes one write at 0x70 whose bit n enables channel n, so cameras 0 through 5 answer to 0x01, 0x02, 0x04, 0x08, 0x10 and 0x20; write the byte, confirm the module at 0x10, then stream that sensor-id before opening the next channel.

On the command line, one channel costs two commands:

i2cset -y 2 0x70 0x02   # open channel 1
i2cdetect -y 2          # module answers at 0x10, second module device at 0x64

This module class — an IMX219-class sensor — appears twice on its channel: the sensor at 0x10 and a second device at 0x64. Both belong to the module. A different module type shows its own addresses; take them from that module's data sheet, not from this example.

The stream proof closes the loop, using the camera stack's source element, which selects a camera by index:

gst-launch-1.0 nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! nvvidconv ! xvimagesink

Run it with sensor-id set to 0 through 5, changing only that number. A channel that streams proves the mux node, the child node and the power GPIO for that camera in one shot.

Why does only cam0 stream while every other channel freezes?

When exactly one camera works, the mux and the bus are almost always fine and the dead channel's module is unpowered: its PWDN or RESET pin never reaches the level that releases it, so the sensor answers nothing when its channel opens.

Work the causes in this order.

1. Power pin not driven. Open the failing channel, then measure its PWDN pin. A pin sitting at the unpowered level means the hog is missing or inverted; add it and take the level from the schematic, not from the include's default. GPIO mistakes damage inputs as well as leave cameras dark — the camera GPIO wiring guide covers protection and power-fault triage.

2. reset-gpios missing or on the wrong pin. The driver releases reset through reset-gpios and then reads the sensor's ID register; a wrong pin holds the sensor in reset forever. One hog plus one reset-gpios entry per camera, and the pattern repeats unchanged for cameras 1 through 5.

3. Sensor-id pointing at the wrong channel. The stack index must match the module node's channel; test sensor-id n right after writing byte 2^n to the switch.

4. The module itself. Swap the known-good module onto the failing channel. If it streams, the device tree is right and the module is not — stop editing the tree.

If power measures correctly and the stream still never negotiates, the fault has moved past the mux into clocks or the capture pipeline; MIPI sensor detected but streaming fails picks that thread up.

When is an I2C multiplexer the wrong tool for a six-camera build?

If the host can give every camera its own USB3 or GigE link, drop the multiplexer: separate buses remove the address clash, the PWDN hogs and the module-order dependencies, and the only coupling left is bandwidth and power budgeting.

The multiplexer earns its place when the modules must hang off the SoC's own CSI lanes — smallest modules, one connector bank, one cable set. Where the layout allows a link per station, per-camera buses are simpler to bring up and cheaper to maintain. The budget math for the USB3 case is worked through in multiple USB cameras on one host: bandwidth and power budget, and the module-level trade-offs sit in board level camera selection for embedded vision machines. Synchronizing six cameras from one trigger input is its own wiring task either way; GPIO trigger routing on a serializer board: one input, six cameras shows that pattern.

A 6 MP mono USB3 module on a bare board, with a 1/1.8" rolling-shutter sensor and no lens mount:

A 3.1 MP USB3 module with a 1/1.8" global-shutter sensor, a C-mount lens mount and a 120 fps frame rate:

A 1.6 MP GigE module with a 1/2.9" global-shutter sensor and an M12 lens mount:

Pick the mount to match the station's optics and the shutter to match any motion; the board-level cameras category page filters both, and the camera finder narrows by interface, resolution and sensor format.

If the shared-bus MIPI design stands — tight modules, CSI lanes mandatory — the device tree work above is the one-time cost of admission per carrier revision. Keep the known-good DTB in version control under the revision it was proven on, and the next bring-up starts from proof instead of zero.

For a new multi-camera build, start at the camera configurator with your module count and interface, and the rest of the bus patterns live on the systems topic page.