ERROR : Flash Jetson AGX Xavier : lost connection

I had a ton of issues flashing this with a VM as well.

What worked for me was installing JetPack 4.1.1, and then installing 4.2 over it.

I still had to reconnect the device to the VM mid-install, and that seemed to work out for my use case already.

It is not a straight forward process by any means, don’t let the people here tell you it is.

Yes… 321.8 MB is indeed not large enough for installing the driver package… I just checked my xavier package and it is 38.4 GB.

Also, I am sorry that VM is still not supported for installing Jetpack. Usually, The installation result is unexpected when using VM…

One thing i had during my ins echo “||||||||||||||||||||||| ERROR |||||||||||||||||||||||”
echo “-----------------------------------------------------”
echo “1. The root filesystem, provided with this package,”
echo " has to be extracted to this directory:"
echo " {LDK_ROOTFS_DIR}" echo "-----------------------------------------------------" echo "2. The root filesystem, provided with this package," echo " has to be extracted with 'sudo' to this directory:" echo " {LDK_ROOTFS_DIR}"
echo “-----------------------------------------------------”
echo “Consult the Development Guide for instructions on”
echo “extracting and flashing your device.”
echo “|||||||||||||||||||||||||||||||||||||||||||||||||||||”
tallation was the issue that always this message popped up.

For some reason altough passwd was proper and contained the root user it seemed that this command did false positivly thrown this error:
if [ ! find "$LDK_ROOTFS_DIR/etc/passwd" -group root -user root ]; then

So i dont know why it exactly is happening here but for me it provided some hours of trial and error figuring out how to bypass this.

Figures the issue is, if you install or download to a ntfs drive.
Formattet a usb stick to ext4 and everything goes fine.

Also python has to be installed. Maybe some kind of FAQ or Frequently Issues would be nice there.

Something to consider in general is that security related files tend to have mandatory permission schemes. Non-Linux filesystems (such as NTFS) have no concept of “group”, and so it is not possible to preserve permissions correctly when copying Linux files to something in the Windows world. The generated image which gets flashed starts with unpacking Ubuntu into a directory with permissions preserved.

Okay i will now create a document where i store all the issues + solutions i encounter while developing.

Hope it can help some people, because the AGX is an awesome board.

Hello

I have checked the -Download now and install later (step 2);
Downloaded and closed SDKmanager and opened it again;
After changed the username from “SafeForest” to “safeforest” (step 3).

Worked.
Also, disconnecting ethernet cables from agx xavier.

Good luck to all.
Regards.
PM33

You deserve a medal! I would never figure this out. I confirm that the sdk folder cannot be in an NTFS drive

I have two new Xavier development boards. I was able to flash one to 4.5. I’m having problems with the second. I’m using the same host and USB cable to the board. I put the board in manual flash mode, and run sudo ./flash.sh jetson-xavier mmcblk0p1. The USB connection is immediately lost. I perform the manual flash reset sequence to reestablish the USB connection and the script seems to be doing something, but I receive CPU Bootloader is not running on the device. Here’s the output:

