No Camera Available IMX477 Arducam on Xaviernx

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

@ShaneCCC I am using XavierNX Emmc module with jetpack version 5.1.5 with Arducam IMX477 Camera. When I try to stream it shows “No Camera Available”.

I modilfied the dtb file and flashed the SOM. Have a look to my dtb file attached below. And kinldy help me to solve this issue.
tegra194-p3668-0001-p3509-0000.txt (401.9 KB)

Here is the pipeline i used for streaming:
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! “video/x-raw(memory:NVMM),width=1920,height=1080,framerate=60/1,format=NV12” ! nvvidconv ! nvv4l2h264enc bitrate=2000000 control-rate=1 ! h264parse ! rtph264pay ! queue ! udpsink host=192.168.55.100 port=4000 sync=false

Terminal output:

gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! “video/x-raw(memory:NVMM),width=1920,height=1080,framerate=60/1,format=NV12” ! nvvidconv ! nvv4l2h264enc bitrate=2000000 control-rate=1 ! h264parse ! rtph264pay ! queue ! udpsink host=192.168.55.100 port=4000 sync=false
Setting pipeline to PAUSED …
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:780 No cameras available
Redistribute latency…
NvMMLiteOpen : Block : BlockType = 4
===== NvVideo: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
Got EOS from element “pipeline0”.
Execution ended after 0:00:00.027053739
Setting pipeline to NULL …
Freeing pipeline …

Thanks in advance.

2

Check the devname = “imx477 9-001a” in tegra-camera-platform{} is match query by v4l2-ctl --all

3

Here is my tegra-camera-platform device tree entry:

tegra-camera-platform {
    compatible = "nvidia, tegra-camera-platform";
    num_csi_lanes = <0x04>;
    max_lane_speed = <0x16e360>;
    min_bits_per_pixel = <0x0a>;
  	    vi_peak_byte_per_pixel = <0x02>;
    vi_bw_margin_pct = <0x19>;
    max_pixel_rate = <0x3a980>;
    isp_peak_byte_per_pixel = <0x05>;
    isp_bw_margin_pct = <0x19>;

    modules {
	 module0 {
		badge = "imx477_front";
		position = "front";
		orientation = [31 00];

		drivernode0 {
			pcl_id = "v4l2_sensor";
			devname = "imx477 9-001a";
			proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@0/rbpcv3_imx477_a@1a";
		};
	};

	module1 {
		badge = "imx477_rear";
		position = "rear";
		orientation = [31 00];

		drivernode0 {
			pcl_id = "v4l2_sensor";
			devname = "imx477 10-001a";
			proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@1/rbpcv3_imx477_c@1a";
		};
	};

	module2 {
		badge = "imx477_left";
		position = "left";
		orientation = [31 00];

		drivernode0 {
			pcl_id = "v4l2_sensor";
			devname = "imx477 11-001a";
			proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@2/rbpcv3_imx477_e@1a";
		};
	};

	module3 {
		badge = "imx477_right";
		position = "right";
		orientation = [31 00];

		drivernode0 {
			pcl_id = "v4l2_sensor";
			devname = "imx477 12-001a";
			proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@3/rbpcv3_imx477_g@1a";
		};
	};
};

};

Here is the output:

v4l2-ctl --all
Driver Info:
Driver name : tegra-video
Card type : vi-output, 13e10000.host1x:nvcs
Bus info : platform:tegra-capture-vi:0
Driver version : 5.10.216
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name : tegra-camrtc-ca
Model : NVIDIA Tegra Video Input Device
Serial :
Bus info :
Media version : 5.10.216
Hardware revision: 0x00000003 (3)
Driver version : 5.10.216
Interface Info:
ID : 0x03000006
Type : V4L Video
Entity Info:
ID : 0x00000004 (4)
Name : vi-output, 13e10000.host1x:nvcs
Function : V4L2 I/O
Pad 0x01000005 : 0: Sink
Link 0x02000008: from remote pad 0x1000003 of entity ‘13e10000.host1x:nvcsi@15a00000-’: Data, Enabled
Priority: 2
Video input : 0 (Camera 0: no power)
Format Video Capture:
Width/Height : 1920/1080
Pixel Format : ‘RG10’ (10-bit Bayer RGRG/GBGB)
Field : Any
Bytes per Line : 3840
Size Image : 4147200
Colorspace : Default
Transfer Function : Default (maps to Rec. 709)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Full Range)
Flags :

