Cannot flash OS image to Orin Developer Kit via SDK Manager

Hi,

Is the minicom log during flash still the same?

And which type C usb port is in use here? Are you sure you use the correct flash port?

Do we have other host machine that can test flash?

The minicom shows the same log while flashing via sdkmanager. I use type C usb port next to 40 pins.
Does other host machine means other Jetson machines? I have other Jetson machines (not Orin), but cannot overwrite their OS by flash.

Hi,

  1. No, I mean the x86 host

  2. Are you saying that you have other jetson devices but flash them will also give error too?

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.

Hi, @WayneWWW ,
Is it possible for you to tell me how eeprom values should be changed?

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.

  1. boot while connected to console over UART.
  2. 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

https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide/text/HR/JetsonEepromLayout.html?highlight=eeprom

@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?