Hi,
In some of my Xavier nx boards serial number is present at device tree, but in some other one is not!
I know, I can read serial number from EEPROM, but I need to read it from the device tree.
Is the serial number added to the device tree at boot time, by boot loader?
How can I enable this function into the boot loader?
Thanks
Lachini.
Please share the boot up log of these two kinds for comparison.
Hi,
Looks like you don’t know how to dump serial console log. Please read this link and dump the logs again.
Oh!
I’m so sorry for the mistake of reading log word ( I’m read Logo!).
serial-ok-log.txt (66.7 KB)
serial number OK.
serial-nok-log.txt (67.9 KB)
serial number not OK!
Hi,
Did you ever change the eeprom content of the NG module ?
I just checked the log from NG one, even the ethernet is not working.
7.725062] ether_get_mac_address_dtb: bad mac address at /chosen/nvidia,ether-mac: NULL.
[ 7.732110] hpd: state 7 (Takeover from bootloader), hpd 0, pending_hpd_evt 1
[ 7.736884] nvethernet 2490000.ethernet: No MAC address in local DT!
[ 7.744786] hpd: switching from state 7 (Takeover from bootloader) to state 0 (Reset)
[ 7.750690] nvethernet 2490000.ethernet: failed to get MAC address
[ 7.751654] nvethernet: probe of 2490000.ethernet failed with error -22
This is a typical error to module EEPROM as mac address and serial number are read from it.
Hi,
Yes, I got the following error while running the flash.sh script:
[ 4.1238 ] tegrarcm_v2 --reboot recovery
[ 4.1243 ] MB2 Applet version 01.00.0000
Parsing board information failed.
So I ran the following command:
./chkbdinfo -r cvm.bin
ERROR: calculated CRC8 0x48 != stored CRC8 0xff
So I modified the CRC8 value to fix the problem.
OK. So does the serial number and ethernet come back now?
No,
Is it possible that the reason for this issue is wrong information of EEPROM itself?
And where can I find the correct information of my EEPROM?
What is the result of this command on your NG Jetson?
$ sudo i2cdump -y 0 0x50
This should dump the EEPROM content.
$ i2cdump -y 0 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 01 00 fc 00 54 0e 01 00 03 4c 00 00 00 00 00 00 ?.?.T??.?L......
10: 00 00 00 00 36 39 39 2d 31 33 36 36 38 2d 30 30 ....699-13668-00
20: 30 31 2d 33 30 31 20 4c 2e 30 00 00 00 00 00 00 01-301 L.0......
30: 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
40: ff ff ff ff 71 2c 00 66 6d 3c 31 34 32 31 38 32 ....q,.fm<142182
50: 34 33 32 37 32 35 32 00 00 00 00 00 00 00 00 00 4327252.........
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 71 2c 00 66 ............q,.f
b0: 6d 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 m<..............
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 07 ...............?
for serial number OK!
Are you sure the checksum change you made is on this module?
You told us the checksum should be 0x48 but the value in this eeprom is not 0x48
$ i2cdump -y 0 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 18 00 fc 00 54 0e 01 00 03 42 00 00 00 00 00 00 ?.?.T??.?B......
10: 00 00 00 00 36 39 39 2d 31 33 36 36 38 2d 30 30 ....699-13668-00
20: 30 31 2d 33 30 30 20 42 2e 30 00 00 00 00 00 00 01-300 B.0......
30: 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
40: ff ff ff ff e9 e0 50 2d b0 48 31 34 32 33 32 32 ....??P-?H142322
50: 31 30 31 36 38 30 33 00 00 00 00 00 00 00 00 00 1016803.........
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 e9 e0 50 2d ............??P-
b0: b0 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?H..............
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 48 ...............H
For not OK!
The serial number is still there. But not sure why it cannot get read.
We need to enable more logs to see what is going on
Method 1. rebuild the rel-35 UEFI to debug version and flash the board. Dump the serial console log again.
Method 2. Flash the board with rel-32 release (jetpack4) and dump the log again.
I think method 2 is easier so maybe you could try that first.
new_uefi_dbg_nok_serial_log.txt (130.4 KB)
Log for uefi debug enabled!
Hi,
I notice 2 errors.
cvb Eeprom Product Id: 699-13449-0000-400 D.0
ValidateEepromData: Invalid version in eeprom 18
Cvm Eeprom data validation failed
Please read the document
The first byte from your eeprom is wrong.
“18” should not be there.