Connecting >1 Fake OV5693 Sensors without Multiplexer

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi,

I have successfully captured raw FPGA data by “faking” an OV5693 sensor and commenting out all the I2C functions. It’s a 4-lane signal connected to serial_a. I now want to connect a second FPGA which also provides a 4-lane signal to serial_e. I have copied what I’ve done and adapted the device tree files as follows:

  • Added an additional module1 which links to ov5693_e@36 as drivernode0
  • Added an e3333_ov5693_out1 to /i2c@3180000/ov5693_e@36/<…>
  • Added an e3333_vi_in1 to /tegra-capture-vi/ports/port@1/endpoint
  • Added an e3333_csi_in1 and e3333_csi_out1 to nvcsi@15a00000/<…>
  • Added a ov5693_e@36 node directly to i2c@3180000, alongside the existing ov5693_a@36

The new ov5693_e@36 has “video1” as its devnode, though video1 never shows up. My best guess is that I can’t assign two ov5693 sensors to the same I2C address, namely 0x36. Is that correct?

I need some way of connecting two OV5693 sensors without the pca954x multiplexer, as I don’t have a physical multiplexer in my setup, as the whole setup is faked in order to directly capture raw incoming CSI data from two FPGAs.

Assigning a second I2C address, such as 0x40 to the ov5693_e@40 makes the Jetson Orin not boot anymore.

3

You can assign any none conflict address under 3180000 for your case due to there’s no any physical communication for it.

1 Like
4

Hi Shane,

as soon as I change (only) the “reg” attribute of ov5693_a or ov5693_e, the system does not boot anymore. Though, this only happens when both ov5693 are active. If I only have one ov5693 sensor in my device tree with register 0x40, it works. What could be the reason?

7

If I apply the shown dts file, the Jetson does not boot anymore. If I remove one of the ov5693, it works.

8

You may need check the UART log to know why.

Thanks

9

Hi Shane,

I instead configured the second OV5693 sensor in the DTSI files to be compatible with OV9281 drivers, and then inserted a OV5693 driver, rebranded as a OV9281 driver, into the kernel during runtime.

Doing so, and having a window with sudo dmesg --follow open allowed me to see the reason for the crash.

Turns out, for some reason, the kernel tries to do something with the EEPROM of the second OV5693 sensor, which leads to a null pointer dereference. (“Failed to register i2c client eeprom_ov9281 at 0x54 (-16)”, then crashes with nullptr deref), even though the DTSI files specify “has-eeprom” as 0.

Be it as it may, commenting out all EEPROM related code (in addition to the I2C code) inside the OV5693 driver allows it to be loaded by multiple “fake” cameras, which all do not have an EEPROM and are all not connected to any I2C bus.

Cheers,
Michael