Hello, I would like to display 8 cameras (x4 lanes) on Orin NX using virtual channels.
While I could see the output from 4 VC cameras on CSI2 (Serial_c), I couldn’t get any output on CSI0 (Serial_a).
Currently, I have set port-index = <0>, bus-width = <4>, tegra_sinterface = "serial_a", and lane_polarity = "6". Are there additional settings required to use four-lane cameras on both CSI0?
The devkit CSI-0/1(CAM0) only support 2 lanes due HW problem.
You may need design customized carrier board for 4 lanes use case on CAM0.
Hi, Shane.
I’m using a custom board, not the devkit.
As shown in the attached picture, the board is configured to use 4-lane cameras on CSI0+1 and CSI2+3.
I’m also attaching my DTS file for reference.
test.dts.txt (33.7 KB)
I can see all /dev/video nodes from 0 to 7, but only the camera on serial_a is not displaying video.
Do you dump the device tree to confirm?
sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
Get the trace log to check.
extracted_proc.dts.txt (334.8 KB)
Here is the log file. Is that right?
Didn’t find any problem in the dump file
What the trace log.
sudo modprobe rtcpu_debug ##JP6 release needed
sudo su
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
v4l2-ctl -c bypass_mode --stream-mmap -d /dev/video0
cat /sys/kernel/debug/tracing/trace
log.txt (11.3 MB)
I’m sorry, but I am not familiar with the “SOT multiple bits error.” Do you have any hints on how to resolve this issue? Should I adjust cil_settletime= "0"?
Also, the device tree settings for CSI2 and CSI0 are the same—do I only need to change the settings for CSI0? Could the lane_polarity = "6" option be the cause of this error?
This problem doesn’t matter with the lane_polarity you can try the cil_settletime but can’t promise help on it. If didn’t help on that you need consult with sensor vendor to adjust the settle time for it.
BTW, you also can configurate the sensor to continuous/dis-continuous clocks mode to try.
The question is why there’s a different result when the same camera is mounted on CSI 0 and CSI 2. I am applying the same settings to each deserializer, and the cameras are also the same. Could a MIPI settle time issue occur only on CSI 0?
As far as I know, the only difference between CSI 0 and 2 is that N and P are swapped. That’s why I asked if lane_polarity = "6" could affect the current issue.
It could be the timing in the boundary cause the deviation.
I adjusted the settle time and changed discontinuous_clk= "yes" The log has changed—could you provide any hints about this log?
continuous.log (7.6 KB)
Ohh…I’m sorry. This log is after changing the setting from 4-lane to 2-lane for testing.
Hello, I resolved the issue, though not in the way I initially expected. I removed lane_polarity = "6" for CSI0 from the device tree and adjusted the polarity in the deserializer’s output settings instead. I’m curious whether the lane_polarity option in the device tree wasn’t applied correctly or if it was causing some other issue…
CPHY?
D-PHY.
Please probe the P/N signal first to check if the polarity is really changed by lane_polarity = “6” on your board.
Hi, Trumany.
Are you asking whether I should check if the lane_polarity property is applied through the sysnode, or whether I should directly verify the waveform of the pins whose polarity is changed by lane_polarity = "6"? If it’s the latter, I would like to confirm if I should check the waveform of the pins on the Orin NX connector side.
It’s the latter. You can check the waveform at any point on line. Just make sure the P/N output from deser is as expected.
I checked the waveforms of pins 3 and 5 on the Orin NX connector and confirmed that the polarity (P/N) changes when modified on the deserializer. Is there any additional way to verify this when using the lane_polarityproperty instead of changing it on the deserializer?
When the P/N was swapped on the deserializer and lane_polarity=6 was set, no video output was observed (video output is visible with lane_polarity=0). Considering this result, it seems that the lane_polarity option does work as expected. However, it is puzzling that the video cannot be confirmed using only the lane_polarity=6 property…
