Hi,
Another problem we encoutered :
We are using 2 NVIDIA Jetsons AGX, both of them are up to date.
On the 1st one, the MAC address of eth0 isn’t found / fixed anymore. It was eth0 : 00:04:4b:e5:a0:c4 before being lost. So at each startup it’s generating a new one (DHCP router is giving an always different IP address) and Gnome Network Manager isn’t applying fixed IP settings because the MAC address changed…
Here is the result of dmesg, comparing the 1st one and the 2nd one.
Do you know how to restore the mac address? Is it stored into the eMMC ? (I believe it’s not) or into and i2c eeprom, or something else?
By the way, on the 1st one, on which the MAC address is lost, sdkmanager is unable to flash anymore… while flashing fine on the 2nd one. I guess some information somewhere are lost or innaccessible.
As we are using devkit, I switched the connectors boards but the problem (and mac address) seems to be located in the main SoC board.
Is there a way to repair this, having informations of a 2nd board in the hands, and knowing which mac address should be restored?
Thank you in advance
Hi,
This is a very standard symptom of eeprom is either corrupted or just with wrong checksum value.
Have you ever run any i2c tool to modify anything on your devices?
I think what you should worry about now is the flash problem but not the mac address.
Please read below wiki page and dump both the host log and uart log of device during flash.
https://elinux.org/Jetson/General_debug
Hi, thanks for your answer, here is the (pretty small) log of one failed flash attempt from sdkmanager :
https://sorel.pixconfig.fr/Manual/defective.zip
The only things that seems to be talking about the error is
[ 3.2573 ] Retrieving EEPROM data
[ 3.2575 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/user/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/cvm.bin
[ 3.2588 ] MB2 Applet version 01.00.0000
[ 3.2925 ] 0000000036360018:
[ 3.3465 ]
[ 3.3488 ] tegradevflash_v2 --oem platformdetails eeprom cvm /home/user/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/cvm.bin
[ 3.3505 ] CPU Bootloader is not running on device.
[ 3.3533 ]
Error: Return value 4
Command tegradevflash_v2 --oem platformdetails eeprom cvm /home/user/nvidia/nvidia_sdk/JetPack_4.4_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/cvm.bin
Reading board information failed.
Info: [ Component Install Finished with Error ]
Info: [ 48.00 KB used. Disk Avail: 378.77 GB ]
Info: [ NV_L4T_FLASH_XAVIER_WITH_OS_IMAGE_COMP Install took 4s ]
Error: [error]: : [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FLASH_XAVIER_WITH_OS_IMAGE_COMP.sh; [error]:
Don’t know if you can take a look and collect more details.
However for the UART log during flash (though micro USB port I guess), I will need to access back the board, but it’s currently in use by some co-workers in a different city.
It’s not impossible that i2c tools were used by wo-workers, even if not confirmed as they believe the problem with MAC address started before the use of i2c tools.
Is it possible to use I2C tools to read the working EEPROM for our working another board, and then to put it back to the defective one? Of course changing the mac address (mandatory before connecting both of them to the same local network) will need to recompute the CRC checksum (by coding a little program or script it should be ok).
Hi,
If your board is still able to boot up, then your method would work.
Thanks
Do you know which command/address or even size should be used to read/write the EEPROM?
I will have to be extremely careful about when firing any i2c command on the working board! ;)
By the way, here is the full bash history of the defective board. I’m not an expert of i2c commands but I’m not able to see if one of them could have been harmful for the EEPROM data (i2cdetect and i2cget commands only). Will try to learn those commands before doing it my turn.
sudo -i
sudo ./ueye_4.93.0.986_arm64.run
apt install synaptic
sudo apt install synaptic
sudo apt install qt5-default
sudo apt install qtcreator
sudo apt install vino
sudo ln -s ../vino-server.service \ /usr/lib/systemd/user/graphical-session.target.wants
gsettings set org.gnome.Vino prompt-enabled false
gsettings set org.gnome.Vino require-encryption false
gsettings set org.gnome.Vino authentication-methods "['vnc']"
sudo ln -s ../vino-server.service \ /usr/lib/systemd/user/graphical-session.target.wants
cd /
sudo ln -s ../vino-server.service \ /usr/lib/systemd/user/graphical-session.target.wants
ls
cd srv
ls
cd ..
cd usr
cd lib
cd systemd
cd user
ls
cd graphical-session.target.wants/
sudo ln -s ../vino-server.service \ /usr/lib/systemd/user/graphical-session.target.wants
sudo ln -s ../vino-server.service /usr/lib/systemd/user/graphical-session.target.wants
sudo -i
xrandr --fb 1280x1024
cd /
ls
sudo apt-get install rabbitvcs-nautilus
mkdir -p ~/.local/share/nautilus-python/extensions
cp /usr/share/nautilus-python/extensions/RabbitVCS.py ~/.local/share/nautilus-python/extensions
nautilus -q
cd ~/.local/share/nautilus-python/extensions
ls
open rabbitvcs.py
open -a ./rabbitvcs.py
open -t ./rabbitvcs.py
gedit ./rabbitvcs.py
gedit ./rabbitvcs.pyc
sudo -i
./ProjectorDoubleCamera
lstd
lspci
lspc
lspcl
lshz
lshqw
lshw
man i2cdetect
lspci
lsblk
i2cdetect -l
ls
cd
i2cdetect -l
ifconfig
ipconfig
ifconfig -a
hostname -I
ifconfig -a
ipconfig
ifconig
ifconfig
hostname -I
ip
ip addr show
hostname -I
i2cdetect -l
ipconfig
ifconfig
ip addr show
ipconfig
ifconfig
ifconfing
ifconfig
ipconfig
ifconfig
ip qddr shoz
ip addr show
man i2cdetect
i2cdetect -l
i2cdetect -V
lspci
lshw
hwinfo
lsscsi
lsusb
i2cdetect 0
ifconfig
ip addr show
i2cdetect -l
i2cdetect -F
i2cdetect -F i2c-3
i2cdetect -F i2c
i2cdetect -F i2cbus
i2cdetect -F /dev/i2c-0
i2cdetect -F i2c-3
i2cdetect -F
i2cdetect -F 0
i2cdetect -F 5
i2cdetect -F 2
i2cdetect -F 5
i2cdetect -F 4
i2cdetect -l
chmod +rwx /dev/i2c-4
sudo chmod +rwx /dev/i2c-4
i2cdetect -F 8
i2cdetect -l
i2cdetect -F 8
ifconfig
i2cdetect -l
i2cdetect -y -r 2
i2cdetect -y -r 8
i2cdetect -y -r 1
ifconfig
i2cdetect -y -r 8
i2cdetect -y -r 0
i2cdetect -y -r 1
i2cdetect -y -r 8
i2cdetect -l
dmesg
dmesg --file /dev/i2c-8
dmesg --file "/dev/i2c-8"
dmesg --level=err,warn
i2cdetect -y -r 8
ifconfig
sudo i2cdetect -y -r 8
sudo i2cdetect -y -r 1
sudo i2cdetect -y -r 0
sudo i2cdetect -y -r 8
cd /sys/class/
ls
cd gpio/
ls
sudo i2cdetect -y -r 8
sudo i2cdetect -y -r 1
sudo i2cdetect -y -r 0
sudo i2cdetect -y -r 8
cd
ls
cd ..
ls
cd ..
ls
cd root/
sudo cd root
cd root
sudo
su
d,esg
sudo i2cdetect -y -r 8
sudo apt-get install libi2c-dev
sudo apt-get install i2c-tools
ifconfig
sudo i2cdetect -y -r 8
sudo i2cdetect -y -r 1
sudo i2cdetect -y -r 8
sudo i2cdetect -y -r 0
sudo i2cdetect -y -r -q 8
sudo i2cdetect -y -r 8
sudo i2cdetect -y -q 8
i2cdetect 0
i2cdetect 8
ifconfig
i2cdetect -y 8
i2cdetect -y -r 8
i2cget 8 0x2d 0x11
i2cdetect -y -r 8
sudo apt-get install qtdeclarative5-dev
i2cdetect -y 8
qmake --version
sudo apt-cache search at
sudo apt-cache search qt
sudo apt-cache search libqt
sudo apt-get install libqt5quick5
sudo apt-cache search qtquick
sudo apt-cache search qt512
ip a
ip q
ip a
sudo -i
dmesg
sudo -i
ip a
netstat -nlp
I hope this is not an hardware issue, I’ll call my co-workers to have more information about what they did or tried.
Thanks again
Hi,
i2cset and i2cdump could be used to write and read the eeprom value.
Hi and thanks, but do you know which i2c bus or address?
Hi,
sudo i2cdump -y 0 0x50 will dump the eeprom.
Many thanks ! I’ll keep you informed
I have access to the working one through VPN so I may be able to dump the eeprom now.
I may wait tomorrow to access and look at the content of the defective one first, just to see everything possible before doing any i2c command on the working one
Have a nice day
My coworker sent me the content of the defective EEPROM (left of the picture)
Indeed the checksum at the end (which is 0x3b into the eeprom) is incorrect
On the right of the picture, the correct eeprom from our second board
The checksum at the end (which is 0x94 into the eeprom) is correct
In any case you are right, this is actually corruption of the EEPROM with incorrect checksum.
We can see that the mac address is still OK (byte[172 and following ones, in reverse order) but I’m not sure of what is wrong into the rest of the data.
Are you able to figure out which information can be kept, and which one should be overwritten?
Defective one :
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 34 35 34 36 35 34 00 00 04 4b 00 00 00 00 00 00 454654..?K......
10: 00 00 00 00 36 39 39 2d 38 32 38 38 38 2d 30 30 ....699-82888-00
20: 30 34 2d 34 30 30 20 4b 2e 30 00 00 00 00 00 00 04-400 K.0......
30: 32 32 33 ff 35 ff ff ff ff ff ff ff ff ff ff ff 223.5...........
40: ff ff ff ff c4 a0 e5 4b 04 00 31 34 32 31 32 32 ....???K?.142122
50: 30 30 33 31 36 37 33 00 00 00 00 00 00 00 00 00 0031673.........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 69 ...............i
70: 00 00 00 00 74 65 74 55 00 00 00 00 00 00 00 00 ....tetU........
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 4e 56 43 42 1c 00 4d 31 00 00 ......NVCB?.M1..
a0: ff ff ff ff ff ff ff ff ff ff ff ff c4 a0 e5 4b ............???K
b0: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b ...............;
Working one :
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 01 00 ff 00 48 0b 04 00 04 4b 00 00 00 00 00 00 ?...H??.?K......
10: 00 00 00 00 36 39 39 2d 38 32 38 38 38 2d 30 30 ....699-82888-00
20: 30 34 2d 34 30 30 20 4b 2e 30 00 00 00 00 00 00 04-400 K.0......
30: 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
40: ff ff ff ff 10 92 e5 4b 04 00 31 34 32 31 32 32 ....???K?.142122
50: 30 30 32 38 36 39 39 00 00 00 00 00 00 00 00 00 0028699.........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 4e 56 43 42 1c 00 4d 31 00 00 ......NVCB?.M1..
a0: ff ff ff ff ff ff ff ff ff ff ff ff 10 92 e5 4b ............???K
b0: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 ...............?
I have confirmation by my team that the mac address defect appeared before doing anything with i2c (and what they did with i2c GPIO was successful)
Hi,
Why not just follow the eeprom layout document and recalculate a new checksum based on current eeprom value?
If information from the EEPROM is wrong somewhere and likely to cause problems, I’m not sure that making the checksum “ok” again is a good idea, before being sure that the data is actually correct?
Thanks for the document I’l try to read Jetson TX1-TX2 Module EEPROM Layout (I don’t see any AGX document, is TX1-TX2 right?)
Hi,
Below info between the working one and non-working one should be totally same.
byte 20–49 → this one is the most important.
150–153
154–155
156–157
The rest could be different.
Many thanks !
I repaired the data. The checksum was correct, it was the data which was incorrect.
By repairing bytes [0 to 7], [48 to 49], [111], [116 to 120], [50 and 52] (copying from the working one), I was able to have something identical for the 2 eeprom, appart from tracking number and mac address.
And the checksum at the end 0x3B is correct without having to be changed
This is why I didn’t want to recompute the checksum ;)
Many thanks for your help. We’ll have to rewrite it with i2cset (using correct format) but let’s consider the defective board is probably saved now.
0x01 0x00 0xff 0x00 0x48 0x0b 0x04 0x00 0x04 0x4b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x36 0x39 0x39 0x2d 0x38 0x32 0x38 0x38 0x38 0x2d 0x30 0x30
0x30 0x34 0x2d 0x34 0x30 0x30 0x20 0x4b 0x2e 0x30 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xc4 0xa0 0xe5 0x4b 0x04 0x00 0x31 0x34 0x32 0x31 0x32 0x32
0x30 0x30 0x33 0x31 0x36 0x37 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x4e 0x56 0x43 0x42 0x1c 0x00 0x4d 0x31 0x00 0x00
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xc4 0xa0 0xe5 0x4b
0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3b
To close this thread, the problem is now solved.
Using a bunch of i2cset commands (i2cset -y 0 0x50 0x00 [firstbyte], i2cset -y 0 0x50 0x01 [secondbyte], and so on for the 256 bytes - using a script) the EEPROM have been reflashed with correct data and the mac address is now back :)
Every member of the team who worked on this board is insisting on the fact that the mac address problem appeared before having used any i2c devices or command on the board, which means that it may be something unstable about it. Don’t know if this problem is a recurrent one, or what is causing it.
Bye and thank you again WayneWWW for your help
PS : one of my coworkers found this page, which is giving a lot more details about the meaning of each byte, and even the code which should be used to recompute the checksum after a data change
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fjetson_eeprom_layout.html%23wwpID0EPHA
1 Like
