Mass flashing fails on TX2 with JetPack 4.6

I am trying to mass flash a TX2 on a custom PCB with JetPack 4.6, but the flashing always fails. I had mass flashed the TX2 on the very same PCB with an earlier mass flash blob created with JetPack 4.4.1 (with the mass flash patch) without any issues, but now I have created a JetPack 4.6 mass flash blob and that fails repeatedly. Flashing the same device using flash.sh works fine. It is only the mass flash blob with nvmflash.sh that fails. I tried stopping the udisks2 service but that didn’t help. I have not applied the JetPack 4.4.1 mass flash patch to JetPack 4.6.

The USB device does show up in lsusb as NVIDIA APX (for now I am just testing the mass flash blob with one TX2):

Bus 001 Device 012: ID 0955:7c18 NVIDIA Corp. APX
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0e0f:0008 VMware, Inc. VMware Virtual USB Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I have looked at the other mass flash forum posts, but didn’t see anything that helped. It appears to be having trouble finding the USB device, even though it shows up in lsusb and I have put the TX2 into recovery mode (a procedure which I have done many times, and used to successfully flash using flash.sh as opposed to nvmflash.sh). Here is the mfilog from the mass flashing utility:

*** Boot Rom communication
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --chip 0x18 0 --rcm rcm_list_signed.xml 
BR_CID: 0x81801001645d070218000000120481c0
RCM version 0X180001
Boot Rom communication completed
*** Boot Rom communication succeeded.

*** Checking applet
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --isapplet
Applet version 01.00.0000
*** Checking applet succeeded.

*** Sending BCTs
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt 
Applet version 01.00.0000
Sending bct_bootrom
[................................................] 100%
Sending bct_mb1
[................................................] 100%
*** Sending BCTs succeeded.

*** Sending bootloader and pre-requisite binaries
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --download blob blob.bin
Applet version 01.00.0000
Sending blob
[...........                                     ] 023%
[.......................                         ] 046%
[..................................              ] 069%
[..............................................  ] 092%
[................................................] 100%
*** Sending bootloader and pre-requisite binaries succeeded.

*** Booting Recovery
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --boot recovery
Applet version 01.00.0000
*** Booting Recovery succeeded.

*** Checking applet
/home/dmadill/images/mfi_jetson-tx2/tegrarcm_v2 --instance 1-1 --isapplet

*** Checking CPU bootloader
/home/dmadill/images/mfi_jetson-tx2/tegradevflash_v2 --instance 1-1 --iscpubl
No device on specified bus-port[1-1]
Cannot Open USB
*** Error: Checking CPU bootloader failed.

Any help would be appreciated because we use mass flashing for production. Note that this is a clear mass flash image (no signing or encryption).

Sincerely,
Dan

This is very likely caused by the VM. During flash USB disconnects and reconnects. This is technically not supported, but if you can set up the VM to always pass through the USB (even in the face of disconnect reconnect), then it might work. You’d have to consult VMware’s help to find out how to do that (or whatever docs they publish).

Thank you for the suggestion. The only thing that puzzles me about it is that I am able to use flash.sh in a VM to flash a single device without issue. To be fair, I do use flash.sh in a different VM (one with JetPack installed) than the VM in which I use nvmflash.sh (one without JetPack installed but configured for mass flashing), but both VMs are on the same machine and both are in the same instance of VMware Workstation.

Maybe I will try the mass flashing from a separate folder on the VM from which I flashed a single device using flash.sh just in case there is something wrong with the second VM. The reason I use a second VM for mass flashing is I want to replicate what our production team will use (which is a Linux machine without JetPack installed).

Setup for keeping the USB pass-through for a single device might be different versus multiple devices. Don’t know, but that’d be something the VMware help might be able to solve. It might be that a single device disconnect and reconnect might need different configuration than multiple device disconnect and reconnect. Just speculation, but something as simple as re-enumeration order changing could cause failure (don’t know…to emphasize, that is speculation).

I finally managed to get the mass flashing to work. I put in a new hard drive and installed Ubuntu on it and tried mass flashing from that, but it still didn’t work (similar errors). I then used a shorter USB cable and it worked. The odd thing is I use the longer cable for cloning the embedded flash and flashing a single device from JetPack from within an Ubuntu VM in Windows on the exact same PC hardware without issue. But for mass flashing I have to use the shorter cable (actually the “long” cable is the same short cable with an extension cable). There must be something different about the timing between flash.sh and nvmflash.sh. Anyways, thanks for the suggestions.

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