Orin NX Module flashing error failed to initialize partition table from GPT

[ajarizzo]

Hello,

I am seeing an issue on two different Orin NX SoMs when I try to flash the module a 2nd time:

[   7.3316 ] Start flashing
[   7.3324 ] tegradevflash_v2 --pt flash.xml.bin --create
[   7.3333 ] Bootloader version 01.00.0000
[   7.3357 ] Erasing spi: 0 ......... [Done]
[   8.3450 ] Writing partition secondary_gpt with gpt_secondary_3_0.bin [ 16896 bytes ]
[   8.3461 ] [................................................] 100%
[   8.3494 ] 000000004d4d2c01: E> NV3P_SERVER: Failed to initialize partition table from GPT.
[   8.5713 ] 
[   8.5713 ] 
Error: Return value 1
Command tegradevflash_v2 --pt flash.xml.bin --create
Failed flashing t186ref.

I have previously successfully flashed both modules once, but saw the device go into a busy spin due to the carrier board not having EEPROM. I was trying to apply the fix described here, but I am seeing the above error with both SoMs when trying to reflash them. How can I recover the SoMs?

[linuxdev]

Are you resetting recovery mode between flashes? Each operation requires this. You cannot perform two recovery mode operations in a row without this. Example of what you cannot do:

• Clone, followed by flash.

Example that works:

• Clone.
• Reset power and go back to recovery mode.
• Flash.

Also, if using a VM, then that tends to have errors.

[ajarizzo]

If you mean resetting the board between attempts, then yes, I completely power cycled the board/som before trying to reflash. I am not using a VM.

[WayneWWW]

My suggestion is you could try to share more info about your question. I don’t know you and your board.

I couldn’t know what flash command you are using from your comment.
I don’t know if your board is okay to work or not.

If possible, try it on NV devkit first.

[ajarizzo]

I recovered the Orin NX SoMs using the initrd flashing method which was able to reprogram the QSPI properly without errors. For some reason the flash.sh script does not work after the first time it is run on a fresh module. I did notice a larger initial erase (64MB) when using the initrd flashing image. This takes much longer than the 1s erase the flash.sh script does, which I suspect could be the reason it fails, but I’m not entirely sure.