I am suddenly unable to flash my Jetson TX2. It was working great but now it fails to flash on 'Retrieving EEPROM data. The line is:
[1.0946] ‘tegradevflash_v2 --oem platform details eeprom cvm /home/user/JetPack-L4T/Linux_for_Tegra/bootloader/cvm.bin’
[1.0955] CPU Bootloader is not running on device
Error: Return value 4
Command tegradevflash_v2 --oem platform details eeprom cvm /home/user/JetPack-L4T/Linux_for_Tegra/bootloader/cvm.bin
Reading board information failed.
Originally I was using Jetpack 3.2.1 with the Connect Tech support packages for the Elroy carrier and using flash.sh. Note: I have 7 Jetson TX2s and all others are working fine - this issue only appeared on this one board.
I have tried the following, all with two separate USB to micro-USB cables on every USB port on my computer:
- Fresh install of Jetpack 3.2.1 flash through UI and through script
- Add connect tech packages to new 3.2.1 install and try to flash through script
- Fresh install of Jetpack 3.3 flash through UI and through script
- Add connect tech packages (v119) to new 3.3 install and try to flash through script
When none of these worked, I formatted my hard drive and performed a fresh install of Ubuntu 16.04 LTS and repeated these steps.
I am not running a virtual machine, Ubuntu is installed natively.
Any help would be much appreciated.
stephensampson,
Is that TX2 able to boot up? Could you boot it up and dump below value?
If you ever modified the value in this EEPROM, it may affect the flashing.
sudo i2cdump -y 7 0x50
EEPROM has never been modified. The flashing utility was working perfectly; I had flashed the board earlier the same day. We are working on some initialization automation so we re-flash and start from scratch fairly regularly. Suddenly it just started giving this error.
Running the command mentioned above:
sudo i2cdump -y 7 0x50
displays ‘XX’ in all of the memory address locations.
In fact, running a probe on this bus:
>sudo i2cdetect -y -r 7
does not detect any I2C devices on this bus. In each location it lists ‘–’. Probing other buses (such as bus 0) I can see devices and can dump their memory successfully.
Duplicate reply. Removed.
I got my hands on another dev board this evening and it flashes successfully. It appears as if the I2C bus or EEPROM ‘device’ have malfunctioned on that board. I will see if I can start an RMA process for it.
Yes, looks like the eeprom on tegra is broken… Please file an RMA process.
Sorry about that.
Hi, I have an issue at the same i2c address. On our custom board, i2c7 is connected to a device which also has an address at 0x50, which is the same as the CVM eeprom address. This seems to be the cause of issues such as the tx2 deciding to power down. How does Tegra use the eeprom?
A temporary fix, is to disconnect the device during power-on and reconnect later. But I worry that Tegra may access the eeprom again. What would be a suitable solution to this problem?
Did you mean you place a new EEPROM on your device? or you put something else on it? I cannot share all the detail about how tegra use eeprom. It is not necessary for you to know all of that. What you should know is the eeprom content should follow up the EEPROM layout document in our download center.
I wonder why there is “power down” case. Are you able to share the kernel log?
To be honest, I would suggest not to use such device on i2c7. Tegra would access eeprom during flash and boot up.
It is unfortunate that the current board layout means that the device, an SFP, is using i2c7 and an address of 0x50, hence the conflict. Would rather not have to redesign the layout. However if Tegra doesn’t access eeprom again after flash and boot up, then we can avoid the problem.
Could you confirm whether Tegra accesses the eeprom again after boot-up?
Thanks
Tegra only accesses this eeprom during boot up.
