Jetpack-4.6 tx2 : v4l2-ctl --stream-mmap needs nvarguscamerasrc to succeed

Hello nvcsi and vi experts

The problem described below is new in jetpack-4.6. I never observed i t with jetpack-4.5.1 nor jetpack-4.3.1 or even jetpack-3.3.

In summary ‘with jetpack-4.6 on tx2, v4l2-ctl --stream-mmap’ needs to be preceded by ‘gst-launch-1.0 nvarguscamerasrc’ to work successfully.

After a fresh boot, the following v4l2-ctl video acquisition fails :

$ v4l2-ctl -d /dev/video1 -p 68.300
Frame rate set to 68.300 fps
$ v4l2-ctl -d /dev/video1 --stream-mmap=3 --stream-count=256 --set-fmt-video=width=2464,height=2056,pixelformat=GREY
[ 1619.417324] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 1619.424090] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel

However, if thereafter I run a nvargus-based gstreamer pipeline, it works flawlessly :

+ gst-launch-1.0 -vv nvarguscamerasrc do-timestamp=true awblock=true aelock=true sensor-id=1 '!' 'video/x-raw(memory:NVMM),width=2464,height=2056,format=NV12,framerate=30/1' '!' nvvidconv '!' nvv4l2h264enc '!' h264parse '!' qtmux '!' filesink location=test_color_1080p.mp4 -e
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/nvv4l2h264enc:nvv4l2h264enc0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)NULL, level=(string)NULL, width=(int)2464, height=(int)2056, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, chroma-site=(string)mpeg2
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)NULL, level=(string)NULL, width=(int)2464, height=(int)2056, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, chroma-site=(string)mpeg2
Redistribute latency...
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
/GstPipeline:pipeline0/nvv4l2h264enc:nvv4l2h264enc0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)2464, height=(int)2056, format=(string)NV12, framerate=(fraction)30/1
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 1936 x 1096 FR = 59,999999 fps Duration = 16666667 ; Analog Gain range min 1,000000, max 251,188705; Exposure Range min 16000, max 165770000;

GST_ARGUS: 2464 x 2056 FR = 68,300002 fps Duration = 14641288 ; Analog Gain range min 1,000000, max 251,188705; Exposure Range min 16000, max 165770000;

GST_ARGUS: Running with following settings:
   Camera index = 1
   Camera mode  = 1
   Output Stream W = 2464 H = 2056
   seconds to Run    = 0
   Frame Rate = 68,300002
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
H264: Profile = 66, Level = 0
/GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, profile=(string)constrained-baseline, level=(string)5.1, width=(int)2464, height=(int)2056, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, chroma-site=(string)mpeg2, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, codec_data=(buffer)01424033ffe1000c67424033965401340207f2a001000468ce3c80
/GstPipeline:pipeline0/GstQTMux:qtmux0.GstQTMuxPad:video_0: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, profile=(string)constrained-baseline, level=(string)5.1, width=(int)2464, height=(int)2056, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, chroma-site=(string)mpeg2, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, codec_data=(buffer)01424033ffe1000c67424033965401340207f2a001000468ce3c80
/GstPipeline:pipeline0/GstQTMux:qtmux0.GstPad:src: caps = video/quicktime, variant=(string)apple
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/quicktime, variant=(string)apple
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...

And thereafter, the first v4l-ctl-based command works also perfectly :

$ v4l2-ctl -d /dev/video1 -p 68.300
Frame rate set to 68.300 fps
$ v4l2-ctl -d /dev/video1 --stream-mmap=3 --stream-count=256 --set-fmt-video=width=2464,height=2056,pixelformat=GREY
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 69.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 68.50 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 68.33 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I have two sensors on that board, and the other one does not require nvargus usage to work, but that sensor is also not able to deliver a framerate as high as the one used above. Also on the /dev/video1 sensor, the problem does not happen when working with a lower framesize/framerate combination.

Of course I would like the first command to run perfectly the first time without needing first to run a nvargus pipeline.

I already tried to boost the nvcsi/vi and isp clock before running the command, but that does not help.

The sensor driver itself is unaware that it is called by nvarguscamerasrc or by v4l2-ctl and behave always the same. What do the nvcsi and vi drivers do when called from argus, that is not done when called by v4l2-ctl, and that is also not reverted when called by v4l2-ctl ?

Thanks in advance

Check if boost those clocks help on it.

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 |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

Hello ShaneCCC,

I already had tested boosting the clocks, and I have retested it now after your reply. I must unfortunately confirm that it does not solve the problem. Only running the ‘nvargus’ pipeline makes the ‘v4l2-ctl’ command work.

