Orin fails to capture frame - uncorr_err: request timed out after 2500 ms

Hello, it’s me again. :)

Following up from :
https://forums.developer.nvidia.com/t/arm-smmu-8000000-iommu-unhandled-context-fault-message/285553/
and
https://forums.developer.nvidia.com/t/how-to-enable-tc358743-on-36-3/293215/

Each thread ended with a suggestion to upgrade to the next version of L4T. I am now running JetPack 6.1 and L4T36.4 and still getting the “uncorr_err: request timed out after 2500 ms” error.

Since CAM0 only support 2 lanes, I’m limiting this attempt to capture a single 1280x720 frame.

From the previous thread I was asked to capture:

modprobe rtcpu_debug
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace

root@sthd-61:~# v4l2-ctl -d /dev/video0 --stream-count=1 --stream-mmap --stream-to=frame-720p60.raw --verbose --set-fmt-video=width=1280,height=720,pixelformat=1
VIDIOC_QUERYCAP: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
	Width/Height      : 1280/720
	Pixel Format      : 'UYVY' (UYVY 4:2:2)
	Field             : None
	Bytes per Line    : 2560
	Size Image        : 1843200
	Colorspace        : SMPTE 170M
	Transfer Function : Default (maps to Rec. 709)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Limited Range)
	Flags             :
New timings found
		VIDIOC_REQBUFS returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq:      0 bytesused: 1843200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      0 bytesused: 1843200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 1843200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 1843200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 1843200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
^C
root@sthd-61:~# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 39/39   #P:6
#
#                                _-------=> irqs-off
#                               / _------=> need-resched
#                              | / _-----=> need-resched-lazy
#                              || / _----=> hardirq/softirq
#                              ||| / _---=> preempt-depth
#                              |||| / _--=> preempt-lazy-depth
#                              ||||| / _-=> migrate-disable
#                              |||||| /     delay
#           TASK-PID     CPU#  |||||||  TIMESTAMP  FUNCTION
#              | |         |   |||||||      |         |
     kworker/2:1-3582    [002] .......   795.522139: rtcpu_string: tstamp:25777116585 id:0x04010000 str:"VM0 deactivating."
        v4l2-ctl-3589    [002] .......   808.600948: tegra_channel_open: vi-output, tc358743 9-000f
        v4l2-ctl-3589    [000] .......   808.639007: tegra_channel_set_power: tc358743 9-000f : 0x1
        v4l2-ctl-3589    [000] .......   808.639018: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3589    [000] .......   808.639021: csi_s_power: enable : 0x1
        v4l2-ctl-3589    [000] .......   808.641212: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
 vi-output, tc35-3590    [002] .......   808.652769: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [002] .......   808.652782: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [002] .......   808.652784: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [002] .......   808.652786: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
        v4l2-ctl-3589    [000] .......   808.652828: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-3589    [002] .......   808.656443: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3589    [002] .......   808.656447: csi_s_stream: enable : 0x1
        v4l2-ctl-3589    [002] .......   808.656884: tegra_channel_set_stream: tc358743 9-000f : 0x1
     kworker/2:3-144     [002] .......   808.682143: rtcpu_string: tstamp:26187348110 id:0x04010000 str:"VM0 activating."
     kworker/2:3-144     [002] .......   808.682148: rtcpu_vinotify_event: tstamp:26187959212 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:838002593024 data:0x799e300010000000
     kworker/2:3-144     [002] .......   808.682149: rtcpu_vinotify_event: tstamp:26187959475 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:838002649952 data:0x0000000031000001
     kworker/2:3-144     [002] .......   808.682149: rtcpu_vinotify_event: tstamp:26187959772 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:838002668000 data:0x799e2d0010000000
     kworker/2:3-144     [002] .......   808.682150: rtcpu_vinotify_event: tstamp:26187960024 cch:0 vi:1 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:838002688320 data:0x0000000007020001
     kworker/2:3-144     [002] .......   808.682150: rtcpu_vinotify_event: tstamp:26187960316 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:838002730688 data:0x0000000031000002
 vi-output, tc35-3591    [002] .......   811.178968: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
 vi-output, tc35-3590    [000] .......   811.179149: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [000] .......   811.179164: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [000] .......   811.179166: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
 vi-output, tc35-3590    [000] .......   811.179168: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:3590 tid:3590
     kworker/2:3-144     [002] .......   811.202172: rtcpu_vinotify_event: tstamp:26266836639 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:840528896128 data:0x799e300010000000
     kworker/2:3-144     [002] .......   811.202174: rtcpu_vinotify_event: tstamp:26266836933 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:840528949344 data:0x0000000031000001
     kworker/2:3-144     [002] .......   811.202175: rtcpu_vinotify_event: tstamp:26266837189 cch:0 vi:1 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:840528964352 data:0x0000000007020001
     kworker/2:3-144     [002] .......   811.202176: rtcpu_vinotify_event: tstamp:26266837477 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:840529008160 data:0x799e2d0010000000
     kworker/2:3-144     [002] .......   811.202177: rtcpu_vinotify_event: tstamp:26266837726 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:840529043936 data:0x0000000031000002
        v4l2-ctl-3589    [001] .......   812.045300: tegra_channel_close: vi-output, tc358743 9-000f
 vi-output, tc35-3591    [002] .......   813.706936: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
        v4l2-ctl-3589    [001] .......   813.707124: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-3589    [001] .......   813.707126: tegra_channel_set_stream: tc358743 9-000f : 0x0
        v4l2-ctl-3589    [001] .......   813.708120: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3589    [001] .......   813.708123: csi_s_stream: enable : 0x0
        v4l2-ctl-3589    [001] .......   813.711871: tegra_channel_set_power: tc358743 9-000f : 0x0
        v4l2-ctl-3589    [001] .......   813.711880: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3589    [001] .......   813.711882: csi_s_power: enable : 0x0

