What CSI port should my IMX sensor be on in the Jetson device tree?

It depends on which physical CSI connector on your carrier board is connected to your sensor. On Orin NX, CSI ports 0 and 1 are typically on the J12 connector. The csi-port value in your DTS sensor node must match the hardware routing. A mismatch means the VI captures from the wrong port and returns no frames.

IMX sensor on Jetson: I2C detects but no frames — 5 root causes

Q: Why does i2cdetect find my IMX sensor but v4l2 streaming returns no frames?

i2cdetect finds the I2C address of the sensor hardware — this tells you the sensor is powered and responding on the bus. It says nothing about the MIPI capture pipeline. No frames means the V4L2 or Argus capture path isn't configured correctly to receive data from that sensor, even though the sensor is alive.

Q: How do I check if my IMX camera driver is streaming on Jetson?

Use v4l2-ctl --stream-mmap -d /dev/video0 --count=10 after setting the format with --set-fmt-video. Also check dmesg for uncorr_err or tegra-camrtc-capture-vi errors. If dmesg is clean but frames are zero, the sensor may not be sending MIPI data — check that s_stream is being called and MCLK is enabled.

Q: Do IMX sensors on Jetson require Argus or can they use V4L2 directly?

It depends on the driver. NVIDIA-provided IMX drivers (IMX219, IMX477) are designed to work with libargus and nvarguscamerasrc. They can also work with V4L2 directly using v4l2-ctl, but some pipeline features require Argus. Community-ported IMX drivers vary — check whether the driver implements the full V4L2 streaming API.

Q: My IMX driver works in JetPack 5 but not JetPack 6 — what changed?

The tegracam sensor driver framework changed between L4T R35 (JP5) and L4T R36 (JP6). The sensor registration API, MCLK handling, and some subdev operations changed. A JP5 IMX driver usually needs porting before it works in JP6 — it's not a drop-in replacement.

Key Insights

i2cdetect finding your IMX sensor only means it’s powered and on the I2C bus — it says nothing about the MIPI pipeline
Five root causes cover the vast majority of no-frames failures: CSI port mismatch in DTS, sensor mode not loaded, MCLK not active before streaming, pixel format not set, driver is Argus-only
CSI port mismatch is the most common on custom carrier boards — trace the physical MIPI lanes on your schematic before touching the driver
Always set the V4L2 format on both the video device and the subdevice before streaming — setting only one silently falls back to a default that may not work
If nvarguscamerasrc produces frames but v4l2-ctl --stream-mmap doesn’t, you have an Argus-only driver — not a broken board

Why I2C detection doesn’t guarantee frames

When i2cdetect -y 0 shows 0x10 (IMX477) or 0x1a (IMX283), it means the sensor responded to an I2C address query. That’s it. The sensor is powered, the I2C bus is functional, and the chip is there.

The MIPI capture pipeline is a completely separate path. For frames to arrive at the Jetson’s V4L2 or Argus interface, all of the following must be true simultaneously:

The sensor driver’s s_stream(1) call must have completed and started MIPI output
The MCLK must be active and at the correct frequency
The NVCSI must be configured to receive on the correct CSI port and lane count
The VI (Video Input) pipeline must be armed to capture
The pixel format and resolution must match what the sensor is sending

I2C detection confirms only that the sensor is powered. Everything else can still be broken while i2cdetect shows a clean response.

Root cause 1: CSI port mismatch in the device tree

This is the most common cause we see on custom carrier boards. The sensor DTS node specifies csi-port = <0>, but the physical MIPI lanes from the sensor are actually routed to CSI port 2 on the SoC. The VI tries to capture from port 0, which has nothing connected, and returns zero frames.

How to check: pull up your carrier board schematic and trace the MIPI data lanes from the sensor connector to the Jetson SoM pins. Cross-reference the SoM pin assignments with the Orin technical reference manual to determine which CSI port those pins belong to. Then verify the DTS matches.

/* Check this matches your PCB routing */
tegra-camera-platform {
    modules {
        module0 {
            csi_port = "0";    /* This must match physical routing */
            ...
        };
    };
};

On Orin NX and Orin Nano, CSI ports 0 and 1 are on different physical connectors than on AGX Orin. If you’re porting a reference design from one module to another, the CSI port numbers may not transfer.

Root cause 2: sensor mode not loaded

IMX sensors support multiple operating modes — different resolutions, frame rates, and bit depths. The driver needs to load the correct register table for the selected mode before streaming starts.

If the driver defaults to an invalid mode index, or if the mode configuration doesn’t match what v4l2-ctl requested, the sensor’s register state after initialization may leave it in a non-streaming condition. The MIPI transmitter in the sensor won’t start without the correct streaming enable register being set.

Check by looking at what v4l2-ctl reports for the sensor:

# List supported formats and frame sizes
v4l2-ctl --list-formats-ext -d /dev/video0

# Try setting a specific format before streaming
v4l2-ctl -d /dev/video0 \
  --set-fmt-video=width=1920,height=1080,pixelformat=RG10

# Then start streaming
v4l2-ctl --stream-mmap -d /dev/video0 --count=10 -v

If --list-formats-ext returns nothing, the driver didn’t register any valid formats — a driver implementation problem. If it lists formats but streaming still fails, check dmesg during the --stream-mmap call for uncorr_err or mode-switch errors.

