I have a question about the EEPROM. On our custom carrier board, when powering on, the first byte of the CVM EEPROM (I2C 0, address 0x50) gets cleared to 0. It does not occur during reboot. What could be causing this issue?
After powering off on the custom carrier board and then powering on using the devkit carrier board, this problem does not occur.
*** Please note that this reply is generated by LLM automatically ***
To address the issue of the first byte of the CVM EEPROM at I2C 0 address 0x50 getting cleared to 0 on your custom carrier board when powering on, let’s break down the potential causes and compare the behavior with the devkit carrier board.
-
Power Sequencing and Reset: The
SYS_RESET*signal, which is driven by the Power Sequencer or PMIC during power-up, could potentially affect the EEPROM. If the power sequencing on your custom carrier board differs from that of the devkit carrier board, it might cause the EEPROM to be accessed or modified unexpectedly during the power-on sequence. TheSYS_RESET*signal is crucial as it indicates when the system is in a reset state, and improper handling could lead to unexpected behavior. -
Power Supply and Voltage: The main power supply (
VDD_5V_SYS) and how it is managed on your custom carrier board compared to the devkit carrier board could be a factor. If there are differences in how power is supplied or sequenced, it could affect the operation of the EEPROM. Specifically, theVDD_INcomponent, which is the total module power and is expected to be 5V on the developer kit carrier board, should be verified on your custom board. -
I2C Bus and Signal Integrity: The integrity of the I2C bus signals on your custom carrier board might be compromised, leading to spurious writes or clears during power-on. This could be due to improper termination, noise on the lines, or other signal integrity issues. Comparing the I2C bus layout and signal quality between your custom board and the devkit carrier board might reveal differences.
-
Carrier Board EEPROM vs. Module EEPROM: The behavior of the EEPROM on your custom carrier board versus the devkit carrier board might also depend on how the carrier board’s EEPROM and the module’s EEPROM interact. The carrier board EEPROM contains the carrier board’s serial number and part number, while the module EEPROM contains similar information for the module. Differences in how these are accessed or initialized during power-on could be relevant.
-
Software or Firmware Interaction: Although less likely given the context of the issue occurring during power-on, any software or firmware that interacts with the EEPROM could potentially cause the observed behavior. This might include bootloaders or early system initialization code that accesses the EEPROM.
-
Hardware Design Differences: Any differences in the hardware design between your custom carrier board and the devkit carrier board, such as the presence of specific components (e.g.,
M.2 Key E Socket,M.2 Key M Socket (4-lane),M.2 Key M Socket (2-lane)) or the layout, could affect the operation of the EEPROM.
To troubleshoot this issue, consider the following steps:
- Verify the power sequencing and reset signals on your custom carrier board to ensure they match the expected behavior of the devkit carrier board.
- Check the power supply and voltage levels to the EEPROM and ensure they are within specifications.
- Inspect the I2C bus for any signal integrity issues.
- Compare the EEPROM access and initialization code (if any) between your custom setup and the devkit carrier board.
- Review the hardware design for any differences that could affect the EEPROM’s operation.
Given the information provided, it’s clear that the issue is specific to your custom carrier board and does not occur with the devkit carrier board. Thus, the comparison and troubleshooting should focus on identifying the differences in design, implementation, or operation between these two boards.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi chinchen.lin,
What’s the Jetpack version in use?
What’s the first byte before you think it gets cleared to 0?
Would it affect any functionality?
I am using Jetpack 6.2.
I powered on the custom carrier board to confirm the power supply (the board’s indicator light turns on), and immediately cutting off the power causes the issue.
It affects the need to specify the MAC address for the network interface when entering the system.
Do you cut off the power manually?
How do you know the byte in EEPROM affecting MAC address for network?
Do you cut off the power manually?
yes
How do you know the byte in EEPROM affecting MAC address for network?
Is the issue specific to your custom carrier board?
The EEPROM of CVM should included in the module itself. I think they should not be modified through power on/off.
Could you elaborate on this?
Do you mean that you can’t get MAC address through ifconfig eno1?
Is the issue specific to your custom carrier board?
Yes, this issue does not occur on the devkit’s carrier board.
Could you elaborate on this?
To set the MAC address of the network interface, it’s necessary to use nvidia,mac-addr-idx = <0> in the device tree. The reason for the failure appears to be that /chosen/nvidia,ether-mac0 cannot be set during the MB2 stage. After reviewing the EEPROM layout and running i2cdump -f -y 0 0x50, I found that the first byte was not 0x02 as expected for the AGX Orin I’m using. I then modified it using i2cset -f -y 0 0x50 0 0x02 to set it to the correct Orin value. After rebooting, the MAC address could be retrieved successfully.
However, when I use shutdown or poweroff and then power the device back on, this byte reverts to 0x00. Through testing, I found that this issue only occurs when the system is powered on after being shut down—not when using reboot.
Thanks for your information.
Could you compare the logs(serial console log and /var/log/syslog) in both cases(shutdown and reboot)?
Maybe there’s the custom service modifying the first byte in some case?
Please also check if this issue happens on each of your board.
This issue only occurs during power-on, and it happens on every board before any messages appear on the debug port.
Could you help to clarify it happens in which part of boot up?
You can get a scope to measure I2C bus and check the full serial console log at the same time.
I tried using a brand new, unflashed AGX Orin to boot on our carrier board first, and then moved it to the DevKit for flashing. During the process, the following error appeared:
bad mac address at /chosen/nvidia,ether-mac0: NULL.
After the flashing was completed, I used i2cdump -f -y 0 0x50 to confirm that the first byte had changed to 0.
Is the first byte modified by your custom board so that you got first byte as 0 after you flash/boot on the devkit?
What’s the first byte if you put it on the devkit and perform flash and reboot?
Is the first byte modified by your custom board so that you got first byte as 0 after you flash/boot on the devkit? yes
If I write the first byte back to 0x02 and then re-flash and reboot the module on the DevKit, the first byte does not change to 0.
It’s weird that your custom board will modify the EEPROM inside the CVM.
Could you try to disable i2c@3160000 in kernel device tree to clarify if it may modify it from kernel?
Do you have other custom carrier boards and all of them have similar issue?
Because our carrier board has an MCU that controls the power, I suspect it might be related to the Power On Sequence. Are there any ways to check this?
Since it also happens even without flashing the Linux system, this possibility can be ruled out.
yes
Do you mean MCU connected with AGX Orin through I2C interface?
If so, you can try to measure if there’s I2C data during boot up.
Or you can simply remove MCU to clarify if it is caused from your MCU.
What do you mean about “even without flashing the Linux system”?
EEPROM is connected on the following I2C bus 0. I would suggest you measure the signal on this bus to clarify when it gets configured.
Bus 0: /dev/i2c-0 => i2c@3160000 (&gen1_i2c: nvidia,tegra234-i2c) => I2C1/I2C2 (PI.03/PI.04): Custom 1.8V I2C devices
Our MCU is used to replace the reference board MCU for Power Sequence, but it also includes some other features that we need.
It’s a completely new SOM.
Do you mean the button MCU?
We are not clear about why you want to switch the MCU.
My suggestion is just to clarify if the issue is caused by the custom MCU in your case.
Or you need to check with your vendor for the logic inside that MCU.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.