About 2, I have successfully flashed othe Jetson machines (not Orin) from this host machine.
Hi,
Could you use i2cset to change the last eeprom value of your cvm from 0xdf to 0x8a?
The result you shared indicates it seems not correct.
Yes. I used i2c libraries including i2cset to communicate with other devices.
No… you don’t get what I mean.
There is a EEPROM on the module and flash script will read the eeprom content. Current situation is the checksum bit in the eeprom is incorrect…
In case you don’t know… I am talking about the result you shared from this.
OK. How should I use i2cset commnad?
I am experiencing the same issue. I used the following command and followed steps to flash Orin:
docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb/ -v /dev:/dev -v /media/$USER:/media/nvidia:slave --network host sdkmanager --cli install --logintype devzone --product Jetson --version 5.0.2 --targetos Linux --target JETSON_AGX_ORIN_TARGETS --flash all
But I get similar “rcm state” and “recovery mode” related errors. Weird thing is, the setup detects that device is in recovery mode but when it reaches to the flashing point it starts giving errors. It starts with this error:
│info: Start to check if in device recovery mode… │
│info: Found matching device in recovery mode. │
│error: Can not find matching device in recovery mode.
Is that really so hard to just check the manual to know how to run i2cset by yourself?
The answer is already present on there
And you dumped the eeprom content on 8/3.
@WayneWWW
I am having the same issue. I did exactly what you mentioned.
- boot while connected to console over UART.
- set the last address of eeprom (0xff) on address 0x50 to the value 0x8a
Before :
root@device-orin:~# 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: 02 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.?..
10: 00 00 00 0a 36 39 39 2d 31 33 37 30 31 2d 30 30 …?699-13701-00
20: 30 30 2d 35 30 30 20 4a 2e 30 00 00 00 00 00 00 00-500 J.0…
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
40: 00 00 00 00 e4 73 7b 2d b0 48 31 34 32 31 36 32 …?s{-?H142162
50: 32 31 32 34 34 32 33 00 00 00 00 00 00 00 00 00 2124423…
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 00 00 4d 31 00 00 …NVCB…M1…
a0: 00 00 00 00 00 00 00 00 00 00 00 00 e4 73 7b 2d …?s{-
b0: b0 48 0a 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 56 …V
after:
root@device-orin:~# sudo 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: 02 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.?..
10: 00 00 00 0a 36 39 39 2d 31 33 37 30 31 2d 30 30 …?699-13701-00
20: 30 30 2d 35 30 30 20 4a 2e 30 00 00 00 00 00 00 00-500 J.0…
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
40: 00 00 00 00 e4 73 7b 2d b0 48 31 34 32 31 36 32 …?s{-?H142162
50: 32 31 32 34 34 32 33 00 00 00 00 00 00 00 00 00 2124423…
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 00 00 4d 31 00 00 …NVCB…M1…
a0: 00 00 00 00 00 00 00 00 00 00 00 00 e4 73 7b 2d …?s{-
b0: b0 48 0a 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 8a …?
It still does not allow me to flash it.
Any ideas ? how do you determine the last value?
What does this value in the this address represent?
The last bit is not a fixed value. This is CRC checksum bit, which means the value is decided by the whole eeprom bit 0~254 to decide.
For the user “rayer”, his value is 0x8a. But for your case, if you understand what I am talking about above, then you would know it is not possible to be 0x8a… You need to calculate the value again.
Please refer to
@WayneWWW
thanks, I checked the CRC value for the eeprom in address 0x50, and I was correct.
I wrote a python script to check the CRC. I tested it with the dump provided by rayer, and it came out to be 0x8a.
It didn’t fix the issue, I am still unable to flash Jetpack 5.0.2.
Error:
[ 0.0839 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
[ 0.0843 ] BR_CID: 0x80012344705DD3C38400000011018240
[ 0.2878 ] Sending bct_br
[ 0.5059 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Reading board information failed.
Here the script :
def AddToCRC(b, crc):
b2 = b
if (b < 0):
b2 = b + 256
for i in range(8):
odd = ((b2^crc) & 1) == 1
crc >>= 1
b2 >>= 1
if (odd):
crc ^= 0x8C # This means crc ^= 140.
return crc
if __name__ == "__main__":
# use the correct values
value = [0x02, 0x00, 0xfe, 0x00, 0x00]
crc = 0x0
for v in value:
crc = AddToCRC(v, crc)
print(f"crc= {hex(crc)}")
Hello,
Just want to confirm, since you are able to change the eeprom value, are you indicating you are still able to boot your Orin?
If so, is it possible to change to another ubuntu host (18.04 or 20.04) or type C usb cable? And are you able to dump the uart log during the flash error happened?
Please let me know if you have anything that didn’t understand in my comment here.
@WayneWWW
once I corrected the eeprom value, I was able to boot into the Orin normally. But I am still not able to flash the new image into the Orin. I tried different cables and host machine.
I have attached the logging files from the sdkmanager when flashing fails:
SDKM_logs_JetPack_5.0.2_Runtime_(rev.1)_Linux_for_Jetson_AGX_Orin_modules_2022-09-12_16-08-17.zip (44.1 KB)
I saw an interesting observation. I tried upgrading the Jetpack from the repository, but it failed. I rebooted the Orin and it is failing to boot again. I am wondering if upgrading the Jetson Orin is causing this eeprom corruption. This time the CRC of the eeprom on address 0x56 was not correct. I changed it to the correct value and it was able to boot. Also, I had to removed and SD card from mounting at boot ( I use it as additional memory ).
I tried upgrading the Jetpack 5.0.1 DP to the 5.0.2 from the repositories but it fails. I need to flash from the sdkmanage but it does not work either.
Hi,
That is not normal.
What is your command to “upgrading the Jetpack from the repository” ?
Also, I am a little confused by your exact method to “change eeprom value”. If you cannot boot, then how did you change the value? Where did you change it?
sudo apt upgrade.
so it does not boot as a user nor displays over display port. it does boot as root over the uart console. over the console, I set the eeprom value, once corrected, it boots normally.
I am out of ideas.
Hello,
Is this behavior a reproducible and repeated one?
For example, boot up fine → apt-get upgrade → eeprom is being changed → failed to flash → change eeprom manually back → able to flash again → boot up fine → apt-get upgrade again… → loop
Hi, @WayneWWW
I successfully flushed Jetson Orin via SDKManager after correcting the last eeprom value. Sorry for taking long time to get back to you. I appreciate your coorperation and support.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.