It connected to desktop USB port 2.0 directly without HUB.
The lsusb | grep ‘0955:7’ output is
Bus 001 Device 008: ID 0955:7f21 NVidia Corp.
The lsusb -t output is:
nvidia@nvidia-OptiPlex-3050:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
|__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 9: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 10: Dev 8, If 0, Class=Vendor Specific Class, Driver=, 480M
You have to run “dmesg --follow” before the flash, and observe what appears. It is what is new from the flash which I am looking for, and the full “dmesg” is instead everything since the beginning of boot. The full “dmesg” is a problem since I don’t know the exact log which is from the flash itself.
@WayneWWW had asked to try flash with defaults instead of using the “-R”, and this would be a good time to check the host PC dmesg (but only the dmesg which occurs during the flash…content prior to flash should be removed, which in turn means you have to see where “dmesg --follow” ends prior to flash). However, what I do see at the end for USB seems to be valid and without error, but it would be good to verify the exact lines of log which might appear at the time of failure.
Btw, the original question of updating for your carrier board would be unrelated to flash stopping, but of course it is hard to answer that if the system doesn’t flash. Device tree changes would never stop flash.
Also, the USB shows up as correct on the host side prior to flash. The fact that the tree view of lsusb shows a “Vendor Specific Class” proves the device is both present and in recovery mode. I’m guessing the device ID “7f21” is the eMMC model of Nano module.
Loopback mount might be a side-effect of the flash process generating the image to flash, so that only verifies partial progress.
It could be a port issue, which happens sometimes. You might try different ports, or if available, even a different computer. It could also be the USB is a problem of the Nano itself. Hard to tell without trying other ports and another host.
I tried an USB 3 port. It works fine. No other USB 2 port available on my desk top.
No other Ubuntu 18.04 desktop available for me to test.
I will not go further to investigate as it works on the USB 3 port.
Probably a signal quality issue (which happens with perfectly good hardware when wiring is just the wrong shape/length). I’ll guess that the USB3 port is wired to tighter standards, and thus behaves differently than a USB2 device on a USB2 port.