Arducam IMX477 UC-517 REV D3 (B0274), 4 lane configuation on CAM1 of ORIN NX 16GB development kit

Hello,

I want to test a IMX477 UC-517 REV D3 (B0274) in 4 lane configuration on my ORIN NX 16 GB development kit. I have connected the camera device in CAM1. I have written a dt overlay for this. The camera is seen on i2c-10 but v4l2-compliance -d /dev/video0 -s fails.

I have attached 3 files:

  1. The dt overlay that I have created: tegra234-p3767-xxx is dt overlay that I have created.

  2. imx477-4lane-debug.txt contains the output of various commands

  3. imx477_trace_CSICD_VIPort2.txt contains the tracing output.

It is not clear to me whether this camera is supposed to work on in 4lane configuration, or if I have messed up something in the device tree. I am using JP6.2 tegra release is 36.4.3.

I have seen various questions on the forum regarding similar issue or trying this camera on a Nano. Just wasn’t sure if there is a resolution on this.

Hoping for some advice on figuring out what could be the issue.

Thank you,

vangogh

I imx477-4lane-debug.txt (26.7 KB)

imx477_trace_CSICD-VIPort2.txt (123.1 KB)

tegra234-p3767-camera-p3768-imx477-dual-AC-4lane.zip (3.4 KB)

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, it appears that you are trying to test an IMX477 UC517 REV D3 B0274 camera in a 4-lane configuration on your Jetson Orin NX 16 GB development kit. You have written a device tree overlay for this camera and have connected it to the CAM1 port. However, when you run the v4l2-compliance command, it fails.

To troubleshoot this issue, let’s break down the information provided:

  1. Device Tree Overlay: You have created a device tree overlay for the IMX477 camera, which is attached as tegra234-p3767-camera-p3768-imx477-dual-AC-4lane.zip. This overlay is likely used to configure the camera settings and interface.

  2. Camera Detection: The camera is detected on the i2c10 bus, which indicates that the camera is properly connected and recognized by the system.

  3. v4l2-compliance Failure: The v4l2-compliance command fails, which suggests that there is an issue with the camera configuration or the V4L2 driver.

  4. Tracing Output: The tracing output file imx477-trace-CSIC-DVIPort2.txt contains information about the camera’s configuration and the communication between the camera and the system.

To resolve this issue, here are some potential steps you can take:

  1. Verify Device Tree Overlay: Double-check that the device tree overlay is correctly configured for the IMX477 camera in a 4-lane configuration. Ensure that the overlay is properly applied to the system.

  2. Check V4L2 Driver: Verify that the V4L2 driver is properly configured and loaded for the IMX477 camera. You can check the kernel logs to see if there are any errors related to the V4L2 driver.

  3. Camera Configuration: Check the camera configuration settings, such as the pixel clock, data lanes, and format, to ensure that they are correctly set for the IMX477 camera in a 4-lane configuration.

  4. Compare with Known Working Configurations: Compare your device tree overlay and camera configuration with known working configurations for the IMX477 camera on the Jetson Orin NX platform.

  5. Seek Additional Help: If you are still unable to resolve the issue, you may want to seek additional help from the Jetson Orin NX community or NVIDIA support.

In terms of comparing with other similar issues, there have been reports of similar issues with the IMX477 camera on the Jetson Nano platform. However, it’s unclear if these issues are directly related to your specific problem.

To provide more specific advice, I would need more information about the exact error messages and logs you are seeing when running the v4l2-compliance command. Additionally, it would be helpful to know more about the specific camera configuration and settings you are using.

In terms of the camera API matrix, it appears that you are using the V4L2 API to communicate with the camera. The V4L2 API is a standard API for video capture devices, and it is supported by the Jetson Orin NX platform.

In terms of the camera core library interface, it is not clear if you are using this interface or the direct V4L2 interface. The camera core library interface provides a higher-level API for camera control and configuration, while the direct V4L2 interface provides a lower-level API for direct access to the camera hardware.

Overall, it appears that you are experiencing an issue with the camera configuration or the V4L2 driver, and further troubleshooting and debugging are needed to resolve the issue.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

hello vangogh,

please aware that there’s only single camera port to support 4-lane configuration on Orin NX developer kit.
it’s CAM0/CSI-B which support with 2-lane config only; you should connect the camera to CAM1/CSI-C for running with 4-lane config .

Hi Jerry,

Thank you for getting back on this issue.

The camera device is connected to CAM1, to make use of the 4 lane capability on the development kit . All the debug, traces are with respect to CAM1.

Thank you

hello vangogh,

let’s follow the commands below to dump device tree into dts formats for checking.
$ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts

123.dts.txt (324.0 KB)

Hi Jerry,

I have attached the dts created using the command you provided. I am looking through it, but nothing jumps out for me as yet. Will continue investigating, but hoping that you might find something and point out.

Thanks!

hello vangogh,

