I bought the Jetson TX2 (S/N 0424118035793) on January 2, 2019 through Amazon. The TX2 booted up well. But I kept it as it was because I did not have any Linux machine. Recently I got a Linux machine and tryed to install JetPack to the TX2. When I connected the TX2 to the Linux machine through the micor Usb connecter on the board, the Linux machine did not recognize NVIDIA in the lsusb list. Thus I could not process flashing. To check the USB cable I connected a USB memory through the micoro usb connector. It was not recognized by the TX2 becaouse USB icon did not show up on the Ubuntu screen.
Another abnormality was observed when the TX2 list the booting messages, there is one error message that showed as:
[FAILD] Failed to mount Squashfs mount unit for ubuntu-core.
Squashfs my simply be a feature not turned on (and unless the system booted normally you probably couldn’t see that message).
Is the micro-B USB cable the original which comes with the development kit? Other cables tend to not be up to standards and typically are for charging.
Putting the Jetson in recovery mode involves holding down the recovery button, and then either powering on or resetting power (no need to hold the recovery button for long periods of time). Then the Linux computer at the other end should show a TX2 from “lsusb -d 0955:7c18”. An exception is if your host is a VM, in which case VMs usually fail without extra work. Is the host a VM, or is there anything unusual about the host?
Thank you for your response, but the problem hasn’t been soloved yet.
About [FAILD] Squashfs, do you mean this is not related to the micro-B usb and I can just leave it as it is?
About micro-B USB connection, I used the cable which was included in the development kit. Because of this problem of the TX2, I bought a Jetson Nano. I cahecked the cable by connecting the Nano to the Linux machine and also to a Win10 machine and both cases Nano was recognized. Linux with “lsusb” showd NVIDA on the list, and Win10 with its device manager Nano was recognized as “other machine”.
The Linux machine is a usual machine and not VM. When I checked USB memory on the TX2 micor-B USB connector I used the small micro-B to female USB connector cable that was also included in the TX2 development kit.
This time, I connected TX2 to another Linux machine through the micro-B USB and did “lsusb” and “lsusb -d 0955:7c18”. The result showed any sign of TX2 as:
nakamura@nakamura-desktop:~$ lsusb
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04bb:0947 I-O Data Device, Inc. WN-G150U Wireless LAN Adapter
Bus 001 Device 007: ID 054c:02a5 Sony Corp. MicroVault Flash Drive
Bus 001 Device 006: ID 0566:3029 Monterey International Corp.
Bus 001 Device 005: ID 056e:0018 Elecom Co., Ltd
Bus 001 Device 003: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
nakamura@nakamura-desktop:~$ lsusb -d 0955:7c18
nakamura@nakamura-desktop:~$
Shinji
In my previous reply I meant :
The result did not show any sign of TX2 as:
nakamura@nakamura-desktop:~$ lsusb
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04bb:0947 I-O Data Device, Inc. WN-G150U Wireless LAN Adapter
Bus 001 Device 007: ID 054c:02a5 Sony Corp. MicroVault Flash Drive
Bus 001 Device 006: ID 0566:3029 Monterey International Corp.
Bus 001 Device 005: ID 056e:0018 Elecom Co., Ltd
Bus 001 Device 003: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
nakamura@nakamura-desktop:~$ lsusb -d 0955:7c18
nakamura@nakamura-desktop:~$
Squashfs may be related to a filesystem type, which is separate from actual block devices. If something actually requires squashfs, then the setup would be a different topic…but in fact if you had some external storage over the USB which caused a squashfs failure, then it would imply the external storage actually worked and the next step to making use of this specialized filesystem would have been the failure. However, there are lots of reasons why a default install might mention not having squashfs configured, and until it is determined that there is something needing squashfs, then this should be ignored and not considered until you have an otherwise working system.
The lsusb command should show the presence of the TX2 if and only if the TX2 is in recovery mode. The cable which arrives with a Nano should do the job and will not be an issue. Are you absolutely certain the TX2 was in recovery mode before running the lsusb command? If so, then we have an actual hardware failure.
Thank you for your reply.
I am absolutely sure that TX2 had only power and micro-B usb connections and was in the recovery mode set according to the method specified in your reply. And I checked the entire procedure with lsusb commands more than twice.
In that case I’d say it is an actual hardware failure and RMA is required. lsusb with recovery mode should be extremely reliable and more or less immune to software issues (other than a VM losing USB).