I believe the root cause could be the sensor REG configure cause.
You can compare the configure before and after argus run to figure it out.

Actually, the sensor is powered off after each streaming use, and powered on and reset before each new streaming use, so it is difficult to believe that sensor config could be retained after argus use. But nvcsi, vi or peripheral CPU is perhaps not powered down nor reset between uses.

Is there a way to dump the configuration of nvcsi, vi and related peripheral processor ?

No, actually the NVCSI/VI was reset for each streaming on/off

To be sure, I have retested with the same hardware (except using another TX2 to avoid the tedious reflash) with jetpack-4.5.1. The sensor driver is the same as in my jetpack-4.6 port, and the sensor part of the device-tree too. With that setup, the v4l2-ctl --stream-mmap command works perfectly after the reboot. There is thus a regression in jetpack-4.6 that must be looked at, but where ?

You can check the csi/vi driver at …/kernel/nvidia/drivers/platform/tegra/camera/

I had already done that quicly, and found no blatant change there. Is there some other driver or processor involved ?

Suppose most VI driver are there.
Have a check the trace log for the failed case to check if any clue.

Here are some excerpts from trace :
During first (failing) v4l2-ctl command :

     kworker/3:2-1151  [003] ....   834.828267: rtcpu_vinotify_event: tstamp:26437644091 tag:CHANSEL_PXL_SOF channel:0x00 frame:2 vi_tstamp:26437643546 data:0x00000001
     kworker/3:2-1151  [003] ....   834.828276: rtcpu_vinotify_event: tstamp:26437644338 tag:ATOMP_FS channel:0x00 frame:2 vi_tstamp:26437643553 data:0x00000000
     kworker/3:2-1151  [003] ....   834.828282: rtcpu_vinotify_event: tstamp:26437647198 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:2 vi_tstamp:26437646796 data:0x08000000
     kworker/3:2-1151  [003] ....   834.828291: rtcpu_vinotify_event: tstamp:26438001576 tag:ATOMP_FRAME_TRUNCATED channel:0x00 frame:2 vi_tstamp:26438000409 data:0x00000000
     kworker/3:2-1151  [003] ....   834.828297: rtcpu_vinotify_event: tstamp:26438003359 tag:CHANSEL_FAULT_FE channel:0x04 frame:2 vi_tstamp:26438002212 data:0x00000001
     kworker/3:2-1151  [003] ....   834.828303: rtcpu_vinotify_event: tstamp:26438004463 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:2 vi_tstamp:26438002212 data:0x08000000
     kworker/3:2-1151  [003] ....   834.828308: rtcpu_vinotify_event: tstamp:26438005482 tag:ATOMP_FE channel:0x00 frame:2 vi_tstamp:26438002215 data:0x00000000

During argus pipeline :

     kworker/3:2-1151  [003] ....  1312.735563: rtcpu_vinotify_event: tstamp:41372270692 tag:ISPBUF_FS channel:0x00 frame:1 vi_tstamp:41372270279 data:0x00000000
     kworker/3:2-1151  [003] ....  1312.735565: rtcpu_vinotify_event: tstamp:41372273087 tag:CHANSEL_PXL_SOF channel:0x00 frame:1 vi_tstamp:41372272683 data:0x00000001
     kworker/3:2-1151  [003] ....  1312.735567: rtcpu_vinotify_event: tstamp:41372722473 tag:CHANSEL_PXL_EOF channel:0x00 frame:1 vi_tstamp:41372721754 data:0x08070002
     kworker/3:2-1151  [003] ....  1312.735568: rtcpu_vinotify_event: tstamp:41372722666 tag:ISPBUF_FE channel:0x00 frame:1 vi_tstamp:41372721778 data:0x00000000

And during second (successful) v4l2-ctl command :

     kworker/3:2-1151  [003] ....  1457.203519: rtcpu_vinotify_event: tstamp:45886455895 tag:CHANSEL_PXL_SOF channel:0x00 frame:2 vi_tstamp:45886455345 data:0x00000001
     kworker/3:2-1151  [003] ....  1457.203524: rtcpu_vinotify_event: tstamp:45886456141 tag:ATOMP_FS channel:0x00 frame:2 vi_tstamp:45886455352 data:0x00000000
     kworker/3:2-1151  [003] ....  1457.203525: rtcpu_vinotify_event: tstamp:45886458891 tag:CHANSEL_LOAD_FRAMED channel:0x04 frame:2 vi_tstamp:45886458489 data:0x08000000
     kworker/3:2-1151  [003] ....  1457.203526: rtcpu_vinotify_event: tstamp:45886905118 tag:CHANSEL_PXL_EOF channel:0x00 frame:2 vi_tstamp:45886904415 data:0x08070002
     kworker/3:2-1151  [003] ....  1457.203527: rtcpu_vinotify_event: tstamp:45886905270 tag:ATOMP_FE channel:0x00 frame:2 vi_tstamp:45886904440 data:0x00000000

