We are trying to bring up image sensors with an Orin NX that we have already functioning with a Xavier NX.
We are running Jetpack 5.1.1 and are using very similar configurations to our functioning Xavier NX setup.
According to the kernel trace, streaming seems to start fine, but eventually begins complaining about CHANSEL_NOMATCH for data type 0x12. 0x12 is our sensor’s embedded row ID. We have successfully retrieved data from the embedded rows on our Xavier NX setup and the rows have the same ID there.
I am confused why streaming seems to start fine but then fails because of a digital test pattern row. We are using identical camera sensor settings to our Xavier NX setup which is functional, so I don’t know why the digital test pattern rows are causing problems.
I can stream using v4l2-ctl fine for long periods. The kernel trace looks normal while streaming using that tool. The kernel trace only reports CHANSEL_NOMATCH when trying to stream via Argus.
I have also encountered the attached Argus error.
argusfail (4.1 KB)
What’s the output size(resolution)?
Please try boost the clocks to try.
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
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
The output size is 3840 x 2160 with CSI pixel depth of 12 bits and dynamic depth of 16. We have deskew enabled.
With clocks boosted, the kernel trace looks even worse. I have attached logs from argus and the kernel for both a boosted and normal clock run.
normalclocks-kernel (119.8 KB)
normalclocks-argus (5.2 KB)
boostedclocks-kernel (161.4 KB)
boostedclocks-argus (2.9 KB)
Could you verify by v4l2-ctl to confirm if able to streaming continuously?
v4l2-ctl --set-fmt-video=width=3840,height=2160,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap
Yes as I said in my second post I am able to stream continuously using v4l2-ctl and the logged raw outputs look fine.
We are running L4T R35.3.1 JP 5.1.1.
could you please apply Apr25_libnvscf.7z to try
Apr25_libnvscf.7z (1.6 MB)
.
it’s based-on JP-5.1.1/l4t-r35.3.1 release version, please update /usr/lib/aarch64-linux-gnu/tegra/libnvscf.so for confirmation.
thanks
1 Like
I have attached logs with that binary replaced.
It looks like the kernel trace ends immediately after receiving the start of the first frame now.
normalclocks-kernel (7.5 KB)
normalclocks-argus (4.0 KB)
boostedclocks-kernel (25.2 MB)
boostedclocks-argus (3.6 KB)
Error NotInitialized: V4L2Device not powered on also looks scary, but I am not sure what that means.
I also re-confirmed that I can stream using v4l2, and it reports frames coming through fine, but I also now see these errors:
v4l2-ctl --stream-mmap --stream-count=100 --set-ctrl bypass_mode=0 -d /dev/video0
[ 19.867420] bwmgr API not supported
[ 19.867702] bwmgr req failed for 8
[ 19.867952] misc tegra_camera_ctrl: tegra_camera_isomgr_request: ICC failed to reserve 73242 KBps
[ 19.868254] misc tegra_camera_ctrl: tegra_camera_update_isobw: failed to reserve 73242 KBps with isomgr
<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<< 28.82 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 28.82 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 28.82 fps
<<<<<<<<<<<<
Could you restore the lib and add delay after programing the streaming on sensor REG to try.
Thanks
1 Like
I tried adding a 10ms delay and a 200ms delay to the end of the start streaming mode table. 10ms didn’t seem to allow any frames through in the trace.
With 200ms, it looks like we may get a few more frames in the kernel trace before we start seeing CHANSEL_NOMATCH again.
The argus log seems to still have a good number of concerning errors, but I am not sure how to interpret them or know if they are actually serious.
delay-argus (6.8 KB)
delay-kernel (140.7 KB)
Could you share your driver here.
Thanks
Hi Shane,
I have attached our driver files.
ox08b40_mode_tbls.h (30.1 KB)
ox08b40.c (24.9 KB)
ox08b40.h (6.8 KB)
tegra234-ox08b40.dtsi (15.9 KB)
Could you try adjust the data output rate > 1.5Gbps.
Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:
Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)
Hi Shane,
How should I re-configure for an output data rate >= 1.5 Gbps?
Our current pix_clk_hz is set like this:
/*
* Nvidia gives lots of ways to calculate this, be it by using SCLK, using raw
* h * w * fps, or by just using the total MIPI lane speeds. We tried using SCLK
* originally as it is also what the exposure calcs will be based on, which is
* convenient, but it is too slow and causes garbage image data to be received.
* Instead, we use total MIPI speed:
* 2300 Mbps * 2 lanes / 12 bits per pixel = 383333333 Hz = ~383 MHz
*/
pix_clk_hz = "383333333";
which, if we have done this correctly, specifies a data rate above 1.5 Gbps.
Was this previously configured in the tegra-camera-platform section? It was my understanding from reading the most recent documentation that the values previously in that section like max_lane_speed are deprecated as they are no longer mentioned in the camera driver documentation.
I tried bumping pix_clk_hz to 800000000 just to see what would happen and had the same results as before.
Please help to try attached libs agian.
Please confirm v4l2-ctl able streaming continuously first.
libnvscf_deskew.so (7.4 MB)
1 Like
Hi Shane,
I gave that lib a try in place of /usr/lib/aarch64-linux-gnu/tegra/libnvscf.so
I confirmed that I can stream from both of our sensors using v4l2 fine. I attached kernel trace logs when streaming from v4l2.
v4l2-kernel (320.4 KB)
We don’t seem to make it any further with streaming via Argus. I have attached argus and kernel trace logs.
Just to confirm I am trying to initiate a stream correctly, I have been using
gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! "video/x-raw(memory:NVMM),width=3840,height=2160" ! nvvidconv ! fakesink silent=false -v
and adjusting sensor-id= to 0 or 1 to select our two sensors. I also uploaded the logs from the gstreamer command.
newlib-argus (6.4 KB)
newlib-kernel (570.9 KB)
newlib-gstreamer (3.5 KB)
Apologies I realized I streamed from sensor 0 which is still set up with pix_clk_hz of 800000000. Attached are logs from sensor 1 which is set to pix_clk_hz of 383333333. The logs seem similar.
cam1-newlib-argus (4.2 KB)
cam1-newlib-gstreamer (6.1 KB)
cam1-newlib-kernel (250.1 KB)