Hello,
I upgraded system to jetpack 6.2.
When starting raw video stream using the command
v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=100 --verbose just freeze and crash.
I cannot get any logs (the board is not responding and restart)
It is working fine with argus and on jetpack 5.1.3
I tested also imx185 driver, but I get the same result (just to validate that my driver was ok)
Would you have an idea why it is not working ?
Thanks
Try below command. Modify the width/height depend on your sensor mode.
v4l2-ctl --set-fmt-video=width=1920,height=1080, --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video0
Hello, Adding additionnal parameters do the same
Maybe get the log from UART console otherwise don’t know what happened.
Thanks
Hello,
I can see that the function power_on of the driver is called successfully, then after that the board freeze. I added some logs in my driver functions and they are not called
I made additionnal tests:
gstlaunch is working
gst-launch-1.0 -e nvv4l2camerasrc device= /dev/video1 ! 'video/x-raw(memory:NVMM), format=UYVY, width=1936, height=1552,framerate=30/1' ! nvvidconv ! video /x-raw , format =UYVY ! filesink location=output.UYVY
nvargus raw is working
nvargus_nvraw --c 0 --mode 0 --file output --format “raw” --skipframes 150
If I select manually the set mode, I managed to get v4l buffer:
v4l2-ctl --set-ctrl sensor_mode=1 -d 1
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG12 --stream-mmap --set-ctrl=bypass_mode=0 -d /dev/video1
I got a stream, but I also have a lot of frame drops:
So If I sumup:
Thanks
Review the pix_clk_hz in the sensor mode of the device tree.
Hello,
I decrease the deserializer mipi output rate
I increase the deserializer mipi output rate
Using size to calculate the clocks.
The sensor output size is not the final output size. It is the total number of pixels the sensor used to generate the final output size.
For example:
Sensor output size = 2200 Ă— 1125
(actual output size 1920 Ă— 1080)
Frame rate = 30 frames/second
pixel_clk_hz = 2200 Ă— 1125 Ă— 30 = 74250000
I already calculated the correct pixel clock, based on sensor datasheet and sensor output size (including horizontal blanking and vertical blanking)
The issue is happening on all sensors, as soon as the MIPI output rate is 2.5Gbps…
D-PHY?
Boost the clocks to try.
udo 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
Yes using DPHY
Deskew is enabled (I can retrieve image correctly using nvgstcapture so I am sure that deskew is correct).
If I configure serdes_pix_clk_hz = “740000000” this is working, but serdes_pix_clk_hz = “750000000” is crashing.
What I don’t understand, is why the system is crashing. In worst case, we should have a timeout or an error corrupted frame
Yes, usually should show timeout message instead of crash.
Do you have other devkit to verify.
I tested on Jetson 32GB and Jetson 64Gb, same result
Hello, any update on this ?
Maybe try the cil_settle in device tree.
THS settle time of the MIPI lane, in nanoseconds. Calculate the range of acceptable values with the formula:
85 ns + 6Ă—ui < (cil_settletime+6) Ă— (lp_clock_period) < 145 ns + 10Ă—ui
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.