gsml camera
We are facing this issue while interfacing the LI-AR0820 Image sensor with Jetson ORIN on MIPI-CSI-A port with 4 lanes configuration.
Continuously reporting errors：
[RCE] ISR PHY 0 CIL_B 0x40
camera log ：
csi2.log (802.2 KB)
hello 305248199.
those were debug logs, I believe you’ve debug version camera firmware applied.
may I confirm the Jetpack release version you’re working with.
furthermore,
skew calibration is required since you’ve camera with output data-rate larger than 1.5Gbps.
there’s a known issue that camera firmware kept waiting for deskew signal from the sensor side.
could you please try with Applications Using V4L2 IOCTL Directly to use V4L2 IOCTL to verify basic camera functionality.
Jetpack version is 5.0.2
The effect is the same when using the command：
v4l2-ctl -V --set-fmt-video=width=3840,height=2160,pixelformat=YUYV --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3 --stream-to=8M_yuyu_video.yuv -d /dev/video0
Mainly because I don’t know what this log means？？？
[RCE] ISR PHY 0 CIL_B 0x40
as mentioned…
But under another low board of orin, with the same software and hardware configuration, there is no such problem
hello 305248199,
what did you meant another low board of orin? it is has lower data-rate below 1.5Gbps.
2 cameras connected to port index=0, 4lanes, vc0, vc1, one displaying normally, and the other without video locked，but with link locked
I configured deskew on max96712, and the orin system only needs to modify theserdes_pix_clk_hz enough?
The formula is ??
Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)
serdes_pix_clk_hz = (Output data rate) * (number of CSI lanes) / (bits per pixel).
hello 305248199,
please refer to SerDes Pixel Clock section.
moreover, it’ll choose serdes_pix_clk_hz when it’s defined, and serdes_pix_clk_hz should be larger than pix_clk_hz.
3840 * 2160
30 frame
I am currently using this：
pix_clk_hz=“280000000”;
serdes_pix_clk_hz=“833333333”；
camera.dtsi (15.5 KB)
hello 305248199,
(1) I don’t see the marco for this setting… tegra_sinterface = TEGRA_SINTERFACE;
please check both sensor nodes has assign to tegra_sinterface = "serial_a".
(2) please revise num_csi_lanes and position property within tegra-camera-platform {...}
for example,
tegra-camera-platform {
num_csi_lanes = <8>;
module0 {
badge = "ar0234b_bottomleft";
position = "rear";
module1 {
badge = "ar0234b_bottomright";
position = "front";
TEGRA_SINTERFACE–> serial_a
It’s all on port index=<0>
num_csi_lanes = 8 ?
Position=“real”;
Must we start from real?
it’s rear and front. please double check.
The two positions have been changed according to your requirements, but the problem still persists. The prompt is:
[RCE] ISR PHY 0 CIL_ B 0x40
Deskew_ Initial_ Enable=“true”;
Do you need this sentence?
no, this property Deskew_ Initial_ Enable is unnecessary.
had you confirm this is related to deskew issue? can the camera functionality works normally by lower the data-rate?
FYI, we’ve some changes to address the deskew timeout issue. it’ll coming with next public Jetpack release verison.
Reduce the rate of pix_clk_hz and serdes_pix_clk_hz ?
camera new log：
entries-in-buffer/entries-written: 27/27 #P:8
_-----=> irqs-off
/ _----=> need-resched
| / _—=> hardirq/softirq
|| / _–=> preempt-depth
||| / delay
TASK-PID CPU# |||| TIMESTAMP FUNCTION
| | | |||| | |
kworker/4:2-181 [004] .... 65.745641: rtcpu_string: tstamp:2643898942 id:0x04010000 str:"VM0 deactivating."
kworker/4:2-181 [004] .... 75.245629: rtcpu_string: tstamp:2940896398 id:0x04010000 str:"VM0 activating."
kworker/4:2-181 [004] .... 75.245635: rtcpu_string: tstamp:2941005301 id:0x04010000 str:"NVCSILP clock rate = 408000000 Hz.
"
kworker/4:2-181 [004] … 75.469668: rtcpu_isp_falcon_task_start: tstamp:2947771422 ch:0 task:HANDLE_EVENT
kworker/4:2-181 [004] … 75.469673: rtcpu_isp_falcon_task_end: tstamp:2947771463 task:HANDLE_EVENT
kworker/4:2-181 [004] … 76.197618: rtcpu_string: tstamp:2969990858 id:0x04010000 str:“tegra_nvcsi_stream_set_config(vm0, stream=0, csi”
kworker/4:2-181 [004] … 76.197622: rtcpu_string: tstamp:2969990959 id:0x04010000 str:"=0)
"
kworker/4:2-181 [004] … 76.202146: rtcpu_string: tstamp:2969991330 id:0x04010000 str:“MIPI clock = 1000000 kHz, tHS-SETTLE = 0, tCLK-S”
kworker/4:2-181 [004] … 76.202147: rtcpu_string: tstamp:2969991431 id:0x04010000 str:“ETTLE = 0
"
kworker/4:2-181 [004] … 76.202156: rtcpu_string: tstamp:2969991641 id:0x04010000 str:”===== NVCSI Stream Configuration =====
"
kworker/4:2-181 [004] … 76.202159: rtcpu_string: tstamp:2969991882 id:0x04010000 str:"stream_id: PP 0, csi_port: PORT A
"
kworker/4:2-181 [004] … 76.202162: rtcpu_string: tstamp:2969992133 id:0x04010000 str:"Brick: PHY 0, Mode: D-PHY
"
kworker/4:2-181 [004] … 76.202166: rtcpu_string: tstamp:2969992417 id:0x04010000 str:"Partition: CIL A, LP bypass: Enabled, Lanes: 4
"
kworker/4:2-181 [004] … 76.202169: rtcpu_string: tstamp:2969992595 id:0x04010000 str:"Clock information:
"
kworker/4:2-181 [004] … 76.202172: rtcpu_string: tstamp:2969992899 id:0x04010000 str:"MIPI clock rate: 1000.00 MHz
"
kworker/4:2-181 [004] … 76.202175: rtcpu_string: tstamp:2969993141 id:0x04010000 str:“T_HS settle: 0, T_CLK settle: 0
"
kworker/4:2-181 [004] … 76.202179: rtcpu_string: tstamp:2969993364 id:0x04010000 str:”======================================
"
kworker/4:2-181 [004] … 76.202182: rtcpu_string: tstamp:2969995105 id:0x04010000 str:"tegra_nvcsi_stream_open(vm0, stream=0, csi=0)
"
kworker/4:2-181 [004] … 76.202185: rtcpu_string: tstamp:2970002010 id:0x04010000 str:"nvcsi_calc_ths_settle ths_settle 50
"
kworker/4:2-181 [004] … 76.202188: rtcpu_string: tstamp:2970002272 id:0x04010000 str:"nvcsi_calc_ths_settle ths_settle 50
"
kworker/4:2-181 [004] … 76.202191: rtcpu_string: tstamp:2970002529 id:0x04010000 str:"nvcsi_calc_ths_settle ths_settle 50
"
kworker/4:2-181 [004] … 76.202194: rtcpu_string: tstamp:2970002783 id:0x04010000 str:"nvcsi_calc_tclk_settle tclk_settle 75
"
kworker/4:2-181 [004] … 76.202198: rtcpu_string: tstamp:2970003465 id:0x04010000 str:"Deskew setup message sent for port 0 num_lane 4
"
kworker/4:2-181 [004] … 76.202205: rtcpu_vinotify_event: tstamp:2970105541 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:95026753312 data:0x379d580010000000
kworker/4:2-181 [004] … 76.202206: rtcpu_vinotify_event: tstamp:2970105675 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:95026759840 data:0x0000000031000001
kworker/4:2-181 [004] … 76.202206: rtcpu_vinotify_event: tstamp:2970105825 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:95026805888 data:0x379d550010000000
kworker/4:2-181 [004] … 76.202206: rtcpu_vinotify_event: tstamp:2970105953 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:95026812448 data:0x0000000031000002
root@cookoo:~# [ 78.813630] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 78.813948] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 78.815076] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 78.815309] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 78.815620] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 78.815847] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 78.816314] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 81.341639] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 81.341939] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 81.343043] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 81.343272] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 81.343578] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 81.343795] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 81.344293] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 81.347851] bwmgr API not supported
it looks you did not lower the data-rate correctly, because this is still reported by camera firmware to wait for deskew signal from sensor side.
If there are images, this log cannot produce images
hello 305248199,
did you meant…
you cannot capture frames only when you see Deskew setup message sent for port 0 num_lane 4 present on tracing logs?
if yes,
that’s the deskew timed out issue. there’re some bug fixes check-in to rel-35 code-line, please expect next public release will address the issue.
FYI,
it’s Argus waits for signal too early.
to workaround this… you may configure sensor state as standby (not streaming), then switch the sensor state to stream after you see the RCE deskew setup debug logs. (i.e. [RCE] Deskew setup message sent for port 0 num_lane 4…)