IMX283 Driver Bring-up on Xavier NX (JetPack 5.1.5) – Issues with tegracam framework and I2C detection

Robotics & Edge Computing Jetson Systems Jetson Xavier NX
1

Hi NVIDIA Team,

I am working on bringing up a custom camera sensor (IMX283) on Xavier NX using JetPack 5.1.5.

I am using the IMX185 driver as a reference, but I am facing issues with the tegracam framework and sensor initialization.

Below are my setup details:

Platform:

  • Module: Xavier NX
  • JetPack Version: 5.1.5
  • Kernel Version: 5.10

Sensor Details:

  • Sensor: IMX283
  • Interface: CSI

Issues:

  1. Sensor is not detected in i2cdetect initially.

    • After manually toggling PWDN GPIO, the sensor appears at address 0x1A.

  2. tegracam framework mismatch:

    • IMX185 reference driver does not seem compatible with JetPack 5.1.5.
    • Facing issues in tegracam_device structure and registration.

  3. Probe function behavior:

    • Driver loads but sensor initialization is inconsistent.

What I have tried:

  • Updated device tree with correct GPIO and MCLK configuration
  • Compared IMX185 driver with other drivers like IMX219
  • Verified power sequence manually

Questions:

  1. Is there a recommended reference driver for JetPack 5.1.5?
  2. Has the tegracam framework changed significantly from JetPack 4.x?
  3. Is there updated documentation for camera driver development for JP5?
  4. Any guidance on proper PWDN and MCLK handling?

Any help or guidance would be greatly appreciated.

Thanks,
Afzal

2

Hello @Sunim_1

Could you please share your device tree and driver.c files? Also the dmesg log?

Regards!
Eduardo Salazar
Embedded SW Engineer at RidgeRun

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

4

hello Sunim_1,

please check Release Notes for section [4. Implementation Details], you must create a device tree overlay (DTB overlay or .dtbo) file to register the camera module.
was this driver validated on JP-4 public release? you may refer to Camera Driver Porting for a high-level overview of changes.

5

Hello,

I am working on a custom carrier board for Jetson Xavier NX (JetPack 5.1.5 / Kernel 5.10).

Hardware Configuration

  • SoC: Jetson Xavier NX

  • Sensor: Sony IMX283 (4-lane MIPI CSI-2)

  • Carrier board: Custom

  • CSI layout:

    • 2 data lanes connected to CSI0 (serial_a, port-index 0)

    • 2 data lanes connected to CSI1 (serial_b, port-index 1)

As per earlier guidance, I configured:

  • port-index = <0>

  • bus-width = <4>

to allow the NVCSI hardware to aggregate 2+2 lanes into a single 4-lane stream.

Current Status

  1. I2C Detection

    sudo i2cdetect -r -y 9

    Sensor address (0x1a) shows UU, meaning the driver has successfully probed the device.

  2. MCLK Status
    With extperiph1 enabled in DT:

    sudo cat /sys/kernel/debug/clk/clk_summary | grep extperiph1

    Output:

    extperiph1   1 1 0   25500000   25000000

    So MCLK is correctly running at 25 MHz.

  3. Sensor Mode Configuration

    active_w = "3840";
active_h = "2160";
line_length = "3960";
num_lanes = "4";
pix_clk_hz = "287500000";

    (line_length >= active_w, as per documentation)

  4. Streaming Attempt

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

    Result:

    VIDIOC_STREAMON returned -1 (Remote I/O error)

Observations

  • Probe succeeds.

  • MCLK is stable at 25 MHz.

  • I2C works during initialization.

  • STREAMON fails immediately with Remote I/O error.

  • This suggests NVCSI is unable to lock onto the incoming MIPI stream.

Cam-reset gpio is set as out hi PP.04 but as I used imx477 over there is set as out lo

My Questions

  1. Is splitting a 4-lane sensor as 2 lanes on CSI0 + 2 lanes on CSI1 fully supported on Xavier NX production silicon?

  2. Are there additional NVCSI or VI configuration requirements when using this 2+2 split configuration?

  3. Are there known limitations regarding lane ordering or brick pairing when aggregating CSI0 and CSI1?

  4. Is there a recommended way to verify that NVCSI aggregation is correctly configured (debugfs, tracepoints, etc.)?