We had this capturing frames in 5.1.2 - but I must have missed some of the changes in how things were set up between 5.1.2 and 6.1.

Attached are my dtsi file and custom dmesg output in case they may be useful.
tc35-dtb_file.txt (15.5 KB)
tc35-dmesg.txt (10.6 KB)

Can you help me figure out what I can not capture a frame ?

Thank you.

Some properties should in the mode#{} like below.

mode0 {
						discontinuous_clk = "yes";
						readout_orientation = "90";
						exposure_factor = "1000000";
						mclk_khz = "24000";
						phy_mode = "DPHY";
						default_gain = "16";
						dpcm_enable = "false";
						max_gain_val = "170";
						framerate_factor = "1000000";
						min_hdr_ratio = "1";
						num_lanes = "2";
						max_framerate = "21000000";
						min_gain_val = "16";
						pixel_phase = "rggb";
						mode_type = "bayer";
						pix_clk_hz = "182400000";
						step_gain_val = "1";
						cil_settletime = "0";
						default_exp_time = "2495";
						active_h = "2464";
						max_exp_time = "683709";
						lane_polarity = "6";
						active_w = "3280";
						min_exp_time = "13";
						max_hdr_ratio = "1";
						min_framerate = "2000000";
						mclk_multiplier = "9.33";
						step_exp_time = "1";
						default_framerate = "21000000";
						csi_pixel_bit_depth = "10";
						step_framerate = "1";
						inherent_gain = "1";
						embedded_metadata_height = "2";
						line_length = "3448";
						tegra_sinterface = "serial_b";
						gain_factor = "16";
					};

Where can I find more information on what is expected to be in mode0{} ?

I suspect it’s up to the actual driver how that information is used, isn’t it?