Root cause 3: MCLK not active before streaming

The IMX sensor’s internal PLL requires a stable MCLK input before it can lock and produce valid MIPI output. If the driver enables MCLK and then immediately starts MIPI streaming without waiting for PLL lock time, the sensor’s MIPI transmitter isn’t ready and no frames come out.

This is a driver timing issue. The correct sequence is:

Enable MCLK (at correct frequency)
Wait for PLL lock time (usually 1–5 ms, per sensor datasheet)
Write the register initialization sequence
Wait for sensor streaming enable
Signal V4L2 that streaming has started

Drivers that skip the PLL lock delay or start MIPI capture before step 4 completes produce this failure. In dmesg you won’t see errors — the pipeline starts, waits for frames, times out.

Check your driver’s s_stream implementation. Does it call clk_enable(mclk) and then immediately proceed? Add the lock delay if it’s missing.

Root cause 4: wrong pixel format for capture

V4L2 on Jetson requires the capture format to be set before streaming begins. If you call v4l2-ctl --stream-mmap without first setting the format, the driver uses its default — which may not match what the sensor is outputting.

For a RAW10 sensor like the IMX477 sending 4-lane MIPI at 1920x1080, the format must be set to a compatible RAW10 format:

# Set format first
v4l2-ctl -d /dev/video0 \
  --set-fmt-video=width=1920,height=1080,pixelformat=RG10

# Then set subdevice format (important on Orin)
v4l2-ctl -d /dev/v4l-subdev0 \
  --set-subdev-fmt pad=0,width=1920,height=1080,code=0x300f

# Stream
v4l2-ctl --stream-mmap -d /dev/video0 --count=10

On Jetson Orin, you often need to set the format on both the video device and the subdevice. Setting only one and not the other results in format negotiation failure, which may silently fall back to a default that produces no valid frames.

Root cause 5: Argus driver with limited V4L2 support

Some IMX sensor drivers provided by NVIDIA or carrier board vendors are primarily designed for the libargus API, not V4L2 direct capture. They implement the V4L2 subdev interfaces but may have incomplete implementations of the video node streaming path.

In practice, this means v4l2-ctl tools work for device query and format inspection, but actual frame capture requires going through the Argus pipeline:

# Test with nvarguscamerasrc instead of v4l2-ctl
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! \
  'video/x-raw(memory:NVMM),width=1920,height=1080' ! \
  nvvidconv ! xvimagesink -e

If this produces frames but v4l2-ctl --stream-mmap doesn’t, you’re in Argus-only mode. The driver works, but your V4L2 capture path needs to go through nvarguscamerasrc or the libargus API directly.

This is particularly common with IMX283 and IMX412 drivers from third-party BSP vendors.

Quick diagnosis matrix

Symptom	Most likely cause
No `uncorr_err` in dmesg, zero frames, no timeout errors	CSI port mismatch
`uncorr_err` on every frame	MCLK/link frequency wrong (see our uncorr_err post)
Frames work with nvarguscamerasrc but not v4l2-ctl	Argus-only driver
Format query returns no formats	Driver not registering V4L2 formats
Works first time, fails on subsequent runs	MCLK PLL lock timing
Works on JP5, broken on JP6	tegracam API change (needs driver port)

For more on the CSI bring-up stack including DTS structure and sensor driver templates, see our CSI camera driver post. If your sensor produces frames but they come out corrupted, the next step is diagnosing V4L2 uncorr_err on Jetson. If you’re stuck with a specific IMX variant and the standard fixes haven’t moved the needle, book a scoping call.

Sony’s IMX sensor documentation (application notes and register maps) is available through the Sony Semiconductor Solutions partner portal. For the V4L2 media controller API used to configure multi-subdev pipelines, see the Linux kernel media documentation.

Frequently Asked Questions

Why does i2cdetect find my IMX sensor but v4l2 streaming returns no frames?

i2cdetect confirms the sensor responds on the I2C bus — it says nothing about the MIPI capture pipeline. No frames means the capture path isn’t configured correctly to receive data, even though the sensor is powered and alive.

How do I check if my IMX camera driver is streaming on Jetson?

Use v4l2-ctl --stream-mmap -d /dev/video0 --count=10 after setting the format. Also check dmesg for uncorr_err or tegra-camrtc-capture-vi errors during the streaming attempt.

Do IMX sensors on Jetson require Argus or can they use V4L2 directly?

It depends on the driver. NVIDIA-provided IMX drivers work with both libargus and V4L2. Some third-party drivers are Argus-only. If nvarguscamerasrc works but v4l2-ctl --stream-mmap doesn’t, you’re in an Argus-only driver.

What CSI port should my IMX sensor be on in the device tree?

It depends on your carrier board’s physical PCB routing. Trace the MIPI lanes from your sensor to the SoM pins, cross-reference with the Orin TRM to find the CSI port number, then verify the DTS matches. A mismatch is one of the most common no-frames root causes.

My IMX driver works in JetPack 5 but not JetPack 6 — what changed?

The tegracam sensor driver framework changed between L4T R35 and R36. The sensor registration API and MCLK handling both changed. JP5 IMX drivers usually need porting — they’re not drop-in on JP6.

ProventusNova brings up custom CSI cameras on Jetson regularly — IMX sensors, GMSL2 cameras, custom ISPs. If you’re stuck on a no-frames issue, book a scoping call.