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.

Hello ShaneCCC,
We are deriving mipi clocks in the same way from this post - VI cannot recv any data form tc358743 - #13 by ShaneCCC

For a 720p60 UYVU (16bits for color) :

Calculation:

Total pixels per frame: 1650 × 750 = 1,237,500 pixels
Bits per pixel for UYVY: 16 bits
1,237,500 × 16 = 19,800,000 bits per frame
Bits per second: 19,800,000 × 60 fps = 1,188,000,000 bits/second

Assuming 2 lanes:
1,188,000,000 ÷ 2 = 594,000,000 bits per lane
CSI clock frequency calculation:
1,188,000,000 ÷ 4 = 297 MHz (remains the same)
So for two-lane configuration:

bits_per_lane: ~594 Mbps
csi_clk_freq: 297 MHz

And that is what I’m getting:
[10122.426932] t194-nvcsi 13e00000.host1x:nvcsi@15a00000: X- NEW2 mipi_clock_rate is : 297000

I noticed it used to be calculated in csi5_fops.c like this:

cil_config.mipi_clock_rate = tegra_chan->subdev[index]->bps_per_lane / 2000;

But bps_per_lane is not defined in the csi5_fops.c - so I have currently hardcoded the value.

Is 297000 correct? And would that be the same for 4 land 1080p60 video?

For PHY mode, I see this :

[10122.426920] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- brick_config.phy_mode : 0
[10122.426924] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- brick_config.lane_polarity[index] : 0
[10122.426927] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- csi5_stream_set_config : before s_data
[10122.426930] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- using hardcode 5940
[10122.426934] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- sizeof(msg) is : 280
[10122.426936] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- valid ports is : 1
[10122.426938] t194-nvcsi 13e00000.host1x:nvcsi@15a00000:    X-- vi port is : 0

Does that look correct?

Thank you.

I confirmed that capturing works by setting the EDID.
00ffffffffffff005262888800888888
1c150103800000780aEE91A3544C9926
0F505400000001010101010101010101
010101010101011d007251d01e206e28
5500c48e2100001e8c0ad08a20e02d10
103e9600138e2100001e000000fc0054
6f73686962612d4832430a20000000FD
003b3d0f2e0f1e0a202020202020014f
020322444f841303021211012021223c
3d3e101f2309070766030c00300080E3
007F8c0ad08a20e02d10103e9600c48e
210000188c0ad08a20e02d10103e9600
138e210000188c0aa01451f01600267c
4300138e210000980000000000000000
00000000000000000000000000000000
00000000000000000000000000000015

The method to insert the EDID is as follows:
v4l2-ctl -d /dev/v4l-subdev2 --set-edid=file=/home/test/edid.txt --fix-edid-checksums

After executing the following command, I verified real-time video playback:
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,framerate=30/1 ! videoconvert ! glimagesink sync=0
After executing the following command, I confirmed that video capturing works successfully.

