Eeprom fails to read when setting I2C1 to input in pinmux config, causing fail at boot

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
, , ,
1

I’m developing firmware for a orin on a custom carrier board, and i am running into some issues with the eeprom, after configuring the pinmux using the provided template.

I have configured the I2C1 as follows:

		gen1_i2c_sda_pi4 {
			nvidia,pins = "gen1_i2c_sda_pi4";
			nvidia,function = "i2c1";
			nvidia,pull = <TEGRA_PIN_PULL_NONE>;
			nvidia,tristate = <TEGRA_PIN_ENABLE>;
			nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>;
			nvidia,lpdr = <TEGRA_PIN_DISABLE>;
		};

		gen1_i2c_scl_pi3 {
			nvidia,pins = "gen1_i2c_scl_pi3";
			nvidia,function = "i2c1";
			nvidia,pull = <TEGRA_PIN_PULL_NONE>;
			nvidia,tristate = <TEGRA_PIN_ENABLE>;
			nvidia,enable-input = <TEGRA_PIN_ENABLE>;
			nvidia,io-high-voltage = <TEGRA_PIN_ENABLE>;
			nvidia,lpdr = <TEGRA_PIN_DISABLE>;
		};

However, this fails to boot the module, which results in the following error:

image
image1257×692 107 KB

From my investigation, this is caused by the two pins tristate being enabled, which is done automatically when configuring the two pins to be an input.

When manually changing the DTSI file, and changing the two pins tristate to being disabled, the orin module boots fine.

Let me know if there is any more information that you need from me or my team, regarding this issue.

2

Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!

4

hello kslo,

may I know the version of pinmux spreadsheet you used.
please also share the Jetpack release version you’re now working with.

5

Hi Jerry,

Im using revision 2.01 of the excel sheet, on Jetpack 6

6

hello kslo,

it turns out it’s gen1_i2c for checking carrier board eeprom.
for instance,

        eeprom-manager {
                data-size = <0x100>;
                bus@0 {
                        i2c-bus = <&gen1_i2c>;
                        eeprom@1 {
                                slave-address = <0x56>;
                                label = "cvb";
7

Where is this eeprom-manager defined?

Regardless, this doesn’t answer my question regarding why the eeprom can only be read, when tristate is disabled for gen1_i2c, which is automatically enabled in the excel spreadsheet.

As i am using a custom carrier board, where there is no eeprom, tegra234-mb2-bct-common.dtsi eeprom configuration looks like this:

        eeprom {
            cvm_eeprom_i2c_instance = <0>;
            cvm_eeprom_i2c_slave_address = <0xa0>;
            cvm_eeprom_read_size = <0x100>;
            cvb_eeprom_i2c_instance = <0x0>;
            cvb_eeprom_i2c_slave_address = <0xac>;
            cvb_eeprom_read_size = <0x0>;
        };

Which i would assume would completely circumvent an issue with the gen1_i2c trying to read the eeprom, if it is trying to read the carrier board eeprom.

8

hello kslo,

just double check…
did you perform image flashing completely after modify the MB2 BCT file?

9

Hi Jerry,

Yes i completed flashing the module, and it successfully booted after modifying the MB2 BCT file.

11

HI,

CVB and CVM eeprom are on the same i2c. Your error log is from CVM eeprom and you told us you disabled CVB eeprom. These two are not conflicting to each other. Your modification for that i2c pinmux just leads the CVM eeprom has some problem.

12

Hi,

That makes sense yes, however the issue still lies in:

I enabled I2C1 to be input, which automatically enabled tristate for the pins (In the excel sheet). The enabled tristate caused I2C1 to not be able to read anything, and failing the boot sequence of the module.

What should be done, in order to correctly have these pins configured, when generating the DTSI files using the excel template?

13

What is the exact purpose that you want to control this pin? My suggestion is please do not change that one to affect the behavior of cvm eeprom.

14

It is a part of our system design. For now i have configured them as bi-directional, which i suppose is the default.
This seems as it has been a mistake on my part, apologies for the confusion :)