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.
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.
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!
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:
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.
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.
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?
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 :)