TX2NX corrupted EEPROM

Hnil.DN · October 24, 2022, 10:37am

Hi,
I’m using JP 4.5.1, TX2 NX module.
After received the module from store, I do first flashing JP 4.5.1 image.
But I found that the EEPROM is totally corrupted.
By modifying flash-helper.sh script, I got eeprom binary likes this:

# hexdump cvm.bin 
0000000 0001 000d 0e34 0001 4803 0000 0000 0000
0000010 0100 0000 3936 2d39 3331 3336 2d36 3030
0000020 3130 332d 3030 4820 302e 0000 0000 0000
0000030 0000 ff7f ff7f ff7f ff7f ff7f ff7f ff7f
0000040 ff7f ff7f 4c4f 2d3b 4830 3431 3132 3236
0000050 3031 3336 3439 0033 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000090 0000 0000 0000 564e 4243 001c 314d 0000
00000a0 ff7f ff7f ff7f ff7f ff7f ff7f 4c4f 2d3b
00000b0 4830 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
*
00000f0 0000 0000 0000 0000 0000 3834 0032 a504
0000100

But when reading eeprom via I2C after boot, the EEPROM is:

# i2cdump -y 7 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 0d 00 14 0e 01 00 03 08 00 00 00 00 00 00    ?.?.???.??......
10: 00 01 00 00 16 19 19 0d 11 13 16 13 16 0d 10 10    .?..????????????
20: 10 11 0d 13 10 10 00 08 0e 10 00 00 00 00 00 00    ??????.???......
30: 00 00 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f    ..??????????????
40: 1f 1f 1f 1f 0f 0c 1b 0d 10 08 11 14 12 11 16 12    ????????????????
50: 11 10 16 13 19 14 13 00 00 00 00 00 00 00 00 00    ???????.........
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 0e 16 03 02 1c 00 0d 11 00 00    ......?????.??..
a0: 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 1f 0f 0c 1b 0d    ????????????????
b0: 10 08 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 14 18 12 00 04 05    ..........???.??

It looks like the CVM binary is correct, but I2C reading isn’t?

I tried to write the EEPROM from CVM binary, using python SMBUS I2C library. The writing went fine, no error.
But the eeprom data is still the same.

How can I recover the SoM EEPROM? Thank you so much.

JerryChang · October 25, 2022, 2:38am

hello HnilND,

may I know how you flash the target? flash script will have USB communication to check eeprom for the board information before image flashing.
so, it should be okay if you’re able to flash the target.

BTW,
please try adding -f options to force access to the device even it’s busy.
for example, $ sudo i2cdump -f -y 7 0x50

Hnil.DN · October 25, 2022, 2:30pm

Hello Jerry,

I flashed using flash.sh with command, of course via USB communication with recovery mode:

sudo BOARDID=3636 FAB="300" BOARDSKU="0001" BOARDREV="" ./flash.sh jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

This bypass eeprom checking. However, the eeprom has invalid CRC if I don’t bypass the checking:

[   2.1185 ] Retrieving EEPROM data                                                                                                                                                                          
[   2.1186 ] tegrarcm_v2 --oem platformdetails eeprom cvm /work/works/tools/nvidia_sdk/sdk/JetPack_4.5.1_Linux_JETSON_TX2_NX/Linux_for_Tegra/bootloader/cvm.bin                                              
[   2.1193 ] Applet version 01.00.0000                                                                                                                                                                       
[   2.2095 ] Saved platform info in /work/works/tools/nvidia_sdk/sdk/JetPack_4.5.1_Linux_JETSON_TX2_NX/Linux_for_Tegra/bootloader/cvm.bin                                                                    
[   2.2824 ]                                                                                                                                                                                                 
Parsing board information failed.

However, the problems are:

the CVM reading in flash script gives different EEPROM binary (from bootloader/cvm.bin) compare to reading from I2C after booted.
Write into EEPROM via I2C doesn’t affect the EEPROM.

This is when I write the byte & readback

$ sudo i2cset -f -y 7 0x50 255 0x51 b
$ sudo i2cdump -f -y 7 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 05 00 04 06 01 00 03 00 00 00 00 00 00 00    ?.?.???.?.......
10: 00 01 00 00 06 01 01 05 01 03 06 03 06 05 00 00    .?..??????????..
20: 00 01 05 03 00 00 00 00 06 00 00 00 00 00 00 00    .???....?.......
30: 00 00 07 07 0f 07 07 07 0f 07 07 0f 0f 07 07 07    ..??????????????
40: 07 07 07 07 06 07 03 05 00 00 01 04 02 01 06 02    ????????..??????
50: 01 00 06 04 00 00 00 00 00 00 00 00 00 00 00 00    ?.??............
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 06 06 03 02 04 00 05 01 00 00    ......?????.??..
a0: 0f 07 07 07 07 07 07 0f 0f 07 07 07 02 02 04 00    ???????????????.
b0: 01 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 04 00 02 00 03 01    ..........?.?.??
$ sudo i2cset -f -y 7 0x50 255 0x57 b
$ sudo i2cdump -f -y 7 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 05 00 04 06 01 00 03 00 00 00 00 00 00 00    ?.?.???.?.......
10: 00 01 00 00 06 01 01 05 01 03 06 03 06 05 00 00    .?..??????????..
20: 00 01 05 03 00 00 00 00 06 00 00 00 00 00 00 00    .???....?.......
30: 00 00 07 07 07 07 07 07 07 07 07 07 07 07 07 07    ..??????????????
40: 07 07 07 07 06 07 03 05 00 00 01 04 02 01 06 02    ????????..??????
50: 01 00 06 04 00 00 00 00 00 00 00 00 00 00 00 00    ?.??............
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 06 06 03 02 04 00 05 01 00 00    ......?????.??..
a0: 07 07 07 07 07 07 07 07 07 07 07 07 02 02 04 00    ???????????????.
b0: 01 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 04 00 02 00 03 07    ..........?.?.??