Any guidance on how to further debug NVCSI lock failures would be greatly appreciated.

Thank you.

6

hello Sunim_1,

let me have confirmation, it’s actually single 4-lane camera connected to 1st CSI brick which utilize CSI-A/B, right?
although we don’t have 4-lane reference camera on Xavier NX, we’ve tested 4-lane camera for AGX Xavier series, it should works ideally.
please see-also below..
$public_sources/kernel_src/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-imx185-a00.dtsi

7

The sensor is detected on I2C and the media pipeline appears correct, but video capture fails with VI timeout errors.

I would appreciate help identifying the cause.

i2cdetect -y -r 9

 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00: – – – – – – – – – – – – –
10: – – – – – – – – – – UU – – – – –

Media Pipeline:

Media device information
driver tegra-camrtc-ca
model NVIDIA Tegra Video Input Device

entity 1: 13e10000.host1x:nvcsi@15a00000
entity 4: imx283 9-001a
entity 6: vi-output, imx283 9-001a

Sensor format:
SRGGB10_1X10 2736x1538

v4l2-ctl --list-formats-ext -d /dev/video0

Size: Discrete 2736x1538
Interval: 0.033s (30 fps)

Capture Test:
v4l2-ctl --stream-mmap -d /dev/video0 --stream-count=10

capture fails.

Kernel logs:

sudo dmesg | tail -30

[ 345.288992] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 592.871280] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 592.871546] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 592.871854] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 592.872019] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 592.872251] (NULL device *): vi_capture_control_message: NULL VI channel received

I am new in camera bringup, kindly help me to know the exact root cause of this and help me to fix this issue.

Thanks in advance.

8

hello Sunim_1,

let’s check the board schematic, you may refer to Jetson Xavier NX Product Design Guide to review the [Figure 9-2. CSI Connection Options].
you should use 4-lane camera with CSI0_D0/D1 and CSI1_D0/D1, whereas only CSI0 clock is used.

please also note that, Xavier NX series parse the device trees from jakku folders.
for instance, $public_sources/kernel_src/hardware/nvidia/platform/t19x/jakku/kernel-dts/…
you may see-also tegra194-camera-jakku-rbpcv2-imx219.dtsi for device tree of 2-lane camera, IMX219.
here’s commands to dump device tree into dts formats, please upload the results for cross-check.
$ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts

please also double check Sensor Pixel Clock, which must be set correctly to avoid potential issues.
FYI, I usually using the sensor CSI lane output rate for evaluation.
such as.. pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel

besides.. you may also try the commands to boost all the VI/CSI/ISP clocks for testing.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
9

Please find the below device tree file which is currently in use.

current_dts_file.txt (374.1 KB)

dmesg_log.txt (10.1 KB)

Here’s the cmd I run which throughs dmegs error:
v4l2-ctl --stream-mmap --stream-count=10 -d /dev/video0

Kindly go through my device tree file mode settings for double check of pix_clk_hz and line_length.

10

hello Sunim_1,

