SIPL I2C Virtual Address Assignment

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Hi NVIDIA team,

I have a couple of questions regarding the SIPL camera configuration for a camera setup:

  1. Continuous Address Configuration (0x08–0x0F) for Multiple Deserializers & I2C Buses We are using 16 cameras distributed across two I2C buses, with two deserializers per bus (4 deserializers total, each handling 4 cameras). The Camera HAL defaults to resetting the virtual address range to 0x08–0x0B for each block, causing address overlaps. How should we properly configure the platform configuration and I2C/deserializer settings to achieve a continuous or non-conflicting address range across these blocks?

  2. Maximum Camera Limit What is the maximum supported camera count under the standard SIPL architecture?

Thanks for your help!

4

hello owenturing1224,

>> Q1
please see-also developer guide, Virtual Address Translation.

Sensor id values must be unique and sequential within a platform config. Even when multiple deserializers are present, no two sensors may share the same id.
as mentioned by Best Practices. Sequential sensor IDs: Sensor id values must be unique across the entire platform config, even across different device blocks. Use non-overlapping ranges (for example, 0–3 for the first deserializer, 4–7 for the second).

>> Q2
for SIPL/CoE configuration, it supports up-to 16 cameras through 8 HSBs, with 2 cameras per HSB. you may see-also Release Notes (r39.2.1).
for SIPL/GMSL configuration, the limitation come from GMSL links per deserializer, CSI routing, virtual channels. in theory, each MIPI brick can support up-to 16 VC’s.

5

Hello JerryChang

I understand that sensor IDs must be unique and sequential across the entire platform configuration, including across multiple deserializers

However, I would like to clarify whether this requirement is directly related to the I2C Virtual Address allocation issue that originally reported

Our hardware configuration consists of:

  • Two physical I2C buses, each connected to two MAX96724 deserializers.
  • Up to four serializers connected to each MAX96724
  • Globally unique sensor IDs (0–15), as observed in our SIPL configuration.

To investigate the issue further, I added debug logging to the serializer driver to inspect the address translation table provided by Camera HAL

Specifically, I retrieved the virtual address corresponding to the serializer’s physical I2C address (0x40) from context.config.addressTranslations

The following virtual addresses were reported for nine active camera modules:

# I2C-2 Bus
GMSL Port 1: 0x0A, 
GMSL Port 2: 0x0A, 0x0E,

# I2C-9 Bus
GMSL Port 3: 0x0A, 0x0E, 
GMSL Port 4: 0x0A, 0x0E, 0x12, 0x16

These values are taken directly from the address translation entries provided by HAL

What concerns me is that the same virtual addresses appear to be assigned to serializers behind different deserializers, including deserializers sharing the same physical I2C bus

Based on this observation, I would appreciate clarification on the following points:

  1. Does the sensor ID affect the I2C Virtual Address allocation process, or is the requirement for unique sensor IDs independent of VA allocation?
  2. Does Camera HAL maintain a shared virtual address reservation pool for all deserializers connected to the same physical I2C adapter, or is the allocation handle independently for each deserializer?
  3. Is reusing the same virtual address across different deserializers on the same I2C bus expected behavior, perhaps due to link-specific I2C routing, or should these addresses be unique?

My understanding from the Virtual Address Translation documentation is that Camera HAL is responsible for assigning virtual addresses and providing the resulting translation table to the serializer driver.

Therefore, I would like to understand how HAL prevents address conflicts when multiple deserializers share the same physical I2C adapter.

I have also attached our current SIPL JSON configuration file for your reference.

Could you please review the configuration as well and let me know if there are any issues or settings that might affect the I2C Virtual Address allocation behavior?

I would greatly appreciate your assistance in reviewing both the configuration and the observed behavior

Thank you again for you continued support

thor_t5000_sipl_configuration.zip (1.6 KB)

6

Hello JerryChang

I attached wrong query json file to you

I’ve attached correct sipl json configuratin now

I’m so sorry

thor_t5000_sipl_config_20261015.zip (1.5 KB)

7

actually, it’s recommend have one deserializer per independent I2C bus for the current CameraHAL implementation.

8

Thank you for the clarification

I understand that the current CameraHAL implementation recommends using one deserializer per independent I2C bus.

However, our hardware platform(exactly ASUS’s PE3001N) has already been designed with two MAX96724 deserializers sharing a single physical I2C bus, so changing this hardware topology would be difficult at this stage

Given this limitiation, I would like to ask two additional question:

  1. Are there any plans to update CameraHAL to support a shared I2C virtual address reservation pool across multiple deserializers connected to the same physical I2C bus?
    In particular, we would like to know whether a future JetPack release will support globally coordinated virtual address allocation within the same I2C adapter to prevent address conflicts.
  2. Would NVIDIA be able to provide a customized CameraHAL implementation or patch that supports our existing hardware topology?
    Ideally, we would like to retain our current hardware configuration while ensuring that virtual addresses are allocated and reserved correctly across multiple deserializers sharing the same I2C bus

If a customized CameraHAL cannot be provided directly, we would also appreciate any guidance on possible modifications or alternative approaches to support this configuration

Thank you again for your continued support