Is the host PC Ubuntu 18.04? Is there any VM involved? Are you using the supplied micro-B USB cable?
Note that VMs have problems when they fail to correctly pass through USB. During flash the USB will disconnect and reconnect multiple times, and this is where a VM tends to fail to reacquire USB.
Many third party “charger” cables have very poor data capabilities, and probably 3 out of 4 such charger cables will fail during long data transfers.
Is the host PC Ubuntu 18.04? Yes
Is there any VM involved? No. sdkmanager is launch from host.
Are you using the supplied micro-B USB cable? Yes and no… I use the micro-B USB cable supplied by D3 with D3 board based on Jetson.
I tried to flash D3 board and Nvidia dev kit without success.
This could be important. I wouldn’t think it would cause a flash to just fail in the middle, but you have to use their software for actual boot to succeed. Mostly this is the same as the supplied software from NVIDIA, but includes device tree changes to deal with the different carrier board layout. Possibly if you flash with just the generic NVIDIA software something would fail to start, but that’s just a guess at one possibility. Are you using the software supplied with the D3 during the flash?
There are few things that can help clarify this issue
Do you have only 1 jetson TX2 module and carrier board to try? From previous comment, I can only tell you have x1 devkit and x1 D3 board.
If you have more than one module, you can try to flash them too. If multiple devices cannot be flashed on same host, then it is possible host side issue.
Are you able to flash with other hosts?
You said this board was able to be flashed 2 month ago. If so, the release during that time should be <=rel-32.4.3, have you tried old jetpack release?
Do you have only 1 jetson TX2 module and carrier board to try? From previous comment, I can only tell you have x1 devkit and x1 D3 board.
2 carrier (1 D3, 1 Nvidia dev kit). Both carriers have their own modules.
If you have more than one module, you can try to flash them too. If multiple devices cannot be flashed on same host, then it is possible host side issue.
I agree !
Are you able to flash with other hosts?
Yes. My co-worker did it.
You said this board was able to be flashed 2 month ago. If so, the release during that time should be <=rel-32.4.3, have you tried old jetpack release?
I tried 32.4.3 and then 32.4.2. With ou without deepstream. With Jetpack 4.4.1 or 4.4.0.
I failed to go with an earlier version than this 32.4.2. sdkmanager reported incompatibility issues when trying this.
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 413c:3010 Dell Computer Corp. Optical Wheel Mouse
Bus 001 Device 003: ID 8087:0a2a Intel Corp.
Bus 001 Device 002: ID 04f2:b59e Chicony Electronics Co., Ltd
Bus 001 Device 026: ID 0955:7c18 NVidia Corp. <======= TX2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Sorry that I cannot get much info from your reply.
2 carrier (1 D3, 1 Nvidia dev kit). Both carriers have their own modules.
So both modules cannot be flashed on your current host, right?
Yes. My co-worker did it.
Are you able to ask your co-worker to use his host to flash the board again?
I tried 32.4.3 and then 32.4.2. With ou without deepstream. With Jetpack 4.4.1 or 4.4.0.
I failed to go with an earlier version than this 32.4.2. sdkmanager reported incompatibility issues when trying this.
What kind of “incompatibiliy” issue is that? TX2 has been released for 3 years. Even old jetpack re-28 should be able to flash it.
Both carriers and modules cannot be flashed on my current host.
I tried and failed with sdkmanager 1.3, then I removed/purge nvidia’s packages (libvision* nvidia-* cuda-*), then I installed sdkmanager 1.2. sdkmanager reported incompatibility issues about host’s packages. After trying hours to solve it, I decided to quit trying to downgrade sdkmanager.
sdkmanager keep re-installing “host components”. It takes a long time. Surprisingly, the status is “installed” after each try. Maybe it’s not related to my flashing issues but it’s very annoying.
Are you able to ask your co-worker to use his host to flash the board again?
I am not sure why you have to remove the sdkmanager for older release. Sdkmanager can help you pick the old release version.
Also, since your co-worker can still flash your board, it is more like a problem on your host.
Is there any log coming out from serial console port when you run flash command? Please note that serial console port is from UART port of tegra. Not from host.
Containers and VMs will possibly (probably) loose the UART as USB repeatedly disconnects and reconnects during a flash. Depends on settings (something I cannot help with). However, the screenshot above is not an actual flash log. If you want to create a log file you can attach to this thread, then a TX2 could be flashed as follows with the TX2 in recovery mode:
cd ~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt
…then attach log_flash.txt in your thread. The SDKM also has an “export logs” you can run, but this includes a lot of logs other than just flash, e.g., downloading and host PC setup. What you really need is the flash log.
You could also log the serial console of the Jetson during the flash. Programs like minicom and gtkterm are able to log sessions. This includes being able to log what is seen during a flash. Serial console is Jetson side, flash.sh logs are host side. However, you’d watch both from host since the serial console program runs on the host.