v4l2-ctl -d /dev/video0 --stream-count=10 --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 : Rec. 709
YCbCr/HSV Encoding: Rec. 709
Quantization : 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: 780.217992 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 1 bytesused: 1843200 ts: 780.227900 delta: 9.908 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 2 bytesused: 1843200 ts: 780.244566 delta: 16.666 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 3 bytesused: 1843200 ts: 780.261232 delta: 16.666 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 4 bytesused: 1843200 ts: 780.277898 delta: 16.666 ms (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 5 bytesused: 1843200 ts: 780.294565 delta: 16.667 ms fps: 60.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 6 bytesused: 1843200 ts: 780.311231 delta: 16.666 ms fps: 60.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq: 7 bytesused: 1843200 ts: 780.327897 delta: 16.666 ms fps: 60.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq: 8 bytesused: 1843200 ts: 780.344563 delta: 16.666 ms fps: 60.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq: 9 bytesused: 1843200 ts: 780.361229 delta: 16.666 ms fps: 60.00 (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq: 10 bytesused: 1843200 ts: 780.377896 delta: 16.667 ms fps: 60.00 (ts-monotonic, ts-src-eof)

Would you like to give it a try as well?
The video0 on the Orin Nano works well, but video1 does not function properly. Could I kindly ask you to check if it works on your side? Additionally, could you verify if there are any mistakes in my setup?

I will share the DTSI and C code that I am currently using. Thank you for your assistance!
tc358743.c.txt (89.8 KB)
tc358743.dtsi.txt (7.6 KB)

@user74491 - very cool you got it working!

For some reason the tc358743.c that nVidia ships does not have the EDID in the code, I think that was the case in JP5.1.2 as well. I had a note to take another look at that, so that’s enabled now.

I changed my tc358743.c and tegra234-p3767-camera-p3768-tc358743.dts files to look more like your files, but it did not capture. I was able to compile your tc358743.c file, but that and my original .dtsi file did not work either. I suspect there is something wrong in my dtsi… I am now attempting to use your .dtsi file.

Did you use the capture-vi.c, vi5_fops.c, or the csi5_fops.c files that I posted above?

First thing I noticed on your code is the num_lanes set to six. The tc358743 we’re using only can use two or four lanes. In the code there are a lot of commented out lines with HD in them to remind me to change those to four lanes if I’m capturing 1080p60. I wasn’t able to get it to autosense and switch from two to four lanes in JetPack 5.1.2 which is what brought us to JP 6.1

Thank you.

That’s unfortunate news.
Yes, I used the method you mentioned above.

If you’d like to try the same method I used, I can provide the steps I followed.
I will send to email.

Hello @ShaneCCC - I’ve been in touch with user74491 regarding their success in using my files to capture video, but I am still timing out trying to capture a frame. The positive here is that it appears these files should work to capture video for me as well on JetPack 6.1

I restarted from scratch and followed their method (primarily swapping a tc348743.dtsi for the imx219.dtsi during build and skipping the convoluted process to bless a dtbo to be used)

I wanted to try another capture however

modprobe rtcpu_debug
echo 1 > /sys/kernel/debug/tracing/tracing_on

Failed because /sys/kernel/debug/tracing does not exist. I tried mounting debugfs and got this message :

mount -t debugfs non /sys/kernel/debug/
mount: /sys/kernel/debug: non already mounted on /sys/kernel/debug.

How do I get kernel tracing working again ?

Thank you.

The answer was to re-install from scratch. Something about the build with 5.15.136-tegra was missing CONFIG_FTRACE, CONFIG_TYPEC_UCSI, and CONFIG_UCSI_CCG. Interestingly, DisplayPort video out wasn’t working either, only noticed after I rebuilt and ended up on 5.15.148-tegra where everything was back in working order.

Here’s the debug, pretty much same as the 6.0 failure…

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-61v3:~# 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: 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-61v3:~# more   /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 40/40   #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/3:3-143     [003] .......  1754.394475: rtcpu_string: tstamp:55768163730 id:0x04010000 str:"VM0 deactivating."
        v4l2-ctl-4512    [004] .......  1756.367945: tegra_channel_open: vi-output, tc358743 9-000f
        v4l2-ctl-4512    [001] .......  1756.399191: tegra_channel_set_power: tc358743 9-000f : 0x1
        v4l2-ctl-4512    [001] .......  1756.399204: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-4512    [001] .......  1756.399208: csi_s_power: enable : 0x1
        v4l2-ctl-4512    [001] .......  1756.400052: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
 vi-output, tc35-4513    [002] .......  1756.409587: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [002] .......  1756.409598: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [002] .......  1756.409601: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [002] .......  1756.409603: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
        v4l2-ctl-4512    [002] .......  1756.409655: tegra_channel_set_stream: enable : 0x1
     kworker/3:3-143     [003] .......  1756.410530: rtcpu_string: tstamp:55831424766 id:0x04010000 str:"VM0 activating."
        v4l2-ctl-4512    [001] .......  1756.415625: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-4512    [001] .......  1756.415630: csi_s_stream: enable : 0x1
        v4l2-ctl-4512    [001] .......  1756.416086: tegra_channel_set_stream: tc358743 9-000f : 0x1
     kworker/3:3-143     [003] .......  1756.466097: rtcpu_vinotify_event: tstamp:55832025035 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1786611905856 data:0x799d580010000000
     kworker/3:3-143     [003] .......  1756.466100: rtcpu_vinotify_event: tstamp:55832025304 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1786611993440 data:0x0000000031000001
     kworker/3:3-143     [003] .......  1756.466101: rtcpu_vinotify_event: tstamp:55832025605 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1786612011488 data:0x799d550010000000
     kworker/3:3-143     [003] .......  1756.466102: rtcpu_vinotify_event: tstamp:55832025854 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:1786612031744 data:0x0000000007020001
     kworker/3:3-143     [003] .......  1756.466102: rtcpu_vinotify_event: tstamp:55832026138 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1786612074112 data:0x0000000031000002
 vi-output, tc35-4514    [001] .......  1759.162646: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
 vi-output, tc35-4513    [004] .......  1759.162906: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [004] .......  1759.162915: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [004] .......  1759.162916: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
 vi-output, tc35-4513    [004] .......  1759.162917: vi_task_submit: class_id:48 ch:0 syncpt_id:26 syncpt_thresh:0 pid:4513 tid:4513
     kworker/3:3-143     [003] .......  1759.214047: rtcpu_vinotify_event: tstamp:55918038022 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1789365245536 data:0x799d580010000000
     kworker/3:3-143     [003] .......  1759.214051: rtcpu_vinotify_event: tstamp:55918038317 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1789365277504 data:0x0000000031000001
     kworker/3:3-143     [003] .......  1759.214053: rtcpu_vinotify_event: tstamp:55918038573 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:1789365313728 data:0x0000000007020001
     kworker/3:3-143     [003] .......  1759.214053: rtcpu_vinotify_event: tstamp:55918038855 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1789365365504 data:0x799d550010000000
     kworker/3:3-143     [003] .......  1759.214054: rtcpu_vinotify_event: tstamp:55918039106 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1789365395072 data:0x0000000031000002
        v4l2-ctl-4512    [000] .......  1759.737817: tegra_channel_close: vi-output, tc358743 9-000f
 vi-output, tc35-4514    [005] .......  1761.690718: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
        v4l2-ctl-4512    [004] .......  1761.691387: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-4512    [004] .......  1761.691390: tegra_channel_set_stream: tc358743 9-000f : 0x0
        v4l2-ctl-4512    [004] .......  1761.692360: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-4512    [004] .......  1761.692363: csi_s_stream: enable : 0x0
        v4l2-ctl-4512    [001] .......  1761.697326: tegra_channel_set_power: tc358743 9-000f : 0x0
        v4l2-ctl-4512    [001] .......  1761.697337: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-4512    [001] .......  1761.697340: csi_s_power: enable : 0x0
     kworker/3:3-143     [003] .......  1766.837935: rtcpu_string: tstamp:56157252615 id:0x04010000 str:"VM0 deactivating."

I’ve started running the following commands to add to my already verbose dmesg -

echo 0xff > /sys/class/video4linux/video0/dev_debug
echo 5 > /sys/module/tc358743/parameters/debug

Here’s the dmesg output in case @ShaneCCC or @JerryChang see anything out of the ordinary.
2025-dmesg_output.txt (129.0 KB)

Thank you for your time.

The log still tell didn’t receive any validate data from the MIPI bus.

So where do I start to debug the MIPI bus issue? What could be causing this issue?

Thank you.

Suppose need to probe the signal to confirm the timing match the MIPI spec.

Thanks

Physically probe the wires?

The tc358743 hardware and source I’m using worked on JetPack 5.1.2 on the Orin. Several modifications were made to the code to work with JetPack 6.0 and now JetPack 6.1. But it still does not capture a frame. Another user in this thread has had success with this set up.

What code deals w/the MIPI bus? What program would be printing something to dmesg or kernel debug if this was working correctly?

Thank you.