It looks like only half-byte is written, or maybe only half-byte read.

Do you have any idea to solve this? Thank you.

JerryChang · October 26, 2022, 3:10am

hello HnilND,

actually, there’re two eeprom for parsing board info, one is cvb, the other is cvm.
they’re based-on different i2c address. they’ve contain some board-specific information.
for example,

                bus@0 {
                        i2c-bus = <&gen8_i2c>;
                        eeprom@0 {
                                slave-address = <0x50>;
                                label = "cvm";
                        };
                        eeprom@1 {
                                slave-address = <0x57>;
                                label = "cvb";
                        };

are you using TX2 NX DevKits?
also, where’s your cvm.bin came from? it’ll dump and store the info as cvm.bin during image flash. flash may failed if the content is corrupted.
you may try adding SKIP_EEPROM_CHECK=1;into flash commands, this will ignore the checking.

Hnil.DN · October 26, 2022, 8:51am

Hi Jerry,

Of course we are talking about CVM EEPROM with address 0x50. My cvm.bin came from flash.sh script (see log above Saved platform info in /work/works/tools/nvidia_sdk/sdk/JetPack_4.5.1_Linux_JETSON_TX2_NX/Linux_for_Tegra/bootloader/cvm.bin)
By adding BOARDID=3636 FAB="300" BOARDSKU="0001" BOARDREV="" before flash.sh in command, it is also ignore EEPROM checking. That why I’m able to flash the firmware.

But my concern is, why the EEPROM reading by I2C is so strange? I have many TX2NX (more than 5), but only one of them has this issue.
Is there any customer having similar problem? Just to check if it can happens for other TX2NX modules in future use or not.

JerryChang · October 26, 2022, 2:11pm

hello HnilND,

it’s strange, and I’ve never see this before.
my point is… it is flash script to communicate with the board to dump and store the info as cvm.bin. if there’s failure, it might be something wrong on hardware side.

it looks like hardware issue since you’ve mentioned only one of them has this issue.
please contact the NVIDIA Customer Care team for the RMA process.
thanks

Hnil.DN · October 26, 2022, 2:59pm

Hi Jerry,
Yes, it is very strange.
The cvm.bin looks quite correct since the hardware information “699-…” string is fine and matching TX2NX info.
The I2C write looks good also (no error message, and when readback by flash.sh into cvm.bin got written value).

Just I2C reading in Linux has problem :(.
My code reads EEPROM to check if it is TX2NX or Nano and behave differently.
My company actually bought some hundreds TX2NX for production, I will check if this happens again on other boards.

We bought via distributor, RMA process takes time and need invoice/order batch. So will not go with that process.

system · November 16, 2022, 5:09am

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
"Parsing board information failed" during flash Jetson TX2 reflash	12	946	April 21, 2022
EEPROM not detected Jetson Xavier NX board-design , i2c	20	3234	December 4, 2021
MB2 still trying to read CVB EEPROM after changing misc dts Jetson Orin NX board-design , eeprom	18	187	October 8, 2024
Can't flash Jetpack3.2 on Nvidia TX2 devboard Jetson TX2	34	3149	October 18, 2021
Xavier NX Dev Kit booting problem (most likely because of I2C bus) Jetson Xavier NX boot , i2c	14	947	October 12, 2022
Cannot reflash AGX device - incorrect EEPROM values? Jetson AGX Xavier reflash , i2c	17	1390	May 2, 2022
Does Flashing a TX2NX while connected to a carrier board set up the TX2 NX for that specific carrier board? Jetson TX2 reflash	19	1005	November 24, 2022
Unable to read eeprom on tx2 nx board Jetson TX2 kernel , nvbugs	9	2378	July 28, 2021
Can't flash TX2 on a Jetson TX1 board Jetson TX2	8	1035	October 18, 2021
Flashing L4T R27.1 in TX2: UnicodeDecodeError : Reading board information failed Jetson TX2	28	4291	October 18, 2021

TX2NX corrupted EEPROM

Related topics