Camera Controls

       sensor_configuration 0x009a2032 (u32)    : min=0 max=4294967295 step=1 default=0 [22] flags=read-only, volatile, has-payload
     sensor_mode_i2c_packet 0x009a2033 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
  sensor_control_i2c_packet 0x009a2034 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
                bypass_mode 0x009a2064 (intmenu): min=0 max=1 default=0 value=0
			0: 0 (0x0)
			1: 1 (0x1)
            override_enable 0x009a2065 (intmenu): min=0 max=1 default=0 value=0
			0: 0 (0x0)
			1: 1 (0x1)
               height_align 0x009a2066 (int)    : min=1 max=16 step=1 default=1 value=1
                 size_align 0x009a2067 (intmenu): min=0 max=2 default=0 value=0
			0: 1 (0x1)
			1: 65536 (0x10000)
			2: 131072 (0x20000)
           write_isp_format 0x009a2068 (int)    : min=1 max=1 step=1 default=1 value=1
   sensor_signal_properties 0x009a2069 (u32)    : min=0 max=4294967295 step=1 default=0 [30][18] flags=read-only, has-payload
    sensor_image_properties 0x009a206a (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
  sensor_control_properties 0x009a206b (u32)    : min=0 max=4294967295 step=1 default=0 [30][36] flags=read-only, has-payload
          sensor_dv_timings 0x009a206c (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
           low_latency_mode 0x009a206d (bool)   : default=0 value=0
           preferred_stride 0x009a206e (int)    : min=0 max=65535 step=1 default=0 value=0
override_capture_timeout_ms 0x009a206f (int)    : min=-1 max=2147483647 step=1 default=2500 value=2500
               sensor_modes 0x009a2082 (int)    : min=0 max=30 step=1 default=30 value=30 flags=read-only

v4l2-ctl --list-devices
NVIDIA Tegra Video Input Device (platform:tegra-camrtc-ca):
/dev/media0

vi-output, 13e10000.host1x:nvcs (platform:tegra-capture-vi:0):
/dev/video0

vi-output, 13e10000.host1x:nvcs (platform:tegra-capture-vi:1):
/dev/video1

Here is the output of i2c-bus:

i2cdetect -l
i2c-3 i2c 3190000.i2c I2C adapter
i2c-10 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-1 i2c c240000.i2c I2C adapter
i2c-101 i2c 15210000.display I2C adapter
i2c-8 i2c 31e0000.i2c I2C adapter
i2c-6 i2c 31c0000.i2c I2C adapter
i2c-4 i2c Tegra BPMP I2C adapter I2C adapter
i2c-2 i2c 3180000.i2c I2C adapter
i2c-0 i2c 3160000.i2c I2C adapter
i2c-9 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-7 i2c c250000.i2c I2C adapter
i2c-5 i2c 31b0000.i2c I2C adapter

cat /sys/class/video4linux/video0/name
vi-output, 13e10000.host1x:nvcs

4

The name should be “imx477 *-001a” instead of below.

5

How can I ensure the IMX477 driver is loaded or triggered properly?

Current Status:

  • I2C device 0x1a is visible on bus 9 (i2cdetect -y -r 9 confirms).
  • DT node is correctly at /proc/device-tree/cam_i2cmux/i2c@0/rbpcv3_imx477_a@1a.
  • DTB devname = "imx477 9-001a" is correctly set.
  • Kernel logs (dmesg | grep imx477) show no probe or registration messages.
7

Kinldy have a look once to my device tree file I shared and let me know the areas where I need to make any changes required.

Thanks.

8

Hello @Sunim_1,

How is everything going?

Would it be possible for you to share the output of the following command?

dmesg | grep imx

Notice we are groping only imx instead of imx477 hoping that maybe a different driver is loading.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

9

Here is the updated terminal output:

i2cdetect -l
i2c-3 i2c 3190000.i2c I2C adapter
i2c-10 i2c i2c-2-mux (chan_id 1) I2C adapter
i2c-1 i2c c240000.i2c I2C adapter
i2c-101 i2c 15210000.display I2C adapter
i2c-8 i2c 31e0000.i2c I2C adapter
i2c-6 i2c 31c0000.i2c I2C adapter
i2c-4 i2c Tegra BPMP I2C adapter I2C adapter
i2c-11 i2c i2c-2-mux (chan_id 2) I2C adapter
i2c-2 i2c 3180000.i2c I2C adapter
i2c-0 i2c 3160000.i2c I2C adapter
i2c-9 i2c i2c-2-mux (chan_id 0) I2C adapter
i2c-7 i2c c250000.i2c I2C adapter
i2c-5 i2c 31b0000.i2c I2C adapter
i2c-12 i2c i2c-2-mux (chan_id 3) I2C adapter

cat /sys/class/video4linux/video*/name
vi-output, imx477 9-001a
vi-output, imx477 10-001a
vi-output, imx477 11-001a
vi-output, imx477 12-001a

ls /dev/video*
/dev/video0 /dev/video1 /dev/video2 /dev/video3

sudo dmesg | grep imx

[ 11.531452] imx477 9-001a: tegracam sensor driver:imx477_v2.0.6
[ 11.836724] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx477 9-001a bound
[ 11.841049] imx477 10-001a: tegracam sensor driver:imx477_v2.0.6
[ 12.143029] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx477 10-001a bound
[ 12.144909] imx477 11-001a: tegracam sensor driver:imx477_v2.0.6
[ 12.445696] imx477 11-001a: imx477_board_setup: invalid sensor model id: 77
[ 12.446554] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx477 11-001a bound
[ 12.454621] imx477 12-001a: tegracam sensor driver:imx477_v2.0.6
[ 12.755430] imx477 12-001a: imx477_board_setup: invalid sensor model id: 77
[ 12.762919] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx477 12-001a bound

I have connected 4 cameras having same sensor imx477 arducam out of which two is working now but rest two cameras is not streaming.

Kinldy help me to debug this issue.
I have attahced the terminal output for help.

Also I have shared my dtb file. Kinldy have a look and help me with some additional changes required.
my_dtb.txt (388.4 KB)

Thanks in advance.

10

Hello @Sunim_1,

Great to hear you managed to get 2 cameras working.

One aspect that catches my eye from the output logs you shared is that sensors on buses 11 and 12 show the following error message:

imx477 11-001a: imx477_board_setup: invalid sensor model id: 77

and

 imx477 12-001a: imx477_board_setup: invalid sensor model id: 77

Which means that the driver is probing the sensor, is being able to interact with it through i2c, it reads the sensor model id from the sensor register table, then it compares the model id agains an expected value, but the value that the sensor returned seems to not match what is expected.

Are you sure you are using 4 of the exact same camera modules?

I would suggest you add some debug messages into the camera driver code so you can print the model id from all sensors and see what the 2 sensors that are working properly show.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

11

I hope you’re doing well. I wanted to clarify my current hardware and test setup to avoid any confusion.

🔹 Objective:
I am testing 4 IMX477 cameras, connected to different CSI ports, on our custom carrier board designed for Jetson Xavier NX.

🔹 Current Status:

  • I am not using any I2C multiplexer (MUX) in this test.
  • All cameras are connected directly to separate CSI lanes and separate I2C buses.
  • I am enabling only one camera at a time in the device tree (by setting the correct status = "okay" and others to "disabled").
  • The goal is to validate each camera independently, before moving to simultaneous multi-camera operation.
12

Hello @Sunim_1,

Thanks for the clarification.

Just so we can better understand the current status.

  1. Have you been able to verify 1 camera at the time successfully ?

  2. If you are experiencing issues with some of the cameras, how would you describe them?

  3. What exact problem is currently blocking you?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

13
  1. Issue Description (Multi-Camera)

I’ve connected four IMX477 cameras, each to its own CSI port:

CSI-A → working

CSI-C → working

CSI-E → connected but returns invalid sensor model id: 77

CSI-G → connected but returns invalid sensor model id: 77

i2cdetect confirms that all 4 sensors respond at address 0x1a, and the drivers bind to them, but cameras on CSI-E and CSI-G fail at model ID read.

Logs:

imx477 11-001a: imx477_board_setup: invalid sensor model id: 77
imx477 12-001a: imx477_board_setup: invalid sensor model id: 77

  1. Current Blocking Issue

The issue seems to occur only on CSI-E and CSI-G. I suspect it could be related to:

CSI interface configuration (e.g., lane swizzling, wrong tegra_sinterface)

Power/reset sequencing

Mux channel mapping or delay

Physical routing on the custom carrier board (currently under verification).

I’ve reviewed the DTS configuration and noticed that my current cam_i2cmux uses only one GPIO in the mux-gpios entry:

cam_i2cmux {
compatible = “i2c-mux-gpio”;
mux-gpios = <0x0d 0x13 0x00>; // Only 1 GPIO line
…
};

Given that I am trying to use 4 I2C channels (i2c@0 to i2c@3) to support 4 camera modules, I suspect that using only one GPIO for mux selection may be insufficient (since 1 GPIO can only select 2 states).

Could this be the root cause for why cameras on i2c@2 and i2c@3 fail to probe correctly with invalid sensor model id: 77?

Help Needed

Could you please help me validate:

  1. Are additional CSI port configurations needed for CSI-E and CSI-G in Xavier NX?
  2. Is there anything specific I should modify in the DTS for these ports?
  3. Is lane_polarity needed for CSI-E/G in custom boards?
  4. Any known limitations or debug recommendations for 4-camera IMX477 setups?
14

Hello @Sunim_1,

I would say the answer to all your questions from 1 through 3, would be that it depends on your custom carrier board design. Since all the device tree does is describing your HW to the firmware running on the board so that it can interact with all the devices successfully.

We would suggest you run the following tests:

  1. Interchange the cameras working on CSi-A and CSI-C with the ones on CSI-E and CSI-G just so you can verify is not the modules. We would not expect this to be the issue, but is always good to rule out possible causes.

  2. Try interacting with the camera modules through i2c-tools manually. For instance, you can try reading the Model Id with i2cget. This will allow you to debug i2c configuration without having to debug the whole DTB at once.

At this time, your biggest issue is i2c communication with 2 of the 4 sensors, therefore, focusing on CSI configuration might not be necessary for now. You need to focus on i2c, the i2cmux config and start by trying to read the registers from the camera modules with manual commands.

Out of experience we know this is a difficult issue to solve, however, with the HW and its documentation it should be a matter of isolating the correct part of the system to debug and focusing on one small part of the problem at the time.

Please keep us posted and don’t hesitate to reach out if you require further assistance.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

15

One GPIO only able support two i2c slave device.
You may need two GPIO for GPIO mux or use i2c mux chip to extend your i2c slave devices.

https://www.kernel.org/doc/Documentation/devicetree/bindings/mux/gpio-mux.txt

16

@ShaneCCC @proventusnova Platform: Jetson Xavier NX (JetPack 5.1.5)
Camera: Sony IMX477 x4
I2C Mux: GPIO-based mux using i2c-mux-gpio (2 GPIOs)
Device Tree: mux-gpios = <0x0d 0x13 0x00 0x0d 0x14 0x00>; with i2c-parent = <0x2b7>;
✅ What’s Working:

All 4 camera nodes are properly defined in the DTS under 4 mux channels.

I2C communication works; confirmed using manual read:

sudo i2cget -y 11 0x1a 0x16 # → 0x04
sudo i2cget -y 11 0x1a 0x17 # → 0x77
sudo i2cget -y 12 0x1a 0x16 # → 0x04
sudo i2cget -y 12 0x1a 0x17 # → 0x77

GPIOs for the mux show proper export and direction:

gpio-320 (PCC.03 |mux) out hi
gpio-321 (PCC.04 |mux) out hi

❌ What’s Failing:

Cameras on i2c@2 and i2c@3 (i.e., mux channels 2 and 3) return:

imx477 11-001a: imx477_board_setup: invalid sensor model id: 77
imx477 12-001a: imx477_board_setup: invalid sensor model id: 77

📌 Tried Fixes Based on Previous Feedback:

Added a second mux GPIO.

Verified sensor ID manually after unbinding driver — both return correct ID 0x0477.

Added i2c-mux-idle-disconnect; in DTS under cam_i2cmux.

Added nvidia,probe-delay-ms = <100>; to each sensor node.

Request for Help:

Even though I2C access is successful and both failing cameras return valid sensor IDs when accessed manually, the kernel driver fails during probe with invalid sensor model id: 77.

Can you help identify:

Why the driver probe fails despite valid manual reads?

Whether any additional timing, synchronization, or mux GPIO toggling behavior must be handled manually?

Any known limitations of i2c-mux-gpio with imx477 on Xavier NX?

I have shared my dts file here. Review once.

dts_file.txt (388.8 KB)

17

Hello @Sunim_1,

Thanks for all the details you provided, they are very helpful.

Quick question.

What is the result from manually reading Model ID from the 2 sensors that do work?

best regards,
Andrew
Embedded Software Engineer at ProventusNova

18

sudo i2cget -y 11 0x1a 0x16

0x04

sudo i2cget -y 11 0x1a 0x17

0x77

sudo i2cget -y 12 0x1a 0x16

0x04

sudo i2cget -y 12 0x1a 0x17

0x77

All 4 sensor gives the result as above.

19

Thanks.

Hmmm yeah, that is interesting.
Because is the same Sensor ID on all camera modules.

Do you happen to have the camera driver source code handy? I would like to take a look at where that error is being printed so we can better understand what is it that the driver wants and what it is actually getting.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

20

You should print those checking in kernel driver to root out why show the invalid id.

21

@proventusnova @ShaneCCC
Following up on our discussion — I found the IMX477 driver at:

kernel/nvidia/drivers/media/i2c/nv_imx477.c

In the imx477_board_setup() function, the error is coming from the model ID probe:

err = imx477_read_reg(s_data, IMX477_MODEL_ID_ADDR_MSB, &reg_val[0]);
err = imx477_read_reg(s_data, IMX477_MODEL_ID_ADDR_LSB, &reg_val[1]);

if (!((reg_val[0] == 0x00) && reg_val[1] == 0x00))
dev_err(dev, “%s: invalid sensor model id: %x%x\n”, func, reg_val[0], reg_val[1]);

What I’ve Observed:

I’m using 4 IMX477 sensors via I2C mux.

All devices are detected: /dev/video0 to /dev/video3.

Two cameras (channels 0 & 1) are working fine.

Two others (channels 2 & 3) report invalid sensor model ID (0x0477), even though I confirmed via i2cget:

For channel 2 (i2c-11)

sudo i2cget -y 11 0x1a 0x16 => 0x04
sudo i2cget -y 11 0x1a 0x17 => 0x77

For channel 3 (i2c-12)

sudo i2cget -y 12 0x1a 0x16 => 0x04
sudo i2cget -y 12 0x1a 0x17 => 0x77

So the correct sensor ID 0x0477 is present, but the driver still reports:

imx477_board_setup: invalid sensor model id: 477

My Question:

It seems the current driver is checking for 0x0000 as the valid sensor ID. Is this expected?

Shouldn’t the driver be checking for 0x0477 instead?

Can you confirm what the correct expected sensor ID is, and whether I need to patch this check in nv_imx477.c?