Hi,
I have encountered problem using the Nvidia SDK Manager to re-flash the Nvidia Jetson Xavier AGX (P2888-0004_32 GB) mainly with the following observations:
the device has been flashed once before and running before the second re-flash because of the need of “deepstream” SDK
recovery mode is dropped (eg. lsusb without Nvidia details) whenever it reached about 33% mark (the Nvidia information"0955:7019 Nvidia Corp" disappears) and encountered a usb discovery error
attempt doing manually with “sudo ./flash.sh jetson-xavier mmcblk0p1” also does not work (it just halted after long time without showing any errors)
I have used a different host laptop with the specified Ubuntu 18.04 OS in the second attempt of refresh. Using the provided cable from the Xavier AGX developer kit and has successfully flash it once. The Nvidia SDK Manager can detect the board before installation/flashing on step 1 page.
I have done that on the same network. But using Nvidia SDK Manager, internet connection with the AGX device is not necessary since flashing is done with the included USB-C cable?
I would assume the 32GB space is enough for the flashing based on recovery mode?
I did not manage to get to the previous “Automatic Setup” screen in SDK manager with only error stating failure in flashing.
Direct connection from board via USB-C cable included with the power cable connected; nothing else is connected.
Failed to flash even for the latest Jetpack 4.4.1 and using the manual command (sudo ./flash.sh jetson-xavier mmcblk0p1) as described in the email below.
LT4 is being installed and all the mandatory components in Step 1 on the host without the SDK components. Thus, the host directory contains all the files but unable to flash the target (Xavier AGX)?
I have tried to read the posted flashing problems other developers have raised in the blogs; but, could not find a workable solution yet.
–
The device currently has to be shelved till someone can lend me a hand or share. Thanks anyone in advance for offering to provide the needed assistances.
Since the flash is always failed, is your board still able to boot into ubuntu desktop?
Could you share the log you see from flash.sh when error happened? I would say you can forget about sdkmanager at this moment and just use flash.sh to debug. It is totally same and save more time.
thanks for lending a hand and please refer to the respective answers to your earlier questions.
(1)
I tried to do a “upgrade” today on the host computer (via auto-update system prompt) prior to following your recommendations but there were errors in the upgrade process. And when I want to install the minicom, I have experienced with the following errors :
$ sudo apt install minicom
Reading package lists… Done
Building dependency tree
Reading state information… Done
You might want to run ‘apt --fix-broken install’ to correct these.
The following packages have unmet dependencies:
libnvidia-decode-440 : Depends: libnvidia-compute-440 (= 440.118.02-0ubuntu1) but 440.100-0ubuntu0.18.04.1 is to be installed
nvidia-driver-440 : Depends: libnvidia-compute-440 (= 440.118.02-0ubuntu1) but 440.100-0ubuntu0.18.04.1 is to be installed
Recommends: libnvidia-compute-440:i386 (= 440.118.02-0ubuntu1)
Recommends: libnvidia-decode-440:i386 (= 440.118.02-0ubuntu1)
Recommends: libnvidia-encode-440:i386 (= 440.118.02-0ubuntu1)
Recommends: libnvidia-ifr1-440:i386 (= 440.118.02-0ubuntu1)
Recommends: libnvidia-fbc1-440:i386 (= 440.118.02-0ubuntu1)
Recommends: libnvidia-gl-440:i386 (= 440.118.02-0ubuntu1)
E: Unmet dependencies. Try ‘apt --fix-broken install’ with no packages (or specify a solution).
I guess this does not happen to minicom only. But many of your driver package on ubuntu host.
Could you check the arch and foreign arch of dpkg tool and remove that one that is not needed here?
Your current error seems to be the host is amd64 arch but the apt tries to search dependencies in i386 arch…
So my suggestion is try to remove i386 arch there.
You don’t really need to wait for our answer for such issue. This is not specific to tegra.
Searching this on linux of ubuntu related website can provide more help and explanation.
and the following errors that repeats :
[ 2.1687 ]
[ 2.1713 ] tegrarcm_v2 --boot recovery
[ 2.1738 ] Applet version 01.00.0000
[ 2.1955 ]
[ 3.1997 ] tegrarcm_v2 --isapplet
[ 3.2022 ] USB communication failed.Check if device is in recovery
[ 3.4335 ]
[ 3.4363 ] tegrarcm_v2 --ismb2
[ 3.4388 ] USB communication failed.Check if device is in recovery
[ 3.4397 ]
[ 3.4423 ] tegradevflash_v2 --iscpubl
[ 3.4448 ] Cannot Open USB
…
Ctrl-C to break
(2)
and the minicom output is :
Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyUSB3, 00:26:51
[0006.263] W> Profiler not initialized
[0006.266] I> Welcome to MB2(TBoot-BPMP) Applet (version: 00.00.2018.32-mobile-9af8dd5a)
[0006.274] W> Profiler not initialized
[0006.278] I> DMA Heap @ [0x40020000 - 0x40065800]
[0006.282] I> Default Heap @ [0xd486400 - 0xd48a400]
[0006.287] W> Profiler not initialized
[0006.291] W> Profiler not initialized
[0006.294] E> DEVICE_PROD: Invalid value data = 0, size = 0.
[0006.300] W> device prod register failed
[0006.303] W> Profiler not initialized
[0006.371] I> sdmmc DDR50 mode
[0006.375] I> No supported QSPI flash found
[0006.379] E> QSPI Flash: Insufficient flash size (0 MB)
[0006.384] I> QSPI Flash is not present.
[0006.435] E> Link startup dme_set failed
[0006.439] E> UFS initialization failed
[0006.443] I> UFS is not present
[0006.445] W> Profiler not initialized
[0006.452] I> Found 17 partitions in SDMMC_BOOT (instance 3)
[0006.460] I> Found 42 partitions in SDMMC_USER (instance 3)
[0006.466] W> Profiler not initialized
[0006.469] W> Profiler not initialized
[0006.473] W> Profiler not initialized
[0006.476] I> Entering 3p server
[0006.480] I> USB configuration success
(3)
But, I realised the USB has dropped when the flashing fails :
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 004: ID 0c45:6717 Microdia
Bus 001 Device 007: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
–
The “Bus 001 Device 006: ID 0955:7019 NVidia Corp.” disappears when the ./flash.sh is executed. How could I do proceed to re-flash the AGX developer kit? Cheers.
If you are using a host PC, then you would not want to remove i386 architecture. However, if your flash starts and looks ok in the beginning with lsusb, then you might want to try simply unplugging and replugging the USB-C when the error hits. It is quite common for a VM to lose USB, and then an effort to reestablish USB allows continuing, so I am wondering if this might work in a non-VM similar situation.
Hi, as recommended earlier to remove i386 architecture., I have tried to remove it but does not work; so I reinstalled Ubuntu 18.04.5 on the host laptop. With the re-installation of OS on the host, I am at the same stage whereby I cannot re-flash the Xaiver AGX. All this run without any VM.
I have plugged out the USB and reconnect it to the host when there is a dropped USB communication but it does not seem to recognized by AGX. Then I even did a reset with “Recovery” and “Reset” buttons pressed (released first). Then the ./flash.sh hangs at the following point :
[ 29.5460 ] tegrarcm_v2 --ismb2
[ 29.5468 ] USB communication failed.Check if device is in recovery
[ 29.5619 ]
[ 29.5628 ] tegradevflash_v2 --iscpubl
[ 29.5635 ] Cannot Open USB
[ 29.5780 ]
[ 30.5800 ] tegrarcm_v2 --isapplet
[ 30.5808 ] USB communication failed.Check if device is in recovery
[ 30.8643 ]
[ 30.8653 ] tegrarcm_v2 --ismb2
The minicom output is pretty much the same :
Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyUSB3, 12:52:07
The usb type C port is at the side nearest to the 3 buttons (used with the provided cable in AGX developer kit) and the mini usb on the same side is used for debug with minicom (ttyusb3) as per your referred documentation
I am flashing with JetPack 4.4 which happened to be successful before. After trying the second time with a different host (which now works as I have reinstalled the Ubuntu due to the drivers and i386 problems), everything fails with the dropped connection with errors above with ./flash.sh
I am flashing with JetPack 4.4 which happened to be successful before. After trying the second time with a different host (which now works as I have reinstalled the Ubuntu due to the drivers and i386 problems), everything fails with the dropped connection with errors above with ./flash.sh
I am not sure what does that mean. Does this issue happen to second host only or even the first host?
Unfortunately after it fails, the same error happens on both hosts subsequently. And I have re-installed the Ubuntu 18.04.5 (Bonic beaver) to make sure the hosts are not causing the problems.
I have tried to reset when the usb link is down and another re-attempt to disconnect and connect the usb from host. The “lsusb” shows the “Nvidia Corp” line but nothing happens after the reset (with recovery pressed) or usb reconnection.