Hello
I’m developing camera system with Orinx NX on custom board.
At this time, I’m developing 3 channel camera on DSER_A1.
Only about 15% of captures are successful with the 3-channel camera.
I captured success case log and fail case log.
Could you please review both?
Thank you and best regard!
I attached our system and logs
capture_fail_3ch_dser2_07_19.txt (186.3 KB)
capture_success_3ch_dser2_07_19.txt (308.6 KB)
it’s following-up of… Topic 298271: Orin NX is not responding to camera input.
hello suengpyo.shin,
may I double confirm the Jetpack release version you’re now working with.
is this only happened with DSER_A1 (CSI-2/3)? can you seen the same with DSER_A0 (CSI-0/1)?
Hello Jerry Chang
I did not test DSER_A0 yet.
As I know my jetpet version is r36_release_v3.0 since I downloaded “wget https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v3.0/***”
Or Can I check other point?
you may examine release tag, $ cat /etc/nv_tegra_release for confirmation.
Hello Jerry Chang
Capture results are below.
u@u:~$ cat /etc/nv_tegra_release
R36 (release), REVISION: 3.0, GCID: 36191598, BOARD: generic, EABI: aarch64, DATE: Mon May 6 17:34:21 UTC 2024
KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
hello suengpyo.shin,
one more question, is there an issue (85% failure rate) with launching c1 individually, or launching all of a1,b1,c1 together?
hello Jerry Chang.
I launched all of a1,b1 and c1 together.
Thank you.
hello suengpyo.shin,
it may due to bandwidth allocation issue,
please try testing with single/dual/triple camera and sharing the results.
thanks
Hello Jerry Chang.
I enabled only cam_a1 and tested but pass 2 over 6 trials.
I uploaded both success and fail logs.
I set up preparing for streaming at boot time.
And then I issued stream on cam when imx390_start_streaming was called.
I issued command “gst-launch-1.0 v4l2src device=/dev/video2 ! ‘video/x-raw,format=GRAY8,width=3840,height=1024’ ! filesink location=./test.yuv”
about 10 times.
1 time was success in this case.
I can’t explain why some times success and some times fail.
cam_a1_success_repeat_10times_20240723_104243.txt (535.9 KB)
cam_a1_success_case_20240723_104243.txt (404.2 KB)
cam_a1_fail_case_20240723_104243.txt (226.2 KB)
Hello Jerry Chang.
I think the issue might be due to the deskew settings.
I’m changing deskew settings.
My deser’s output data rate is 1.6G
I’m using following equation.
serdes_pix_clk_hz = (deserializer output data rate in hertz) * (number of CSI lanes) / (bits per pixel).
(1600000000x2)/16 == 200000000
Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)
(200000000x16)/2 == 1600000000
In deser, periodic deskew calibration generated every frame, Initial deskew width = 8 x 32k UI
And I attached dts file.
Please let me know how to change values?
tegra234-p3737-camera-imx390-overlay.dts.txt (28.7 KB)
hello suengpyo.shin,
normally, serdes_pix_clk_hz should be larger than pix_clk_hz, and driver side only consider the serdes_pix_clk_hz (if that’s defined) for processing.
FYI,
we are only looking for initial deskew calibration;
however, it should also be ok to support the deserializer with periodic skew calibration bursts. the effect would be that the initial skew calibration can be retried every time the skew calibration burst is sent.
Hello Jerry Chang.
I have to use below command at starting.
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
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 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
I would like to do not use those command.
How would I change settings.
Thank you and best regard !
hello suengpyo.shin,
there’re two parts, first to adjust system clocks (VI, ISP, NVCSI…etc) to maximum, and the later to enable VI tracing logs, which may ignored for real use-case.
regrading to clock configuration, for your use-case, it’s parse the device tree property, serdes_pix_clk_hz for initialization.
according above, you should review your clock settings, please try a higher settings for verification.
Hello Jerry Chang.
Could you let me know which file should I modify to maximize (VI, ISP, NVCSI…etc) ?
Thank you always your prompt response.
hello suengpyo.shin,
please review your sensor device tree, especially the serdes_pix_clk_hz settings.
Hello Jerry Chang
According to error code.
kworker/1:2-390 [001] … 56.670846: rtcpu_nvcsi_intr: tstamp:3013750150 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x10000000
is occured in error case.
I found that errors meaning as below
define NVCSI_INTR_FLAG_CIL_INTR0_DPHY_LANE_ALIGN_ERR MK_BIT32(28)
Could you let me know what is NVCSI_INTR_FLAG_CIL_INTR0_DPHY_LANE_ALIGN_ERR?
Hello Jerry Chang.
Shall I speed up serdes_pix_clk_hz or speed down serdes_pix_clk_hz.
I set serdes_pix_clk_hz as our DSER setting
hello suengpyo.shin,
that’s due to an error has detected in the PHY partition, that some lanes has detected sync words while other lanes not.
you may refer to SerDes Pixel Clock.
please note that, the SerDes pixel clock must be specified correctly to configure the SoC-camera interface correctly and avoid buffer overrun issues.
Hello Jerry Chang,
Thank you for your prompt responses as always.
I believe I have identified the cause of the low capture success rate. Initially, I set up SER and DSER once and executed the following command:
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1 ! filesink location=./test.yuv & gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1 ! filesink location=./test1.yuv & gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1 ! filesink location=./test2.yuv
During this process, the start command was called three times in the device driver, and each time, the stream on for SER and DSER was also called. I modified it so that the stream on is called only once, even if the command is executed three times. After this change, I found that the capture worked correctly.
However, the output for video0, which is connected to CSI-1, is not displayed. For debugging, I tried to activate only video0, which is connected to CSI-1, and enabled only the camera outputting to CSI-1 in SER DSER. The following log is displayed:
kworker/3:1-78 [003] … 285.079565: rtcpu_nvcsi_intr: tstamp:10173488680 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
kworker/3:1-78 [003] … 285.079565: rtcpu_nvcsi_intr: tstamp:10173489725 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
kworker/3:1-78 [003] … 285.079565: rtcpu_nvcsi_intr: tstamp:10173490774 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
kworker/3:1-78 [003] … 285.079566: rtcpu_nvcsi_intr: tstamp:10173491621 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
kworker/3:1-78 [003] … 285.079566: rtcpu_nvcsi_intr: tstamp:10173492478 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
CIS1_TEST_20240725_104802.txt (1.9 MB)
tegra234-p3737-camera-imx390-overlay.dts.txt (22.6 KB)
Could you please check if I have configured the dts file correctly?
I attached dts file and log file.
Thank you.