GMSL Camera Fail to Open Argus_Camera

Dear Shane,

I had tried to upgrade driver to R32 and enabled nvcsi and vi but system is hang up.

Does it failed to boot to system?
Looks like your device tree have problem cause it.

It can’t boot to system.
Device tree only changed port0 at vi@15c10000 to enable.

We fix the problem.
Could you please help to explain what’s the meaning for those values? How to set it?
src-csi-port, dst-csi-port, serdes-csi-link, streams

imx390_a@1b {
	endpoint {
		vc-id = <0x0>;
		port-index = <0x0>;
		bus-width = <0x2>;
		remote-endpoint = <0x2e>;
		linux,phandle = <0x99>;
		phandle = <0x99>;
gmsl-link {
	src-csi-port = [62 00];
	dst-csi-port = [61 00];
	serdes-csi-link = [61 00];
	csi-mode = "1x4";
	st-vc = <0x0>;
	vc-id = <0x0>;
	num-lanes = <0x2>;
	streams = "ued-u1", "raw12";

You should be able to get the information from the sensor driver imx390.c

May I know how to check virtual channel has been enabled correctly?

Media device information
------------------------
driver          tegra194-vi5
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  0.0.0

Device topology
- entity 1: ar0231 2-0070 (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:SGRBG12_1X12/1928x1208 field:none colorspace:srgb]
                -> "15a00000.nvcsi--2":0 [ENABLED]

- entity 3: 15a00000.nvcsi--2 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
        pad0: Sink
                <- "ar0231 2-0070":0 [ENABLED]
        pad1: Source
                -> "vi-output, ar0231 2-0070":0 [ENABLED]

- entity 6: vi-output, ar0231 2-0070 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "15a00000.nvcsi--2":1 [ENABLED]

- entity 18: ar0231 2-0071 (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev2
        pad0: Source
                [fmt:SGRBG12_1X12/1928x1208 field:none colorspace:srgb]
                -> "15a00000.nvcsi--1":0 [ENABLED]

- entity 20: 15a00000.nvcsi--1 (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev3
        pad0: Sink
                <- "ar0231 2-0071":0 [ENABLED]
        pad1: Source
                -> "vi-output, ar0231 2-0071":0 [ENABLED]

- entity 23: vi-output, ar0231 2-0071 (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
        pad0: Sink
                <- "15a00000.nvcsi--1":1 [ENABLED]

What I check is to confirm the port-index and bus-width for port0 and port1 is the same but have different vc-id. You may print this message from the kernel nvcsi/vi driver to confirm it.

port@0 {
                                        reg = <0>;
                                        imx390_vi_in0: endpoint {
                                                vc-id = <0>;
                                                port-index = <0>;
                                                bus-width = <2>;
                                                remote-endpoint = <&imx390_csi_out0>;
                                        };
                                };
                                port@1 {
                                        reg = <1>;
                                        imx390_vi_in1: endpoint {
                                                vc-id = <1>;
                                                port-index = <0>;
                                                bus-width = <2>;
                                                remote-endpoint = <&imx390_csi_out1>;
                                        };

Virtual channel looks opening successfully, but image preview is freeze after about 30sec.

Please refer to attachment for detail log.
trace.txt (5.59 MB)
Log.txt (10.1 KB)

Could you try v4l2-ctl to capture each of them to confirm it.

attachment

Not sure if this is what you want.
v4l2_log0.txt (38.2 KB)
v4l2_log1.txt (53.2 KB)

Tried continues running and it stopped as below:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.02 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.01 fps
<<<<<<<<<<<<<<<<<<<

dmesg is

[ 2500.119999] [RCE] Configuring VI GoS.
[ 2500.120026] [RCE] VM GOS[#0] addr=0xe4900000
[ 2500.120031] [RCE] VM GOS[#1] addr=0xe4901000
[ 2500.120036] [RCE] VM GOS[#2] addr=0xe4902000
[ 2500.120040] [RCE] VM GOS[#3] addr=0xe4903000
[ 2500.120044] [RCE] VM GOS[#4] addr=0xe4904000
[ 2500.120047] [RCE] VM GOS[#5] addr=0xe4905000
[ 2500.120052] [RCE] vi5_hwinit: firmware CL2018101701 protocol version 2.2
[ 2500.120059] [RCE] VI GOS[#0] set to VM GOS[4] base 0xe4904000
[ 2574.396540] tegra194-vi5 15c10000.vi: no reply from camera processor
[ 2574.396671] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[ 2574.396804] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[ 2574.399069] t194-nvcsi 15a00000.nvcsi: csi5_stop_streaming: csi_pt=0, st_id=0, vc_id=0, pg_mode=0x0
[ 2574.399076] t194-nvcsi 15a00000.nvcsi: csi5_stream_close: stream_id=0, csi_port=0
[ 2574.399084] t194-nvcsi 15a00000.nvcsi: csi5_start_streaming: csi_pt=0, st_id=0, vc_id=0, pg_mode=0x0
[ 2574.399088] t194-nvcsi 15a00000.nvcsi: csi5_stream_set_config: stream_id=0, csi_port=0
[ 2574.399093] t194-nvcsi 15a00000.nvcsi: csi5_stream_open: stream_id=0, csi_port=0
[ 2574.399400] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[ 2574.428581] [RCE] Configuring VI GoS.
[ 2574.428588] [RCE] VM GOS[#0] addr=0xe4900000
[ 2574.428594] [RCE] VM GOS[#1] addr=0xe4901000
[ 2574.428623] [RCE] VM GOS[#2] addr=0xe4902000
[ 2574.428631] [RCE] VM GOS[#3] addr=0xe4903000
[ 2574.428635] [RCE] VM GOS[#4] addr=0xe4904000
[ 2574.428638] [RCE] VM GOS[#5] addr=0xe4905000
[ 2576.956430] tegra194-vi5 15c10000.vi: no reply from camera processor
[ 2576.956564] tegra194-vi5 15c10000.vi: uncorr_err: request timed out after 2500 ms
[ 2576.956693] tegra194-vi5 15c10000.vi: err_rec: attempting to reset the capture channel
[ 2576.958432] t194-nvcsi 15a00000.nvcsi: csi5_stop_streaming: csi_pt=0, st_id=0, vc_id=0, pg_mode=0x0
[ 2576.958439] t194-nvcsi 15a00000.nvcsi: csi5_stream_close: stream_id=0, csi_port=0
[ 2576.958448] t194-nvcsi 15a00000.nvcsi: csi5_start_streaming: csi_pt=0, st_id=0, vc_id=0, pg_mode=0x0
[ 2576.958452] t194-nvcsi 15a00000.nvcsi: csi5_stream_set_config: stream_id=0, csi_port=0
[ 2576.958456] t194-nvcsi 15a00000.nvcsi: csi5_stream_open: stream_id=0, csi_port=0
[ 2576.958767] tegra194-vi5 15c10000.vi: err_rec: successfully reset the capture channel
[ 2577.008424] [RCE] Configuring VI GoS.
[ 2577.008432] [RCE] VM GOS[#0] addr=0xe4900000
[ 2577.008439] [RCE] VM GOS[#1] addr=0xe4901000
[ 2577.008447] [RCE] VM GOS[#2] addr=0xe4902000
[ 2577.008451] [RCE] VM GOS[#3] addr=0xe4903000
[ 2577.008455] [RCE] VM GOS[#4] addr=0xe4904000
[ 2577.008483] [RCE] VM GOS[#5] addr=0xe4905000

Looks like the GMSL setting is incorrect. From the trace shouldn’t have two FS package for one frame.

kworker/4:0-36    [004] ....   214.718094: rtcpu_vinotify_event: tstamp:7011655470 tag:FS channel:0x00 frame:1 vi_tstamp:7011610678 data:0x00000010
     kworker/4:0-36    [004] ....   214.718097: rtcpu_vinotify_event: tstamp:7011655619 tag:FS channel:0x01 frame:1 vi_tstamp:7011610700 data:0x00000010
     kworker/4:0-36    [004] ....   214.718098: rtcpu_vinotify_event: tstamp:7011655749 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:7011610700 data:0x00000000
     kworker/4:0-36    [004] ....   214.718132: rtcpu_vinotify_error: tstamp:7011778289 tag:CHANSEL_NOMATCH channel:0x01 frame:1 vi_tstamp:7011777072 data:0x00000589
     kworker/4:0-36    [004] ....   214.718140: rtcpu_vinotify_event: tstamp:7011968534 tag:CHANSEL_NOMATCH channel:0x01 frame:1 vi_tstamp:7011777072 data:0x00000589
     kworker/4:0-36    [004] ....   214.718141: rtcpu_vinotify_event: tstamp:7011968660 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:7011777401 data:0x00000001
     kworker/4:0-36    [004] ....   214.718142: rtcpu_vinotify_event: tstamp:7011968822 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:5333545280 data:0x08020001
     kworker/4:0-36    [004] ....   214.718144: rtcpu_vinotify_event: tstamp:7012638319 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:7012625489 data:0x04b70002
     kworker/4:0-36    [004] ....   214.718145: rtcpu_vinotify_event: tstamp:7012638463 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:7012625503 data:0x00000000

When i enabled trace, the image capture duration will be hang up shorten than not enable trace. Do you know why?

As you mentioned two of FS packet has been received, but channel is different (channel 00 and 01).

I only enable two of camera links, does it related to that?

Confirmed with vendor here are the frame sequences.

SOF(0), SOF(1), SOF(2), SOF(3), SOL(0), V(camera0line0), EOL(0), SOL(1), V(camera1line0), EOL(1), SOL(2), V(camera2line0), EOL(2), SOL(3), V( camera3 line0), EOL(3), SOL(0), V(camera0line1), … EOF(0), EOF(1), EOF(2), EOF(3).

If you only capture one camera at a time shouldn’t send two FS to the bus.
I think it could be better to make sure only one can capture well that move on to enable the VC.

One camera without VC already have been tested overnight and working well.

Could you please help to check what’s the meaning from the log?

NvCaptureStatusErrorDecode Capture-Error: CSIMUX_FRAME (0x00000002)
CsimuxFrameError_Regular : 0x000000a0
    Stream ID                [ 2: 0]: 0
        
    VPR state from fuse block    [ 3]: 0
        
    Frame end (FE)              [ 5]: 1
        A frame end has been found on a regular mode stream.
    FS_FAULT                    [ 7]: 1
        A FS packet was found for a virtual channel that was already in frame.An errored FE packet was injected before FS was allowed through.
    Binary VC number [3:2]   [27:26]: 0
        To get full binary VC number, user need to concatenate VC[3:2] and VC[1:0] together.

Have you try boost the nvcs/vi 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
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate
echo ${max_rate} > /sys/kernel/debug/bpmp/debug/clk/vi/rate
echo ${max_rate} > /sys/kernel/debug/bpmp/debug/clk/isp/rate
echo ${max_rate} > /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

yes, clocks has been boost.

Could you cat the rate to confirm it been set as max.
The log means Frame Stare package in the middle of frame before a Frame End package received.