This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/DS90UB964-Q1: Wanting userpsace frame capture in Linux; Kernelspace device driver issue

Part Number: DS90UB964-Q1
Other Parts Discussed in Thread: ALP

Tool/software: Linux

Hello,

I believe I am in need of assistance with regards to Linux kernel drivers for the CSI-2 output of DS90UB964-Q1 Quad Camera Hub. If there is any Linux device drivers available for the DS90UB964-Q1, or documentation on writing drivers, please direct me as I cannot find them.

However, my problem may be elsewhere. Hence, I am providing further information on my project:

Project specifications:

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*.

Materials:

Embedded Device:

Nvidia TX1

Operating System:

Linux4Tegra (L4T) version 24.2.1

Quad camera hub:
DS90UB964-Q1

Cameras:
4x OV10635 Serial Coax

Connectivity:


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). OV10635 connect via coax to the UB964 board. Development is done on the Linux OS on the TX1 (L4T R24.2.1).

Methods tested:


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, pin numbers used can be found if necessary), 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). The DS90UB96X-Q1EVM User's Guide pdf (page 22) showed an sample ALP python script for locking ports, setting up CSI parameters and aliasing receivers on the I2C. This example was followed in Linux, using the same registers and values, but setting up using a shell script consisting of i2cset commands, such as the following:

i2cset -y -r 0 0x30 0x10 0x81

This i2cset command example refers to i2cbus 0 (on the TX1), at address 0x30 (UB964), register 0x10, value 0x81. A copy of all i2cset commands used here can be given if necessary.

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.

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 have attempted to make device driver files and recompiled the Linux kernel with these device drivers, but to no avail. I'm unsure if the anything in the TI Processors SDK (http://www.ti.com/lsds/ti/tools-software/processor_sw.page?DCMP=epd-gen&HQS=processorsdk would be helpful with regards to the UB964.

I also plan on posting in the Nvidia TX1 forums, as I believe I may require help from both TI and Nvidia in getting this board functional.

Thanks for your time,

Regards,

Peter.

  • Hi Peter,

    We don't provide Linux device drivers for the FPD-Link III SerDes.  Python script examples are given in the DS90UB964-Q1 datasheet and user's guide.  The information about the incoming frames ( line count and line length) are reported in registers 0x73-0x76.

    Regards,

    Davor