Washed out / purple image from IMX377 on TX1

Hi all,

We are attempting to bring up a custom carrier board and custom IMX377 camera module on the TX1 / JetPack3.3 / L4T 28.2.1. This is the first time both this carrier board and custom sensor module are being tested.

We started with Leopard’s IMX377 driver for TX2: Dropbox - File Deleted
I can confirm their driver works with their 3-camera adapter board and their IMX377 module on the TX2. They do have an older driver package for TX1, but it is for L4T28.1 and we need it to work on 28.2.1.

For our carrier board, we have modified the device tree to remove the need for the i2c switch. For this test, we are only using one camera. For simplicity, I’ve put all of our modifications into one DTS file (attached here).

The ISP overrides file is set up correctly and recognized by the nvcamera-daemon, and Leopard confirms the same ISP file can be used with the TX1 and TX2. The attached gstreamer screenshots are from the working and non-working systems using the same lens. In order to rule out the possibility that the ISP is messing something up, I tried capturing the RAW files using v4l2-ctl.

I have enabled logging according to the wiki:

sudo su
cd /sys/kernel/debug/dynamic_debug/
echo file csi2_fops.c +p > control

When I run the command:

v4l2-ctl --set-fmt-video=width=4104,height=3046,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3 --stream-to=imx377.raw -d /dev/video0

I get this result:

root@tegra-ubuntu:/sys/kernel/debug/dynamic_debug# v4l2-ctl --set-fmt-video=width=4104,height=3046,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3 --stream-to=imx377.raw -d /dev/video0
<<<
root@tegra-ubuntu:/sys/kernel/debug/dynamic_debug# dmesg
[ 1140.012188] vi 54080000.vi: Calibrate csi port 0
[ 1140.059599] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[ 1140.066520] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[ 1140.072094] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[ 1140.077789] vi 54080000.vi: cil_settingtime is pulled from device
[ 1140.083896] vi 54080000.vi: cil_settingtime was autocalculated
[ 1140.089728] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[ 1140.096606] vi 54080000.vi: cil_settingtime is pulled from device
[ 1140.102705] vi 54080000.vi: cil_settingtime was autocalculated
[ 1140.108536] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10

I have attached what I see when viewing the raw files in Photoshop. From viewing the raw file generated on the working TX2 system and comparing them to my non-working TX1 system, it seems like one or more of the color channels is not coming through. If so, what are the potential causes for something like this? Is it possible that a hardware issue could cause a missing channel?

It’s worth noting that when I run the command with fewer parameters suggested on the elinux wiki:

v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3

I do get the following error:

[   58.530231] video4linux video0: MW_ACK_DONE syncpoint time out!0
[   58.616269] video4linux video0: MW_ACK_DONE syncpoint time out!0
[   58.622617] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[   58.635088] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[   58.641210] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[   58.651977] vi 54080000.vi: cil_settingtime is pulled from device
[   58.658121] vi 54080000.vi: cil_settingtime was autocalculated
[   58.663974] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10

The wiki suggests reviewing the “line_length” setting. Could this be something that needs to be adjusted when moving to a different carrier board? Is this really even an error I should be concerned with, since it doesn’t happen when capturing with the full v4l2-ctl parameters above?



tegra210-jetson-tx1-d3.dts.zip (3.01 KB)

Does any other sensor mode to try instead of 4104x3046?

This driver only has the one mode, and that’s all we really need. It works fine on TX2, so we know the I2C settings are valid for the sensor. We also know this mode worked at some point with the TX1 in an earlier version of the driver for 28.1.

The only difference in the modes table between the old version and the current version is the enabling of the embedded data from the sensor. I didn’t see anywhere in the driver where the embedded data is parsed. I don’t think this difference would be relevant here, would it?

-marc

Does this problem repo with connect to reference TX1 carrier board?