I have a custom Jetson Nano carrier board (not the official reference carrier) with two physical CSI-2 connectors (CAM0/CAM1) sharing a single I2C bus through a TS3USB30E analog switch, controlled by a GPIO (module pin 130, GPIO06 in the generic SODIMM pin table). Both cameras are Raspberry Pi HQ (IMX477) modules.
Setup — Board A (my current board, the one with the problem):
- L4T R32.7.6 (
# R32 (release), REVISION: 7.6, BOARD: t210ref) - Custom base DTB, compatible =
nvidia,p3542-0000+p3448-0003 - CAM0 alone already works correctly — confirmed with real captures via
nvarguscamerasrc - Confirmed via multimeter that the mux select GPIO (kernel
gpiochip0line 64, corresponds to Tegra padPI.0/NFC_EN) physically switches the TS3USB30E when driven high/low
Setup — Board B (older board, dual-camera works out of the box, used for comparison):
- L4T R32.7.5 (
# R32 (release), REVISION: 7.5, BOARD: t210ref) - Base DTB compatible =
nvidia,p3449-0000-b00+p3448-0002-b00(NVIDIA’s own reference dual-camera carrier lineage) jetson-io.pymenu shows “Camera IMX219 Dual,” “Camera IMX477 Dual,” and “Camera IMX477-A and IMX219-B” as selectable options natively- Its base DTB has
num-channels = <0x2>, a fullchannel@1block, and a workingcam_i2cmuxnode (compatible = "i2c-mux-gpio", withmux-gpiosand two childi2c@0/i2c@1buses each containing animx477@1anode)
Confirmed: the .dtbo overlay files themselves are version-independent — I extracted a completely fresh, untouched L4T R32.7.6 rootfs from NVIDIA’s public download and confirmed tegra210-p3448-all-p3449-0000-camera-imx477-dual.dtbo etc. are already bundled in stock 32.7.6 too, so this isn’t a “32.7.6 dropped the overlay files” issue — the files are present on both versions identically.
Problem:
On Board A, nvcsi’s num-channels = <0x1> with only channel@0, and no cam_i2cmux node at all. Selecting “Camera IMX477 Dual” in jetson-io.py (after patching the overlay’s compatible string so it appears in the menu — it was originally filtered out since it only listed nvidia,p3449-0000-b00+* compat strings) fails with:
FATAL ERROR!
Failed to overlay /boot/dtb/kernel_tegra210-p3448-0003-p3542-0000.dtb
with /boot/tegra210-p3448-all-p3449-0000-camera-imx477-dual.dtbo!
Also found: Board A’s existing imx477@1a sensor node has reset-gpios = <0x5a 0x97 0x0> (GPIO line 151), which conflicts with an existing gpio-hog on the same line (labeled camera-control-output-low/cam1-pwdn, held permanently low). A manual I2C re-probe attempt (mux held high via sysfs) produced:
imx477_power_get: unable to request reset_gpio (-16)
unable to power get
tegra camera driver registration failed
probe of 6-001a failed with error -14
Question:
What’s the correct, safe way to add a second NVCSI channel and a cam_i2cmux node to Board A’s custom base DTB — ideally via a proper .dtsi include at the kernel-source level (I understand NVIDIA’s official approach uses something like tegra210-porg-camera-rbpcv3-dual-imx477.dtsi included into the board’s top-level .dts, rebuilt from full BSP sources against matching R32.7.6 headers), rather than hand-patching the compiled .dtb? Specifically:
- Is there a reference
.dtsifor a P3448-based custom carrier with an I2C-muxed dual-IMX477 setup, or do I need to write thecam_i2cmux/channel@1nodes from scratch? - Since the reference working example (Board B) is on R32.7.5, are there known ABI/structural differences in the NVCSI/VI device tree bindings between R32.7.5 and R32.7.6 kernels (4.9.x) I should watch for when porting this structure forward a point release?
- How should phandle numbering be handled safely when adding these nodes, vs. rebuilding cleanly from source?
- Guidance on resolving the reset-gpios conflict on line 151 between the sensor’s own reset request and the existing
cam1-pwdnhog?
Happy to share the full decompiled .dts output for both boards if useful.