$ sudo ./flash.sh jetson-xavier mmcblk0p1
###############################################################################
# L4T BSP Information:
# R32 , REVISION: 5.0
###############################################################################
# Target Board Information:
# Name: jetson-xavier, Board Family: t186ref, SoC: Tegra 194, 
# OpMode: production, Boot Authentication: NS, 
# Disk encryption: disabled ,
###############################################################################
copying soft_fuses(/home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-soft-fuses-l4t.cfg)... done.
./tegraflash.py --chip 0x19 --applet "/home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod.bin" --skipuid --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins "mb2_applet nvtboot_applet_t194.bin" --cmd "dump eeprom boardinfo cvm.bin;reboot recovery" 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0031 ] Generating RCM messages
[   0.0043 ] tegrahost_v2 --chip 0x19 0 --magicid MB1B --appendsigheader /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod.bin zerosbk
[   0.0054 ] Header already present for /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod.bin
[   0.0135 ] 
[   0.0148 ] tegrasign_v2 --key None --getmode mode.txt
[   0.0158 ] Assuming zero filled SBK key
[   0.0160 ] 
[   0.0173 ] tegrasign_v2 --key None --file /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod_sigheader.bin --offset 2960 --length 1136 --pubkeyhash pub_key.key
[   0.0182 ] Assuming zero filled SBK key
[   0.0190 ] 
[   0.0200 ] tegrahost_v2 --chip 0x19 0 --updatesigheader /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod_sigheader.bin /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod_sigheader.hash zerosbk
[   0.0258 ] 
[   0.0274 ] tegrabct_v2 --chip 0x19 0 --sfuse tegra194-mb1-soft-fuses-l4t.cfg.pdf sfuse.bin
[   0.0287 ] 
[   0.0299 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x19 0 --sfuses sfuse.bin --download rcm /home/pstieber/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_AGX_XAVIER/Linux_for_Tegra/bootloader/mb1_t194_prod_sigheader.bin 0 0
[   0.0309 ] RCM 0 is saved as rcm_0.rcm
[   0.0353 ] RCM 1 is saved as rcm_1.rcm
[   0.0353 ] RCM 2 is saved as rcm_2.rcm
[   0.0353 ] List of rcm files are saved in rcm_list.xml
[   0.0353 ] 
[   0.0354 ] Signing RCM messages
[   0.0364 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key --getmontgomeryvalues montgomery.bin
[   0.0374 ] Assuming zero filled SBK key
[   0.0381 ] 
[   0.0381 ] Copying signature to RCM mesages
[   0.0394 ] tegrarcm_v2 --chip 0x19 0 --updatesig rcm_list_signed.xml
[   0.0414 ] 
[   0.0415 ] Boot Rom communication
[   0.0425 ] tegrarcm_v2 --chip 0x19 0 --rcm rcm_list_signed.xml --skipuid
[   0.0435 ] RCM version 0X190001
[   0.3454 ] Boot Rom communication completed
[   1.3600 ] 
[   2.3635 ] tegrarcm_v2 --isapplet
[   2.3653 ] Applet version 01.00.0000
[   2.9864 ] 
[   2.9885 ] tegrarcm_v2 --ismb2
[   3.6343 ] 
[   3.6366 ] tegrahost_v2 --chip 0x19 --align nvtboot_applet_t194.bin
[   3.6384 ] 
[   3.6405 ] tegrahost_v2 --chip 0x19 0 --magicid PLDT --appendsigheader nvtboot_applet_t194.bin zerosbk
[   3.6423 ] adding BCH for nvtboot_applet_t194.bin
[   3.6495 ] 
[   3.6525 ] tegrasign_v2 --key None --list nvtboot_applet_t194_sigheader.bin_list.xml --pubkeyhash pub_key.key
[   3.6539 ] Assuming zero filled SBK key
[   3.6547 ] 
[   3.6566 ] tegrahost_v2 --chip 0x19 0 --updatesigheader nvtboot_applet_t194_sigheader.bin.encrypt nvtboot_applet_t194_sigheader.bin.hash zerosbk
[   3.6603 ] 
[   3.6626 ] tegrarcm_v2 --download mb2 nvtboot_applet_t194_sigheader.bin.encrypt
[   3.6643 ] Applet version 01.00.0000
[   4.2946 ] Sending mb2
[   4.2947 ] [................................................] 100%
[   4.3075 ] 
[   4.3097 ] tegrarcm_v2 --boot recovery
[   4.3114 ] Applet version 01.00.0000
[   4.9419 ] 
[   5.9453 ] tegrarcm_v2 --isapplet
[   5.9472 ] USB communication failed.Check if device is in recovery
[   6.6582 ] 
[   6.6604 ] tegrarcm_v2 --ismb2
[   6.6621 ] USB communication failed.Check if device is in recovery
[   7.3701 ] 
[   7.3722 ] tegradevflash_v2 --iscpubl
[   7.3740 ] Cannot Open USB
[   8.0823 ] 
[   9.0857 ] tegrarcm_v2 --isapplet
[   9.0875 ] USB communication failed.Check if device is in recovery
[   9.7942 ] 
[   9.7965 ] tegrarcm_v2 --ismb2
[   9.7982 ] USB communication failed.Check if device is in recovery
[  10.5062 ] 
[  10.5085 ] tegradevflash_v2 --iscpubl
[  10.5102 ] Cannot Open USB
[  11.2181 ] 
[  12.2219 ] tegrarcm_v2 --isapplet
[  12.2237 ] USB communication failed.Check if device is in recovery
[  12.9342 ] 
[  12.9363 ] tegrarcm_v2 --ismb2
[  12.9380 ] USB communication failed.Check if device is in recovery
[  13.6462 ] 
[  13.6484 ] tegradevflash_v2 --iscpubl
[  13.6502 ] Cannot Open USB
[  14.3582 ] 
[  15.3616 ] tegrarcm_v2 --isapplet
[  15.3634 ] USB communication failed.Check if device is in recovery
[  16.0702 ] 
[  16.0722 ] tegrarcm_v2 --ismb2
[  16.0740 ] USB communication failed.Check if device is in recovery
[  16.7822 ] 
[  16.7844 ] tegradevflash_v2 --iscpubl
[  16.7862 ] Cannot Open USB
[  17.4982 ] 
[  18.5017 ] tegrarcm_v2 --isapplet
[  18.5035 ] USB communication failed.Check if device is in recovery
[  19.2102 ] 
[  19.2123 ] tegrarcm_v2 --ismb2
[  19.2140 ] USB communication failed.Check if device is in recovery
[  19.9223 ] 
[  19.9245 ] tegradevflash_v2 --iscpubl
[  19.9263 ] Cannot Open USB
[  20.6382 ] 
[  21.6417 ] tegrarcm_v2 --isapplet
[  21.6435 ] USB communication failed.Check if device is in recovery
[  22.3541 ] 
[  22.3559 ] tegrarcm_v2 --ismb2
[  22.3577 ] USB communication failed.Check if device is in recovery
[  23.0702 ] 
[  23.0723 ] tegradevflash_v2 --iscpubl
[  23.0740 ] Cannot Open USB
[  23.7822 ] 
[  24.7857 ] tegrarcm_v2 --isapplet
[ 1030.4127 ] 
[ 1030.4146 ] tegrarcm_v2 --ismb2
[ 2046.2207 ] 
[ 2046.2230 ] tegradevflash_v2 --iscpubl
[ 2046.2248 ] CPU Bootloader is not running on device.
[ 3062.0287 ] 
[ 3063.0321 ] tegrarcm_v2 --isapplet
[ 4077.8368 ] 
[ 4077.8391 ] tegrarcm_v2 --ismb2

Any ideas?

I think the real problem is “[ 22.3577 ] USB communication failed.Check if device is in recovery”.

This should not happen. Is your host a virtual machine?

It is not a VM. It’s actual x86_64 HW running 18.04. I perform the power-up recovery sequence, check the connection using lsusb and it is connected, but when the flash process starts, the USB connection drops. I leave the flash process running and I use the reset recovery sequence to get the USB connection reestablished and I can see it is with lsusb, but the flash process fails. I’m wondering what would make the USB connection drop when the flash begins.

Did your host ever flash any jetson device with any software release before?

If this host didn’t flash any xavier device before, changing the usb cable or host usb port and see if the connection could be stable.

As I mentioned earlier, I have two new Xavier AGX development boards and I successfully flashed one to 4.5 using the exact same setup, host computer, USB cable, and power supply. After one was setup, I just plugged in the other. The other is running R32-3.1, but I’m having the flashing problem described above. I’m sending it to a work colleague to see if they have more “luck”, although I don’t believe “luck” has anything to do with it. If he isn’t successful, we’ll probably work to get a replacement.

Hi,

Yes, if even your colleague cannot flash your board, then please RMA this device.

That is, in fact, the case. Thanks for the help! It’s good to know when to stop trying.