Does the rtcpu keep a configuration it has received when the argus process was active ?

Boost the clocks and system to try.

sudo nvpmodel -m 0
sudo jetson_clocks

nvpmodel crashes my board :

root@tx2-jp46:~# nvpmodel -m 0
[ 1712.167338] Unable to handle kernel read from unreadable memory at virtual address 00000138

I try to find why, but I don’t find the entry point in linux matching the user level write to /sys/devices/system/cpu/cpu1/online.

Also jetson_clocks seems not to be installed on my board. Which package contains it ?

All release have jetson_clocks
Could you try original kernel Image if have the same problem?

Oops sorry. jetson_clocks is available. I do not understand why I did not find it the first time. Probably I thought it had to be in /home/nvidia :(

After running ‘jetson_clocks’, without boosting the clocks, and without calling ‘nvpmodel -m 0’, the ‘v4l2-ctl --stream-mmap*’ command now works. without the need for running argus first. What’s the explanation/conclusion ?

Your case is the memory(emc) clocks too low cause it.

With jetpack-4.5.1, that worked perfectly without needing jetson_clocks. Is there a patch for the nvidia common v4l2 camera rtcpu/nvcsi/vi driver to fix that for jetpack-4.6 ?

Could you check the value of /sys/kernel/debug/bpmp/debug/clk/emc/rate any different for J4.5 and J4.6

On both jetpack-4.5.1 and jetpack-4.6, the value of /sys/kernel/debug/bpmp/debug/clk/emc/rate changes often, even in standby mode.

With the jetpack-4.5.1 TX2, I get the following values :

 408000000
1866000000

With the jetpack-4.6 TX2 , I get the following values :

 408000000
 665600000
1600000000

I also looked at the results of ‘sudo jetson_clocks --show’

With jetpack-4.5.1 :

nvidia@tx2-jp451:~$ sudo jetson_clocks --show
SOC family:tegra186  Machine:quill
Online CPUs: 0-5
cpu0: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=2035200 IdleStates: C1=1 c7=1
cpu1: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=345600 IdleStates: C1=1 c6=1 c7=1
cpu2: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=345600 IdleStates: C1=1 c6=1 c7=1
cpu3: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=1420800 IdleStates: C1=1 c7=1
cpu4: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=960000 IdleStates: C1=1 c7=1
cpu5: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=652800 IdleStates: C1=1 c7=1
GPU MinFreq=114750000 MaxFreq=1300500000 CurrentFreq=114750000
EMC MinFreq=40800000 MaxFreq=1866000000 CurrentFreq=408000000 FreqOverride=0
Can't access Fan!
NV Power Mode: MAXN
nvidia@tx2-jp451:~$

With jetpack-4.6 :

nvidia@tx2-jp46:~$ sudo jetson_clocks --show
SOC family:tegra186  Machine:quill
Online CPUs: 0,3-5
cpu0: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=2035200 IdleStates: C1=1 c7=1
cpu1: Online=0 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=345600 IdleStates: C1=1 c6=1 c7=1
cpu2: Online=0 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=345600 IdleStates: C1=1 c6=1 c7=1
cpu3: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=960000 IdleStates: C1=1 c7=1
cpu4: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=1113600 IdleStates: C1=1 c7=1
cpu5: Online=1 Governor=schedutil MinFreq=345600 MaxFreq=2035200 CurrentFreq=960000 IdleStates: C1=1 c7=1
GPU MinFreq=114750000 MaxFreq=1122000000 CurrentFreq=114750000
EMC MinFreq=40800000 MaxFreq=1600000000 CurrentFreq=408000000 FreqOverride=0
Can't access Fan!
NV Power Mode: MAXP_CORE_ARM
nvidia@tx2-jp46:~$

With both jetpacks, the CurrentFreq of cpu0-5 changes frequently.

I notice a difference in EMC MaxFreq and in ‘NV Power Mode’ between jetpack-4.5.1 and jetpack-4.6, but those value don’t change in jetpack-4.6 between the failing run of ‘v4l2-ctl --stream-mmap’ and the successful run of the same command.

I also tried to find a value changed permanently in the result of ‘sudo jetson_clocks --show’ after having run the argus-based pipeline on jetpack-4.6 but found none.

Interesting, maybe check increase the pix_clk_hz or add serdes_pix_clk_hz and assign a value much bigger than pix_clk_hz to acquire more bandwidth to try.