As a test, I created a mode0 and moved phy_mode inside of it:

					i2c@1 {
						status = "okay";
						reg = <0x01>;
						#address-cells = <0x01>;
						#size-cells = <0x00>;

						tc358743_e@0f {
							reset-gpios = <0x07 0xa0 0x00>;
							status = "okay";
[snip]
							ths_trailcnt = <0x02>;
							hstxvregcnt = <0x00>;

							mode0 {
								phy_mode = "DPHY";
							};

							ports {

and when I try to use that overlay, I get a kernel panic on boot.

If I switch back to the one I posted above, with no node0{} - it boots fine, and I can see in lsmod:

 lsmod | grep tc3587
tc358743               49152  1
v4l2_dv_timings        36864  2 tegra_camera,tc358743
v4l2_fwnode            20480  2 tegra_camera,tc358743
v4l2_async             20480  3 v4l2_fwnode,tegra_camera,tc358743
videodev              249856  5 v4l2_async,videobuf2_v4l2,tegra_camera,videobuf2_common,tc358743
cec                    53248  2 tegra_drm,tc358743
mc                     57344  5 videodev,videobuf2_v4l2,tegra_camera,videobuf2_common,tc358743

So I dug further and moved what I thought should be in the mode0{} -

                        tc358743_e@0f {
                            status = "okay";
                            compatible = "toshiba,tc358743";
                            reg = <0x0f>;
                            devnode = "video1";

                            /* Physical dimensions of sensor */
                            physical_w = "4.713";
                            physical_h = "3.494";
                            /* Sensor Model */
                            sensor_model ="tc358743";
                            use_sensor_mode_id = "true";
                            reset-gpios = <&gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;

                            refclk_hz = <27000000>;  // refclk_hz -> regclk
                            refclk = <27000000>;  // refclk_hz -> regclk

                            ddc5v_delay = <2>;
                            lineinitcnt = <0xe80>;
                            lptxtimecnt = <0x003>;
                            tclk_headercnt = <0x1403>;
                            tclk_trailcnt = <0x00>;
                            ths_headercnt = <0x0103>;
                            twakeup = <0x4882>;
                            tclk_postcnt = <0x008>;
                            ths_trailcnt = <0x02>;
                            hstxvregcnt = <0x0>;

                            mode0 {
                                active_w = "1280";
                                active_h = "720";
                                pix_clk_hz = "74250000";
                                //HD num_lanes = "4";
                                num_lanes = "2";
                                tegra_sinterface = "serial_c";	// just a guess from imx477
                                phy_mode = "DPHY";
                                discontinuous_clk = "yes";
                                lane_polarity = "6";
                                enable_hdcp = "false";
                                cil_settletime = "0";
                            };

(full file here - et-dtb2-file.txt (15.7 KB) )

This compiles and doesn’t cause a kernel panic. But the camera doesn’t show up after modprobe and /dev/video0 is not created. Running dmesg | grep tc358743 returns nothing.

tc358743               49152  0
v4l2_dv_timings        36864  2 tegra_camera,tc358743
v4l2_fwnode            20480  2 tegra_camera,tc358743
v4l2_async             20480  3 v4l2_fwnode,tegra_camera,tc358743
videodev              249856  5 v4l2_async,videobuf2_v4l2,tegra_camera,videobuf2_common,tc358743
cec                    53248  2 tegra_drm,tc358743
mc                     57344  5 videodev,videobuf2_v4l2,tegra_camera,videobuf2_common,tc358743

So - how do I figure out where the problem is ? The .dtsi or my tc358743.c file or ???

Thank you.

Looks like it’s different with general sensor driver.
Reference to tc358840 look like don’t need to report the mode#{} for this kind of device.
Check the setting in csi5_stream_set_config() in csi5_fops.c like phy mode and mipi clocks.

This is my topic.
tegra234-camera-rbpcv2-tc358743.dtsi.txt (15.2 KB)
tegra234-p3767-camera-p3768-tc358743-dual.dts.txt (1.8 KB)
tegra234-p3768-0000+p3767-0000-dynamic.dts.txt (735 Bytes)
tegra234-p3768-camera-rbpcv2-tc358743.dtsi.txt (1.3 KB)

My situation is different from yours. Please check if I did anything wrong.

@user74491 Your problem is device tree have problem to probe to generate the video#, however this topic is driver and device tree probe successfully but can’t get video frame. Suppose you can ask @anomad to share the driver and device tree to you to reference.

I used anomad’s dtsi file, but the result was the same.

I remember using the tc358840 files from JetPack 5.1.2 as a reference I’m working from the tc358743.c that worked in JetPack 5.1.2 ( in this thread Orin Nano and tc358743 capture issue ) , and then re-adapted to better align with the changes that appear in the tc358743.c from public_sources.tbz2 for JetPack 6.1 since it used some different functions and variables.

The very messy combination of of those two drivers is here :
JP661-tc358743.c.txt (89.5 KB)

Thank you.

@anomad
Dear anomd
I was able to resolve the refclk error with the code you gave.
But the results are different for you and me.
When I run ‘v4l2-ctl --query-dv-timings -d /dev/video0’, I get 'VIDIOC_QUERY_DV_TIMINGS: failed: Link has been severed
'.

If there is anything I did wrong, please let me know.
Thank you.

@user74491 - there are a few more files that need to be updated from what nVidia ships in JetPack 6.1 -

capture-vi.c.txt (45.4 KB)
vi5_fops.c.txt (28.0 KB)
csi5_fops.c.txt (18.2 KB)

Back up the current files, and replace them with these. There is a lot more debugging information being printed as well

dmesg | grep jc-

Let me know when you get that running and if you spot something I overlooked.

Thank you.