@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 …
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
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
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:
Are additional CSI port configurations needed for CSI-E and CSI-G in Xavier NX?
Is there anything specific I should modify in the DTS for these ports?
Is lane_polarity needed for CSI-E/G in custom boards?
Any known limitations or debug recommendations for 4-camera IMX477 setups?
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:
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.
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
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?
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
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:
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?