let me re-cap the code snippets as below, it looks you’ve configure IMX283 as 2-lane,

	rbpcv3_imx283_a@1a {
		compatible = "nvidia,imx283";
			mode0 {
				num_lanes = [32 00];
				tegra_sinterface = "serial_a";

			ports {
				port@0 {
					endpoint {
						port-index = <0x00>;
						bus-width = <0x02>;

please revise the port bindings (imx283/nvcsi/tegra-capture-vi) if you’ve 4-lane configuration.

11

Here is the revised device tree file:

devicetree.txt (374.1 KB)

12

hello Sunim_1,

it looks good, could you please review pix_clk_hz, and also line_length
for instance,
I usually using sensor CSI lane output rate to evaluate clock rate,
pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
and.. per developer guide, line_length value must be greater than or equal to active_w.

13

Hello,

When I start streaming using v4l2-ctl, frames are not captured and I see the following error in dmesg:

tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 16384

Hardware Setup

  • Platform: Jetson Xavier NX

  • JetPack version: 5.1.5

  • Sensor: IMX283

  • Interface: MIPI CSI

  • Lanes: 4

  • Data rate per lane: 720 Mbps

  • Pixel format: RAW10

  • Resolution: 3840 × 2160

Device Tree Mode Parameters

active_w = "3840";
active_h = "2160";
line_length = "4400";
pix_clk_hz = "72000000";
csi_pixel_bit_depth = "10";
num_lanes = "4";
embedded_metadata_height = "0";

Streaming Command

v4l2-ctl --stream-mmap -d /dev/video0

dmesg Output

tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 16384

CSI Signal Verification

Using an oscilloscope:

  • MIPI clock lane enters HS mode when streaming starts

  • Data lanes show burst activity

  • Activity envelope visible around ~16 kHz

Question

Could you please help verify whether my pix_clk_hz and line_length values are correct for this configuration?

Also, are there any other parameters in the device-tree that could cause err_data 16384 and frame discard?

Please let me know if additional logs (trace, register dumps, etc.) would help.

trace_log.txt (5.1 KB)

I have also shared trace log.

Thank you.

14

hello Sunim_1,

it’s VI to dequeue a frame, but discarding a frame due to the status without success.
you may dig into camrtc-capture.h for the actual capture status it’s reported.

besides.. did you have frames obtained by VI engine continuously?
if yes.. you may give it a quick try to omit the frame_err for testing.
for instance,

@@ -552,7 +552,7 @@ static void vi5_capture_dequeue(struct tegra_channel *chan,
                                        "err_data %d\n",
                                        descr->status.frame_id, descr->status.flags,
                                        descr->status.err_data);
-                               frame_err = true;
+                               // frame_err = true;
15

Thanks for this info. I tried this and here is the output.

v4l2-ctl --stream-mmap -d /dev/video0
<<<<<<<<<<<<<< 12.60 fps
<<<<<<<<<<<<< 12.82 fps
<<<<<<<<<<<<<<<<<<<< 15.21 fps
<<<<<<<<<<<<<<<<<<<<< 16.66 fps
<<<<<<<<<<<<<<<< 16.54 fps
<<<<<<<<<< 15.34 fps
<<<<<<<<<<<<< 15.12 fps
<<<<<<<<<<<<< 14.86 fps
<<<<<<<<<<<<<< 14.77 fps
<<<<<<<<<<<<<<<< 14.90 fps
<<<<<<<<< 14.30 fps
<<<<<<<<<<<<<<<< 14.45 fps
<<<<<<<<<<<<<<< 14.49 fps

I tried to see dump data and looks like its nil
Here is the output:

hexdump -C frame.raw | head
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…|
*
00fd2000

Dmesg log:

[ 111.186955] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 16384
[ 111.234427] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 16384
[ 111.281882] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 16384

It still through error in the dmesg.

FYI,
I am using an external crystal clk always on of 25Mhz.

mclk_khz = 25000
Active w: 3840
Active h: 2160
fps: 21
pixel_clk_hz: 72000000
line length: 4400

Kindly help me with correct values for line length and pixel_clk_hz.
Please let me know if additional info is required.

Thank you.

16

hello Sunim_1,

discarding frame will reported per above workaround, since it ignore the following frame_err only.
BTW, it also looks abnormal of your frame-id, which should be increasing instead keeping at zero.

17

Hi Jerry,

Thank you for the response and the observation regarding the frame-id staying at zero.

Based on your comment, it seems the CSI pipeline might not be detecting frame boundaries correctly, which could indicate a timing mismatch between the sensor configuration and the VI/CSI settings.

Currently my configuration is:

  • Sensor: Sony IMX283

  • Resolution: 3840x2160

  • MCLK: 25 MHz (external crystal always on)

  • pixel_clk_hz: 287500000

  • line_length: 3960

  • fps: ~21

Observed behavior:

  • v4l2-ctl --stream-mmap shows streaming at ~14–16 fps

  • RAW frame dump contains only 0x00 values

  • dmesg shows:
    tegra-capture-vi: corr_err: discarding frame 0

  • frame-id appears to remain at 0

From your comment, I suspect the issue may be related to sensor timing or CSI configuration.

Could you please provide a hint on which parameter is most likely incorrect in this situation?

For example, should I revisit:

  • pixel_clk_hz calculation

  • line_length / frame_length values

  • CSI data rate configuration

  • sensor streaming registers

If there is a recommended way to verify whether the NVCSI block is receiving valid packets from the sensor, that would also help narrow down the issue.

Thank you for your guidance.