My camera use MIPI-CSI TX output images，and it’s DPHY version is 1.2, but the orig nano’s MIPI-CSI DPHY version is 2.1, my question is if they can connect direct? or I need to translate voltage level to connect each other together?
another question is nano’s MIPI-CSI is processed by real time CPU called Cortex-R5 micro-controller?and send message to tegra soc through IVC?
Yes, the MIPI_CSI DPHY 2.1 should compatible with 1.2, and part of the low level is handle by RTCPU(Cortex-R5 micro-controller)
this is replay from AI when I ask same question，it said DPHY 2.1 can’t not connect to DPHY 1.2 direct because of voltage level is not compatible, I not sure it’s whether correct;
another question is if I can debug code which is run on RTCPU, if can, how to do it? can you give me method? right now MIPI-CSI could not get any data from my camera, and RTCPU did’t reports any error when communication with my camera, but I’am sure my camera seed image to RTCPU;
thanks a lot~~
I only get the error such as below, it may be report by capture vi because it time out to get frame from RTCPU:
[ 404.631508] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 10000 ms
[ 404.631540] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Get the trace log.
BTW, the IMX219 reference sensor board is DPHY 1.2 that working without problem on Orin Nano.
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 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
v4l2-ctl --stream-mmap -c bypass_mode=0
cat /sys/kernel/debug/tracing/trace
strace_2026_01_30_V1.log (8.4 MB)
The trace log I get from my Nano when use VLC get image from my camera as above;
The error tell the data lane sot multiple bits errors.
That could be the improper pix_clk_hz to get improper cil_settletime cause the problem.
And if the sensor output timing don’t follow the MIPI spec.
I set the cil_settletime and pix_clk_hz in device tree node, and I modify cil_settletime in device tree node from 0 to 255, but it have nothing improvement;
how can I check the pix_clk_hz is correct? is there any method to use?
Set the cil_settletime = 0 for auto calculation and make sure the pix_clk_hz follow below.
Looks like without problem. However the user defined byte-base data may need to disable.
what’s the byte-base data mean? is embedded_metadata_height ?
User-defined 8-bit data types typically span from 0×30 to 0×37
.
The error seems happend in DPHY layer, is there any parameters that I can modify in Nano to solove this problem?
The MIPI signal is output by the sensor Nano just a receiver to config the DPHY parameters.
Please check with the sensor vendor for the sensor output timing follow below.
I find the timing from my camera data sheet, I’am not sure whether compatible to Nano;
if my camera send user defined data to Nano, it also can leed to Nano report such int error as above?
This error doesn’t matter with the user defined data.
the error have relationship with pixel format, for example: YUV422 2plane and YUV422_UYVY 1plane ?
Doesn’t matter too. The error tell the MIPI signal timing instead of any data format problem.
Is the Nano support discontinuous clock mode right now？ my use jetson version as below:
root@ubuntu:/home/zjbllg# cat /etc/nv_tegra_release
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
I find property “discontinuous_clk” defined in device tree, but I can’t find it used in source code anymore, I just find code as belew:
if Nano support discontinuous clock mode, how to use it? and how to check in this mode?
