Cboot other mux type


could you consider implementing second type of mux in cboot? For example, TCA9548 which has 8 channels.

As cboot, most of the time isn’t released with other sources it would be great to have that implemented, otherwise, you are depriving us of using more than 4 ch (statically defined in cboot) with plugin manager functionality.

Is cboot going to be released within L4T Sources as we could see for Xavier or it will be a standalone package?

Thank you.

Do you mean enabling another GPIO expander in cboot?


no, just adding support for new type of mux.

For example in tegrabl_eeprom_manager.c there are those defines:
#define I2C_MUX_TYPE_TCA9546A 1
#define I2C_MUX_TCA9546A_MAX_CHANNEL 4

and in function
static tegrabl_error_t tegrabl_read_muxed_eeprom(uint8_t old_count,
uint8_t *new_count)
you are configuring multiplexer…

it would be great if you could implement support for mux I mentioned (8ch support).
For example if the value in EEPROM on CAM_I2C bus on byte that represents type of the mux is “2” it would read through 8 channels of multiplexer and not only 4.

Now that value must be “1”, and will read only though 4 mux channels.

I can check this and see if we can implement.
Any purpose to use such design?

You could consider 6x2CSI Image sensors(imagine different sensors).

If you only parse 4mux ch you are losing image sensor EEPROM information on the last two sensors. Hence, deprived of full plugin manager feature.

This feature is very valuable, especially in development purposes where you could have “plug&play” functionality. Without it you are destined to use static device tree implementation.

Usually EEPROM can connect to the tegra i2c instead of after the i2c MUX for the plugin manager for the auto detect.
And bootloader can read the EEPROM to override the device tree to support the auto detected.

yes, but this is like a common info. And if you change image sensors or change the order, all falls.

You could have all infos on that common EEPROM but you have to have a specific override for that ID. This is essentially mapping static device tree and overlay 1:1.

If you take a look at this picture, ID on image sensor EEPROM and device tree overlay consists of “ImageSensor-MuxCh”. Then you could override a specific image sensor on a specific port.
If you decide to change the order you just change “MuxCh” on EEPROM and everything should work if using plugin manager.

And if you have a structure like this, parsing only 4ch of mux is not enough.

From this picture you can see the EEPROM didn’t connect to the MUX.
For the auto detect you just need to make sure the EEPROM can access from bootloader to override the device tree and pass to kernel to handle the MUX things.

Yes, you are right, EEPROM 0x54 is connected to tegra I2C, and it is labeled here as “common” on picture, and could consists of some common ID (common override), i2c address of mux, type of mux, and other things.

EEPROM 0x57 sits on mux I2C and is on sensor board. It is expected to have ID of sensor on that board.

You wouldn’t need 0x57 EEPROM if you have few sensor configuration. You could write that configuration ID to 0x54 EEPROM and it would be auto detected. But, if you aproach this in a modular way (changing sensors order/type of sensors) you have to have 0x57 EEPROM. The only thing you would need to do is write correct 0x57 EEPROM ID (sensor-muxCh) if you configured you device tree(static description and overrides) for this type of sensor.

On the end, talking from perspective of a developer it would be beneficial to implement second type of mux and cover this structure on the day of the L4T release as well.

Thank you.

Do you mean your design have multiple EEPROM for each sensor detect?


One is on “Camera Interposer Module” which sits on tegra I2C, 0x54, and one EEPROM for each Sensor board (eg. labeled as CAM#1 on picutre). Sensor board I2C busses are connnected to mux channels.

Hi ShaneCCC,

could you gave me some answers on this topic. Could we expect implemenation of second type of mux in cboot by default? If yes, for which release? Would all platform include that?


Sorry to tell It could be difficult to enable the driver didn’t for the device didn’t mount on reference board.