I am working on developing a camera driver for a RAW8 camera using the FPDLİNK-III DS90UB954 Deserializer and DS90UB953 Serializer. On the LT32.4.3 version of the NVIDIA platform, I successfully developed the driver and was able to capture the video stream.
However, after migrating to the LT35.1.0 version and implementing the same driver (with adjustments as needed for the new platform), I am unable to receive any video stream from the camera.
Here are the details of the issue:
Platform Details:
Serializer: DS90UB953
Deserializer: DS90UB954
Data Format: RAW8
Observations
The same hardware setup and camera configuration work perfectly on LT32.4.3.
On LT35.1.0, there is no video output, and the camera does not seem to stream data.
Debugging
Verified the device tree configurations for LT35.1.0.
Compared the FPDLink status and power sequence logs between both versions.
Checked for any kernel API changes between the two versions that might affect the driver.
Logs and Trace Outputs:
Here are some trace logs and kernel debug messages from LT35.1.0:
[Attach logs here, formatted for readability.]
[ 168.672992] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 168.673316] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 168.673528] tegra-camrtc-capture-vi tegra-capture-vi: vi5_channel_error_recover vi5_capture_dequeue
[ 168.674081] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 168.674240] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 168.674447] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 168.674630] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 168.675271] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 171.488861] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 171.489140] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 171.489452] tegra-camrtc-capture-vi tegra-capture-vi: vi5_channel_error_recover vi5_capture_dequeue
I suspect this issue might be due to changes in the kernel driver model, device tree handling, or FPDLink initialization between LT32.4.3 and LT35.1.0.
Has anyone encountered a similar issue while migrating drivers to LT35.1.0? Any guidance on additional debugging steps or specific changes to be aware of in LT35.1.0 would be greatly appreciated.
honestly, there’re several camera software bugs within early JP-5 release versions.
is it possible for moving forward to the latest jetson-linux-r3560 for verification?
While trying to stream on version 35.6.0, the kernel goes into panic, making the situation worse.
I have reverted to version 35.1.0 for now. At this point, it seems that the frame counter on my deserializer is incrementing, but I suspect that the Xavier NX is not receiving the frames correctly.
However, I can confirm that the hardware works perfectly fine on version 32.4.3. The only difference is that I am now using the J202 Carrier Board from Seed Studio, which does not support version 32.4.3. Therefore, I am forced to use JP5.
I am unable to identify the root cause of the issue. When I flash my custom DTB and image files, the device reboots, but the screen goes blank, and the system enters a kernel panic. After unplugging and restarting the device, it powers on, but the screen still does not come back.
I have attached the logs below for reference. Could you please help me understand what might be causing this issue?
it’s NULL pointer dereference, you may dig into your device tree property settings.
please refer to Camera Driver Porting to review your drivers and troubleshooting,
besides, may I know how you updating your customize DTB file?
I don’t believe this issue is caused by an error in the device tree I created. It only occurs when I reboot the system. When I unplug and plug the device back in, it powers on, and the camera initializes successfully.
In my opinion, this seems to be a reboot-related issue. The system boots up, and /dev/video0 is created. However, when I start the camera stream, a different kernel panic occurs. The logs for that issue are included below.
What could be causing the display to go blank? I haven’t made any changes to the display drivers.
according to the logs, it’s kernel panic reported during tegra_camera_update_clknbw.
it’s function to allocate necessary pixel clock, it parse the device tree for the settings.
please dig into VI driver, you may adding some debug prints for examination. (i.e. cdev->pixel_rate.)
for instance, $public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
according to tracing logs, it looks like there’s no validate frame packets received by VI engine.
may I double check which L4T version you’re now working, please check release tag for confirmation, i.e. $ cat /etc/nv_tegra_release
besides, settings since you’re working with SerDes chip, please also check SerDes Pixel Clock section to review your serdes_pix_clk_hz, such pixel clock property value must be set correctly to avoid potential issues.
By using formula you mentioned for the serdes_pix_clk_hz value, we were able to achieve video output after calculating and inputting the appropriate value:
serdes_pix_clk_hz = (deserializer output data rate in hertz) * (number of CSI lanes) / (bits per pixel).