Please Nvidia how do I troubleshoot "Cannot Open USB"?

Hi,

Could you please someone from Nvidia tell me how to troubleshoot “Cannot Open USB”?

lsusb returns the right USB as Nvidia.

Could you please give more details what checks are done before Cannot Open USB is showed?

thanks

What was the command causing the message? Are you trying to flash, and this was on the host PC?

Hi Linuxdev,

You seems to be the only one to answer questions here.

Is Nvidia such a secret organization with no answers? Why no one from Nvidia ever answer?

The command is irrelevant, however here it is:

tegradevflash --read BPF bpmp.bin, then since seems to be no documentation for tegradevflash, i tried:

tegradevflash --instance /001/005/ --read BPF bpmp.bin and I received the error:

Failure to recognize USB device located at dev/bus/usb/001/005

I’m doing everything right, so I need the exact details of what the tegradevflash does when giving that error.

If lsusb shows the Jetson, but reading fails, I am wondering if the host PC has anything unusual going on, e.g., is this a VM?

Hi,

Of course is VM machine, that what Nvidia says how it should be done.

I guess the only thing to do is reverse tegradevflash and debug with gdb.

Nvidia does give you any support or option so I gues reversing is the only thing to do.

It is the reverse…a VM is not supported. A VM has been known to work, but it tends to require making sure the USB passes through in USB2 mode, and some people have found ways to increase the associated buffer. The actual supported host is a native install of Ubuntu 14.04.

Hi,

Thank you, what does it mean USB passes through in USB2 mode? How is it done?

How to increase the associated buffer?

I don’t use a VM, and each VM is different, so it isn’t something I have details on. Previous comments on VM setup seem to indicate each VM has a way to identify a specific USB device to be dedicated to pass through from the host to the VM…you’ll have to figure out how the VM can be configured to identify and dedicate a port for the Jetson to the VM.

There may be other advanced configuration options which can be set for the USB system. Somewhere in those advanced configurations should be a setting for the amount of buffer made available…whatever it is, try increasing it. I do not know specifics.

Hi,

Thanks again. The VM sees the USB device as Nvidia, so there should no issue with pass through.

Why the buffer?

I mention the pass through because not directly marking this for pass through has in the past messed up other VM users. The buffer because it seems there may be underflow causing streams of data to fail or time out…adding buffer has helped other users in this situation in the past. Keep in mind that a VM has overhead and something expecting a stream of data at a given rate might fail.

Hi,

Would you be so kind to connect your tx1 machine in recovery mode, then in linux run lsusb and then

cd /dev/bus/usb/00? and then

tail -f 00? | hexdump -c

where the first 00? is the bus and the second 00? is the device and then let me know the result?

I got the first four as \022\001\020\002

USB devices are hot plug, so the bus/device will change depending on insert order or enumeration order. In my case I have the TX1 showing in recovery mode as bus 003, device 012. My host is Fedora, but the USB information should be identical to yours. Here is the result:

> cat /dev/bus/usb/003/012 | hexdump -c
0000000 022 001  \0 002  \0  \0  \0   @   U  \t   !   w 002 001 001 002
0000010  \0 001  \t 002      \0 001 001  \0 300 020  \t 004  \0  \0 002
0000020 377 377 377  \0  \a 005 201 002  \0 002  \0  \a 005 001 002  \0
0000030 002  \0                                                        
0000032

Hi,

Thank you very much indeed. No it is not identical I got:

0000000 022 001 020 002 \0 \0 \0 @ U \t = � � � 001 002
0000010 003 001 \t 002 C \0 002 001 \0 200 � 005 \t 003 \0 002
0000020 \t 004 \0 \0 003 � � \0 006 \a 005 201 002 \0 002 \0
0000030 \a 005 001 002 \0 002 \0 \a 005 202 003 034 \0 006 \t 004
0000040 001 \0 002 � B 001 005 \a 005 002 002 \0 002 \0 \a 005

By “identical” I should probably clarify that I mean “produces the same result if the input is the same”. I don’t know if there might be other reasons why my USB port reads differently from yours since I don’t know what the hex dump data shows. It might be of more use to use “usbmon” or a protocol analyzer. In case it helps, this is what my verbose “sudo lsusb -d 0955:7721 -vvv” shows for the TX1 in recovery mode…this will tell in a portable way what my host thinks the device is:

Bus 003 Device 010: ID 0955:7721 NVidia Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0955 NVidia Corp.
  idProduct          0x7721 
  bcdDevice            1.02
  iManufacturer           1 NVIDIA Corp.
  iProduct                2 APX
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower               32mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

NOTE: If lsusb shows the same, then I would expect any failure to be from data pipe issues (to emphasize, it is a known issue that VMs do not work correctly during a flash without extra tweaks).

Hi,

Thank you very much, you have been of great help as ever.

To be honest it does not work because they are different, it is a shield tv.

I’m trying to update the bpmp.bin file but neither fastboot or tegradevflash seem to work.

I think the SoC in a Shield TV is different from that of the Jetson. The Jetson TX1 is a tegra21x series, but the specific implementation is the tegra210. I don’t know about your case, but I believe there is a Shield TV out there which is a tegra21x series, but which is not specifically a tegra210 implementation (I’m not really sure about what the specific implementation is for Shield TV).

The module board surrounding the SoC is very very likely quite different from the board the Shield TV has…which implies boot structure and device tree are not compatible…don’t know for sure.

Despite all of this the USB over VM is likely still an issue regardless of whether it is a Shield TV or a Jetson.

The SoC is the some, the name of the board is different, but is still tegra210.

I am investigating the tegradevflash functions in order to understand what check are performed on the USB.

I do not have any problem doing other things, such adb or fastboot with VM, so I would rule out the VM issue.

It’s up to you, but I believe the error you see is a USB pipe issue, and not dependent on data. I’m not saying there won’t be issues when trying to make Jetson tools work with a Shield TV (nothing in the surrounding environment is the same…boards need a BSP and Shield TV BSP will be very different from a Jetson), but the error you have is very likely to be tied to the VM (I do not believe you got far enough for the BSP to get in the way, and this error repeatedly shows up for people using a VM in an otherwise valid configuration).

Well, the only thing that I need is to adapt tegradevflash to the shield tv, since fastboot does not work for me.

Hi, so sorry, I used the wrong command, could you please repeat the command, but this time:

cat /dev/bus/usb/BBB/DDD | head c1024 | hexdump and let me know the result?

BBB is the bus number and DDD is the device number of the Nvidia box.

Thanks