I believe I am in need of assistance with regards to Linux kernel drivers for the CSI-2 output of the Texas Instruments DS90UB964-Q1 Quad Camera Hub attached to a Nvidia Jetson TX1. If there is any Linux device drivers available for the DS90UB964-Q1, or documentation on writing drivers for this chip, please advise.
However, my problem may be elsewhere. Hence, I am providing further information on my project:
Run machine vision software (OpenCV-based) using multiple camera input (4 in this case) on an embedded device
(OpenCV can access cameras once a handle to the camera device is available in /dev/video* (in Linux))
Therefore, aim is to make camera devices available via /dev/video*.
Linux4Tegra (L4T) version 24.2.1
Quad camera hub:
Texas Instruments DS90UB964-Q1
4x OV10635 Serial Coax
The DS90UB964-Q1 (hereafter referred to as the UB964) was connected to the Nvidia TX1 via the (TX1) J21 GPIO expansion header (for I2C connectivity) and (TX1) J22 Camera connector (for MIPI-CSI2 connectivity). The OV10635 cameras connect via coax to the UB964 board. Development is done on the Linux OS on the TX1 (L4T R24.2.1).
Firstly, the i2c connection was confirmed by checking for visibility in userspace, using the Linux program i2c-tools. The following i2cdetect command:
i2cdetect -y -r 0
Revealed the UB964 at (7 bit) i2c address 0x30. This was double-checked in Windows, via connection to I2C using an (Total Phase) Aardvark I2C-to-USB connector and the Texas Instruments Analog Launchpad program. Registers revealed using both methods were checked against the expected default values found in the DS90UB964-Q1 Quad FPD-Link III Deserializer Hub pdf. Electrically, the connection was checked on an oscilloscope (connected to SDA and SCL on the UB964), and write commands to this i2c address produced expected clock and data waveforms on the oscilloscope.
From this, it appears we have connection to the UB964 I2C bus via Linux on the TX1. Next, we wanted to test the connection to the OV10635 (connected through the UB964). So, the next step was to setup the UB964 to alias the OV10635 to the I2C bus (visible in TX1 userspace). A sample script (found in a Texas Instruments UB964 pdf) for locking ports, setting up CSI parameters and aliasing receivers on the I2C was followed in Linux using the same registers and values but setting up using a shell script consisting of i2cset commands.
After running these commands (as a shell script (.sh)), two extra i2c addresses (per each camera connected) were found on the i2c bus. Both of these new i2c addresses were “pinged” via i2cget commands (which reads registers at i2cbus addresses) and one of the two new addresses (per camera) displayed expected data / clock response on an oscilloscope (attached to the SDA/SCL lines on the OV10635 Serial Coax board) while the other register displayed nothing on the oscilloscope.
From this, it appears we have access to the OV10635 registers through the I2C bus.
I don’t have much experience in the Linux kernel, or the lower-level I2C and CSI-2 functionality with the kernel, so general pointers may prove useful.
At this point, I believe my next step is to start looking at how to acquire the CSI-2 data from the UB964 on to the TX1. From what I’ve read on the Nvidia forums and about Linux, I believe I need to get a device driver so the TX1 kernel-space can identify the i2c connection in the device tree (via its i2c address on the TX1 i2c bus), and (using the “compatible” parameter in dtsi file) link this to a driver file (.c) with information about the incoming frames (height, width, clock, etc.) which should allow the Video4Linux2 (V4L2) framework to create a node under /dev/video* with which one can read in the camera frames. I may be incorrect in my assumptions of this process. I’m not sure where a CSI-2 handle might fit in to the kernel either.
I have attempted to make device driver files and recompiled the Linux kernel with these device drivers, but nothing shows up in /dev/video*. The device driver files I complied were simply renamed copies of OV5693 device driver files, and I changed the i2c address in the dtsi files to that of the UB964.
Although I am on L4T 24.2.1, I haven’t found many useful forum posts about using the Media Controller API; so I have been attempting to go the Soc_Camera route as mentioned in these posts:
I had difficulty making nvhost_vi a module, so I removed it and manually exported the symbols that were missing when I tried to recompile the kernel. I added soc_camera as a module (along with created driver files)and recompiled kernel again so I could modprobe soc_camera, which successfully runs. modprobe tegra_camera however responds with “device or resource busy”.
That’s about where I am up to. Other than trying the Media-Controller route, I am not sure how to debug this problem further, and can’t seem to find any more potential development avenues after searching forums of Nvidia, Texas Instruments and Linux.
I followed this guide to build the kernel: http://www.jetsonhacks.com/2016/09/28/build-tx1-kernel-and-modules-nvidia-jetson-tx1/
I have also posted this to the Texas Instruments E2E forums, as I believe I may require help from both TI and Nvidia in getting this board functional.
Thanks for your time,