Multi camera sensor support

[tirankas]

Hello,
I am looking to dynamically support two types of camera sensors in the same build.
I have the kernel drivers in place and dt changes as well for both devices.
Both are mipi csi (imx477 & ar1335).
My understanding is that from dt perspective they are contradicting each other, configuring i2c differently, for example.
Is there an easy, right, way of doing this?
Should I be using dt overlay for such case?
Any guide on how to achieve this?

Thanks

[madisongh]

I wouldn't say it's easy. The "right" way is to use a camera module that has an EEPROM on it that the bootloader will read to identify the module, per NV's "Camera Module Hardware Design" documents (which you can get from the download center). That, coupled with device tree files that conform to NVIDIA's plugin manager mechanism, would make camera selection automatic at boot time.

I've yet to work with a camera that does this in any of my projects, though. I have used an alternative approach, still using the plugin manager, that used the model number in my carrier board's EEPROM to decide which camera plugin to select - I had different models of a product with different cameras. This was a custom carrier, of course.

If you're using a Jetson that has U-Boot on it (e.g., a Nano), a DTB overlay would probably work, if you can decide in U-Boot which overlay to select. I haven't tried that approach, as I've only had to do this sort of thing with cboot.

[atharvanan1]

I'm curious about this. From what I see here - Using Plugin Manager, I'm not sure where the ids value is coming from. It seems that it's being read from the EEPROM on the Camera Sensor but where does it read from? My assumption is that it would need an I2C address to read that from.

Also, curious about your setup with Carrier Board EEPROM and how you have configured it.

[kekiefer]

We actually do use the eeproms on our custom boards to drive the plugin manager. Here's something I wrote up a while ago based on some review of the code (~1-2 years ago):

The format of the id field can be as such:

• exact match, ABCD-1234-00A
• less than version, <ABCD-1234-00A
• greater than or equal to version, >=ABCD-1234-00A
• wildcard version ABCD-123*

Note that LT/GTE comparison is performed only on the third field, fabid (00A in the examples above), and evaluated only if the second field is equal. In other words, a fragment with id >=ABCD-1234-00A will NOT be considered a match on a board with pn ABCD-1235-00A.

[kekiefer]

As for actually setting the ID in hardware, tegra-eeprom-tool can help you with this. The plugin manager reads the ID from eeproms detected by the bootloader, in the format that can be set by this tool.

[kekiefer]

As for where the bootloader gets these I2C addresses from, there's an eeprom-manager node in the device tree, which contains the parts the bootloader will look through to read back this information.

[atharvanan1]

Thanks Kurt! That's extra helpful! I see the eeprom-manager node now. Comment about ids field is helpful too. Thanks again.