please aware this never works. you must configure 4-lane at CSI-C.

			i2c@0 {
				rbpcv3_imx477_a@1a {
						num_lanes = "4";
						tegra_sinterface = "serial_b";

here’s one minor issue, please use different position property, it’s used by libargus to distinguish the devices. you may try using rear and front for a two-camera system.

	tegra-camera-platform {
		modules {
			module1 {
				badge = "jakku_rear_RBPCV3";
				position = "front";
				orientation = "1";

				drivernode0 {
					pcl_id = "v4l2_sensor";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@1/rbpcv3_imx477_c@1a";
				};
			};

			module0 {
				badge = "jakku_front_RBPCV3";
				position = "front";
				orientation = "1";

				drivernode0 {
					pcl_id = "v4l2_sensor";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@0/rbpcv3_imx477_a@1a";

please refer to developer guide, Applications Using V4L2 IOCTL Directly.
let’s test camera stream by using V4L2 IOCTL,
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=3840,height=2160,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

you may also try follow the commands below to boost all the VI/CSI/ISP clocks.

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

Hi Jerry,

Yeah, I don’t expect CAM0 to operate at 4 lanes. The hardware issue in the development kit will force it to 2 lanes.

I will update the module positioning. Thank you for pointing that out.

Right now using v4l2 tools to perform this verification. I have boosted the clocks per your instructions. Please see below, a trace for the v4l2 command you suggested. The trace does not look very different from what it was before the clock boost.

Is there a way to test 4 lane configuration without have a sensor device ?

What is the trace trying to tell?

Thanks.

   kworker/3:1-2990    [003] ....... 118467.488775: rtcpu_string: tstamp:3703782699655 id:0x04010000 str:"VM0 activating."
     kworker/3:1-2990    [003] ....... 118467.488778: rtcpu_vinotify_event: tstamp:3703783155184 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118521050476832 data:0x799d580010000000
     kworker/3:1-2990    [003] ....... 118467.488779: rtcpu_vinotify_event: tstamp:3703783155351 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118521050483232 data:0x0000000031000001
     kworker/3:1-2990    [003] ....... 118467.488779: rtcpu_vinotify_event: tstamp:3703783155508 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:118521050486208 data:0x0000000007020001
     kworker/3:1-2990    [003] ....... 118467.488779: rtcpu_vinotify_event: tstamp:3703783155642 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118521050528480 data:0x799d550010000000
     kworker/3:1-2990    [003] ....... 118467.488779: rtcpu_vinotify_event: tstamp:3703783155805 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118521050535008 data:0x0000000031000002
 vi-output, imx4-71514   [001] ....... 118470.097856: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
 vi-output, imx4-71513   [004] ....... 118470.097938: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118470.097948: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118470.097948: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118470.097949: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
     kworker/3:1-2990    [003] ....... 118470.124694: rtcpu_vinotify_event: tstamp:3703865975962 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118523702146432 data:0x799d580010000000
     kworker/3:1-2990    [003] ....... 118470.124695: rtcpu_vinotify_event: tstamp:3703865976124 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118523702152864 data:0x0000000031000001
     kworker/3:1-2990    [003] ....... 118470.124695: rtcpu_vinotify_event: tstamp:3703865976295 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:118523702155840 data:0x0000000007020001
     kworker/3:1-2990    [003] ....... 118470.124695: rtcpu_vinotify_event: tstamp:3703865976448 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118523702203424 data:0x799d550010000000
     kworker/3:1-2990    [003] ....... 118470.124695: rtcpu_vinotify_event: tstamp:3703865976580 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118523702209920 data:0x0000000031000002
 vi-output, imx4-71514   [001] ....... 118472.656838: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
 vi-output, imx4-71513   [004] ....... 118472.656917: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118472.656924: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118472.656925: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118472.656925: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
     kworker/3:1-2990    [003] ....... 118472.700616: rtcpu_vinotify_event: tstamp:3703945754442 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118526261126528 data:0x799d580010000000
     kworker/3:1-2990    [003] ....... 118472.700616: rtcpu_vinotify_event: tstamp:3703945754586 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118526261132896 data:0x0000000031000001
     kworker/3:1-2990    [003] ....... 118472.700617: rtcpu_vinotify_event: tstamp:3703945754748 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:118526261135936 data:0x0000000007020001
     kworker/3:1-2990    [003] ....... 118472.700617: rtcpu_vinotify_event: tstamp:3703945754883 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118526261178208 data:0x799d550010000000
     kworker/3:1-2990    [003] ....... 118472.700617: rtcpu_vinotify_event: tstamp:3703945755037 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:118526261184672 data:0x0000000031000002
 vi-output, imx4-71514   [001] ....... 118475.216850: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
 vi-output, imx4-71513   [004] ....... 118475.216930: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118475.216936: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118475.216937: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513
 vi-output, imx4-71513   [004] ....... 118475.216939: vi_task_submit: class_id:48 ch:0 syncpt_id:35 syncpt_thresh:0 pid:71513 tid:71513

hello vangogh,

it seems VI did not detect start-of-frame and end-of-frame,
let me share VI tracing logs with a success image capture as an example,
here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine.
afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.
for instance,

rtcpu_vinotify_event: tstamp:4058867917 cch:-1 vi:0 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:129874754944 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206674 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:129891804896 data:0x0000000800000000
rtcpu_vinotify_event: tstamp:4059206818 cch:0 vi:0 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:129891808928 data:0x0000000000000001
rtcpu_vinotify_event: tstamp:4059206976 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:1 vi_tstamp:129891815424 data:0x0000000008020001
rtcpu_vinotify_error: tstamp:4060164160 cch:0 vi:0 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:129925171392 data:0x00000000000000a0
rtcpu_vinotify_event: tstamp:4060166846 cch:0 vi:0 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:129923836800 data:0x0000000004370002
rtcpu_vinotify_event: tstamp:4060167015 cch:0 vi:0 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:129923837312 data:0x0000000000000000

Hi Jerry,

If camera is in CAM1 with CSI C/D in use for 4 lane config shouldn’t the VI be vi:1?

Thanks

hello vangogh,

it’s capture channel instead of active VI bricks. you may try to probe the MIPI signaling to ensure there’s output signal from the hardware point-of-view.