[Orin Nano Super / JetPack 36.4.7] Dual IMX219 — sensor-id=1 always fails with NvBufSurfaceFromFd Failed / dmabuf_fd -1

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Problem Summary:

We are running a dual IMX219 stereo camera setup on the Orin Nano Super. sensor-id=0 streams perfectly. sensor-id=1 always fails with:

nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
NvBufSurfaceFromFd Failed

Argus successfully enumerates all 5 sensor modes for sensor-id=1 and reports “Producer has connected”, but fails immediately when trying to deliver the first frame.

Diagnostic Results:

Step 1 — Both cameras bind correctly in dmesg:

[3.458496] i2c-mux-gpio bus@0:cam_i2cmux: 2 port mux on 3180000.i2c adapter
[11.315953] imx219 9-0010: tegracam sensor driver:imx219_v2.0.6
[11.332171] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx219 9-0010 bound
[11.362147] imx219 10-0010: tegracam sensor driver:imx219_v2.0.6
[11.380262] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx219 10-0010 bound

No I2C errors, no error -121, no probe failures.

Step 2 — Root cause of original black screen was DTB overlay not applying:

The stock OVERLAYS directive in extlinux.conf is silently ignored on the Orin Nano Super. dmesg showed Overlayfs is disabled. We resolved this by manually merging the overlay into the base DTB using fdtoverlay:

bash

fdtoverlay -i kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb \
    -o kernel_tegra234-p3768-0000+p3767-0005-nv-super-dual-cam.dtb \
    tegra234-p3767-camera-p3768-imx219-dual.dtbo

After this, cam_i2cmux appeared correctly in the live device tree with both i2c@0 and i2c@1.

Step 3 — Device tree graph verified as correctly wired:

/proc/device-tree/tegra-capture-vi/ports/ → port@0 and port@1 both present
port@0 remote-endpoint = 0x376 (nvcsi channel@0 port@1 endpoint@1) ✅
port@1 remote-endpoint = 0x377 (nvcsi channel@1 port@1 endpoint@3) ✅
nvcsi channel@0 port@1 remote-endpoint = 0x379 (VI port@0 endpoint) ✅
nvcsi channel@1 port@1 remote-endpoint = 0x37b (VI port@1 endpoint) ✅

Full bidirectional graph is correctly linked.

Step 4 — vi-mapping confirmed:

nvidia,vi-mapping = <0x00 0x00 0x01 0x00 0x02 0x01 0x03 0x01 0x04 0x00 0x05 0x01>

CSI streams 2,3 map to vi-unit 1. We patched this to force all streams through vi0:

nvidia,vi-mapping = <0x00 0x00 0x01 0x00 0x02 0x00 0x03 0x00 0x04 0x00 0x05 0x00>

sensor-id=1 still fails with identical error after this change.

Step 5 — Tested in shared single Argus session:

bash

gst-launch-1.0 \
  nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM),...' ! fakesink \
  nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM),...' ! fakesink

sensor-id=0 streams for the full duration. sensor-id=1 still hits NvBufSurfaceFromFd Failed within 4 seconds.

Step 6 — Tried merging A+C single-camera overlays instead of dual overlay: Result: num-channels stayed at 1, overlays overwrote each other — not viable.

Step 7 — Upgraded to JetPack 36.4.7: Upgraded nvidia-l4t-kernel, nvidia-l4t-kernel-dtbs, nvidia-l4t-kernel-oot-modules, nvidia-l4t-gstreamer, nvidia-l4t-jetson-io. Rebuilt merged DTB with new base. Same error persists.

What we know for certain:

  • The problem is NOT ribbon cables (verified physically)

  • The problem is NOT I2C/driver binding (both cameras bind correctly)

  • The problem is NOT the device tree graph wiring (fully verified)

  • The problem is NOT vi1 DMA specifically (forcing vi0 doesn’t fix it)

  • The problem is NOT a session conflict (shared session tested)

  • Argus can open a CaptureSession for sensor-id=1 and enumerate modes — it fails only at frame buffer allocation

Question:

Is there a known issue with NvBufSurfaceFromFd failing for the second camera stream on the Orin Nano Super with dual IMX219? Is there a Super-specific camera DTB or BSP patch that correctly initializes the NVMAP/DMA buffer allocator for both VI pipelines simultaneously?

Any guidance appreciated. Happy to provide additional dmesg or device tree output on request.

5

hello a214.shams,

we’ve tested Orin-Nano + two imx219, it’s confirmed CAM0 and CAM1 were working normally.

may I know which camera board it is?
the reference driver works with https://www.raspberrypi.com/products/camera-module-v2/, which a single camera device, you may connect two devices to the camera slots to enable dual camera.

BTW,
here’s see-also forum discussion thread, Topic 319378.
please double check your camera hardware for confirmation.

6

The camera we are using is the IMX219-83 Stereo Binocular Camera, a single PCB with two IMX219 sensors, each connected via its own separate ribbon cable to cam0 and cam1 ports

Product: “IMX219-83 Stereo Binocular Camera Sensor Module 3280x2464 8MP AI Depth Stereo Vision Dual IMX219 for Raspberry Pi 5 RPi CM3/CM3+ Compute Module POE IO Board/Jetson Nano B01”

Purchased from Amazon.

Both sensors are on the same PCB but use separate ribbon cables to the Jetson.

7

hello a214.shams,

please refer to Applications Using V4L2 IOCTL Directly.
please check basic camera functionality by using V4L2 IOCTL.
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

8

We tested both cameras using the exact command you provided:

  • /dev/video0 (right camera, CAM0): command hung with no output and produced a 0KB file — no pixel data at V4L2 level.

  • /dev/video1 (left camera, CAM1): streamed at a steady 21.19 fps for 100 frames, producing a 1.8MB file successfully.

Via Argus the behavior is completely inverted:

  • nvarguscamerasrc sensor-id=0 → right camera (CAM0), live video output

  • nvarguscamerasrc sensor-id=1 → left camera (CAM1), black blank window, fails with:

nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
NvBufSurfaceFromFd Failed

So the right camera (CAM0) works via Argus but produces nothing via V4L2 (/dev/video0). The left camera (CAM1) works via V4L2 (/dev/video1) but fails via Argus (sensor-id=1). The mappings are completely inverted between the two interfaces.

We also noticed that when running nvargus-daemon manually, Argus reports Device 0 (of 1) — only 1 camera device visible to Argus despite both sensors binding correctly in dmesg. Could Argus only enumerating 1 device be the root cause of NvBufSurfaceFromFd failing on sensor-id=1?

9

hello a214.shams,

v4l2 IOCTL simply launch the /dev/videoX node, it’s step for camera device registration to setup a video device node to linux kernel, you may refer to device registration process.
please see-also developer guide for Module Properties section. Argus checks for position property of the module to launch the nodes.

anyways..
it’s device tree to define the hardware configuration,
we’ll need to examine the settings, please execute the commands below to dump device tree into dts formats.
for instance, $ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts