Hi,
Our Orin board use 4 Max9296 connect with Sensing-world’s 8 cameras on CSI lane x 4. Camera module use AR0231, AP0202, Max96705, and the resolution is 1920x1080, FPS is 20.
Now there are two board has two problems on camera:
dmesg print:“tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 0, flags: 0, err_data 131072 chan_id 1” and lost this frame. It almost lost 1 frame every minutes;
There is now frame capture after camera initialize, and dmesg print : “tegra-capture-vi: uncorr_err: request timed out after 2500 ms” always;
I hope there is a way to investigate NVCSI stream flow, for example: mipi packet, signal quality etc. Since it can help me to judge if it is a hardware problem.
Thanks for your help!
BR/Tim
is it only happened with multi-cam use-case?
since it’s a SerDes chip, could you please enable test-pattern-generator?
this usually helps to narrow down the issue with bridge device configuration.
Thanks for you reply.
Since abnormal camera port is settled(lost frame board is 0-4 ports, no frame board is 6, 7 ports), multi-cam or single-cam has same behavior.
Would you please tell me how to enable test-pattern-generator?
Thanks!
it’s usually the configuration on the serdes chip for creating color bar as testing purpose.
you may contact with vendor for the code snippets, and instructions.
your VI tracing logs did not present camera related signaling.
if you confirm there’s packets on the CSI channel, it might be issues with device tree settings.
besides, did you have issue a reset signal to SerDes chip when s_stream has called?
Hi jerry,
I am ckt1010’s colleague,Please help us check the device tree settings: AR0231_MAX96705 → MAX9296,4 lane MIPI with 800MHz,dts related to camera is below:
reg = <0x1b>;
devnode = “video0”;
nvidia,gmsl-dser-device = <&dser_a>;
serdes-csi-link = “a”;
may I also confirm the Jetpack release version you’re working with.
there’re some update with the latest release, you may see-also Release Notes (r35.4.1).
re-cap as below…
1.2. What’s New
● Camera
○ Enhanced error resiliency for improved stability in Argus.
○ Added support for multiple camera synchronization (added sample argus_syncstereo).
○ Added support for Deskew calibration for high data rate sensors (> 1.5 Gbps).
so,
please moving to the latest release version for confirmation.
Hi Jerry,
Our board come from TzTek, they provide kernel to us. Jetpack release version is 5.1.1 and L4T 35.3.1.
And since we didn’t use Argus and Deskew (800Mps), they think we don’t need update kernel.
BTW could you check our dts if it is valid?
Thanks!
let’s narrow down the issue,
please simplify the connection to leave only single camera on the system, and also revise the DT to keep only vc-id=0 in the node definition.
can the device node (i.e. $ /dev/video0) register to linux kernel correctly?
if yes, please refer to SerDes Pixel Clock section to double check the clock settings.
if no, there might be something wrong in the port bindings, you may check Port Binding to review the settings.