TX1 devkit, Jetpack 3.1 (R28.1): no USB3 connection on USB3 port

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hello,
On my TX1 devkit with Jetpack 3.1, I am having trouble detecting any USB 3 device as USB 3 on the Devkit’s native USB 3 (blue) port. I was previously using Jetpack 2.2 with no problems.

I have tried setting usb_port_owner_info=2 in /boot/extlinux/extlinux.conf as well as by interrupting U-Boot via serial and setenv’ing saveenv’ing it.
I’ve tried also with various USB 3 hard drives, thumb drives, hubs, and cameras.
Any thoughts or suggestions are appreciated!

More info:
:
nvidia@tegra-ubuntu:/proc$ cat cmdline
root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 androidboot.modem=none androidboot.serialno=03252150220590408104 androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff2bf000 nvdumper_reserved=0xff23f000 core_edp_mv=1075 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootloader=00.00.2014.50-t210-fadd1be5 androidboot.verifiedbootstate=orange root=/dev/mmcblk0p1 rw rootwait usb_port_owner_info=2 usbcore.usbfs_memory_mb=1000

:
nvidia@tegra-ubuntu:/proc$ head -n 1 /etc/nv_tegra_release

R28 (release), REVISION: 1.0, GCID: 9379712, BOARD: t210ref, EABI: aarch64, DATE: Thu Jul 20 07:45:59 UTC 2017

:
nvidia@tegra-ubuntu:/proc$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M

<attaching usb 3 thumb drive>:
nvidia@tegra-ubuntu:/proc$
[ 509.356248] usb 1-3: new high-speed USB device number 11 using xhci-tegra
[ 509.392871] usb 1-3: New USB device found, idVendor=154b, idProduct=00ad
[ 509.399957] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 509.408120] usb 1-3: Product: USB 3.0 FD
[ 509.412283] usb 1-3: Manufacturer: PNY Technologies
[ 509.418072] usb 1-3: SerialNumber: AA5B1025E0013636
[ 509.426682] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 509.433183] scsi host3: usb-storage 1-3:1.0
[ 510.856206] scsi 3:0:0:0: Direct-Access PNY USB 3.0 FD 1100 PQ: 0 ANSI: 6
[ 510.865742] sd 3:0:0:0: [sda] 266797056 512-byte logical blocks: (137 GB/127 GiB)
[ 510.876519] sd 3:0:0:0: [sda] Write Protect is off
[ 510.881361] sd 3:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 510.888057] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 510.910554] sda: sda1
[ 510.916228] sd 3:0:0:0: [sda] Attached SCSI removable disk

:
nvidia@tegra-ubuntu:/proc$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 11, If 0, Class=Mass Storage, Driver=usb-storage, 480M

2

You have two listings for usb_port_owner_info. I think the last one is the one which would actually be used, and it should be “0” for USB3, but your “lsusb -t” does show a USB3 port is running (the 5000M entries).

I’m not sure what the “blue” port means, but the full-sized port is capable of USB3, the micro-USB port is not capable of USB3.

Is your drive plugged directly into the full-sized port? Or is it via a HUB going to the full-sized port?

3

Thanks for the reply!
Yes, I guess the second entry comes from the line I added into /extlinux/extlinux.conf. As I understand, in 28.1 the things that were in the conf file are not put into U-Boot, but the file can still be used to add additional entries. That’s one of the things I was confused about - does it overwrite, is it ignored, etc…
You’re right too, the blue port is the full sized port for USB3. At the moment I don’t have anything connected to the micro-usb port just in case (I’m connecting from another PC through the serial port to get to my shell and see bootup messages, etc.)
Yep, in that last lsusb -t dump I have the usb3 thumb drive directly connected to the fullsize port.

So far nothing I try can get a usb3 device on that port to show up under the usb3 bus (bus 02).
very puzzling…
Thanks again!

4

Are you sure the thumb drive is USB3? Perhaps “lsusb -t” on a known USB3 port of a desktop Linux PC to be sure.

If you want to try editing usb_port_owner_info, just edit the existing entry. Setting a single entry to “2” should do the trick.

I booted with “usb_port_owner_info=2”, and this is what shows up with nothing attached:

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

Here is what shows up with a ZED USB3 stereo camera (full sized port):

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/2p, 5000M
    |__ Port 1: Dev 3, If 0, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 1: Dev 3, If 1, Class=Video, Driver=uvcvideo, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/6p, 480M

(note that my USB3 device is 5000M and shows up under a 5000M root_hub)

This is my “/proc/cmdline” under R21.6 (see “head -n 1 /etc/nv_tegra_release”):

console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 <u><i><b>usb_port_owner_info=2</b></i></u> lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
5

Hi matt,
We have SQA tests before each release. It should not happen if you clean flash the devkit via Jetpack3.1. Could you try Jetpack3.2.1 also?

6

Thanks all for the help. I have tried the following this morning, but still have the same problem:

  • reverted my /boot/extlinux/extlinux.conf to default
  • used U-boot to edit both bootargs and cbootargs to change usb_port_owner_info=2
    – this does not work when continuing to boot, although it appears the usb_port_owner_info change is honored when cat’ing /proc/cmdline
    – upon reboot, the changes to bootargs and cbootargs are not honored. Output From the serial console:
    Hit any key to stop autoboot: 0
    MMC: no card present
    switch to partitions #0, OK
    mmc0(part 0) is current device
    Scanning mmc 0:1…
    Found /boot/extlinux/extlinux.conf
    Retrieving file: /boot/extlinux/extlinux.conf
    222 bytes read in 87 ms (2 KiB/s)
    p2371-2180 eMMC boot options
    1: primary kernel
    Enter choice: 1: primary kernel
    Retrieving file: /boot/initrd
    0 bytes read in 47 ms (0 Bytes/s)
    Retrieving file: /boot/Image
    20984368 bytes read in 523 ms (38.3 MiB/s)
    append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 androidboot.modem=none androidboot.serialno=03252150220590408104 androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff2bf000 nvdumper_reserved=0xff23f000 core_edp_mv=1075 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootloader=00.00.2014.50-t210-fadd1be5 androidboot.verifiedbootstate=orange root=/dev/mmcblk0p1 rw rootwait
    – my method for editing the u-boot variables is from here https://devtalk.nvidia.com/default/topic/1025454/jetson-tx2/how-to-change-cbootargs/
    after the edit, I do saveenv, which says a successful write to mmc, and then I type boot to continue.

Could it be that I am not saving the cbootargs & bootargs variables correctly?

Note:
I realize after some homework that with r28.1, U-boot will have the arguments, and then it loads extlinux.conf for further appends, so I guess it should really not matter where (or how many times) I set the argument, but as a shot in the dark I thought I’d try editing the u-boot variables directly.
If it turns out that it does not matter where I set usb_port_owner_info, then I can say that setting it to 2 does not have any impact on the issue. Still no verfied USB3 device is detected as USB3 on the full size port.
I guess as a last resort I could try reinstalling jetpack 3.1 or upgrading, but this make take some time (and an upgrade may conflict with some other needs of the application. I’m not sure yet…)

Thanks again!

7

My previous testing was with R28.2 on a TX2, and so I’ve specifically gone to the TX1 (but it too is R28.2, not R28.1). YMMV.

With this as my “/proc/cmdline”, and a USB3 HUB on the full-sized port:

root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 androidboot.modem=none androidboot.serialno=03244150325660808206 androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize <u><i><b>usb_port_owner_info=0</b></i></u> lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff2bf000 nvdumper_reserved=0xff23f000 core_edp_mv=1075 core_edp_ma=4000 tegra_fbmem=0x140000@0x92c9d000 is_hdmi_initialised=1 gpt root=/dev/mmcblk0p1 rw rootwait

…the “lsusb -t” shows:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
    |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

At first this seems somewhat odd. The micro-USB port is not connected, and the usb_port_owner_info is still the default “0” (USB3 is achievable without kernel parameter changes). I never had to do anything to get USB3. I expected the devices (other than the HUB itself) to show up at lower speeds (they are keyboard/mouse type items), and this was correct. The HUB for USB3 does show up under USB3, while the slower speed items move over to a non-existent virtual USB2 HUB despite being plugged in physically to the USB3 HUB. I suspect this is due to how USB3 provides backwards compatibility…

In the past a single USB controller controlled all USB protocol versions and had knowledge of current and legacy protocols.

Now, instead of a single controller providing the services for any PHY, different devices will route to a different controller when required (the full-sized type-A PHY is dynamically routed to different controllers…legacy or USB3). In the case of a USB2 controller this controller will understand USB1/USB1.1 along with USB2 (the standards are built into the same controller). USB3 controllers do not provide services to legacy protocols. At least this is what I think is going on…it seems to just be the logic of the lsusb tree view not necessarily being tied to the PHY…the logic is tied instead to the controller (and either controller might touch the full-sized port).

So…I removed everything on USB, and connected just a ZED stereo camera (USB3) and no HUB to the full-sized type-A PHY. This is the new “lsusb -t”:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
    |__ Port 2: Dev 4, If 0, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 2: Dev 4, If 1, Class=Video, Driver=uvcvideo, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M

Indeed, this is correct. So from all I can see we can no longer associate a tree view to physical connector…the internal logic means the same full-sized type-A connector can go to two different controllers, depending on what is being controlled.

It is too bad lsusb doesn’t have the ability to provide some sort of “PHY-ID” to alleviate the confusion. I believe your system has been working correctly and using different controllers on a single port depending on what protocol the end device supports.

It may be that any individual device needs to be listed via “lsusb -vvv” to see what mode it is truly in if you want verification.

8

Thanks Linuxdev for the continued help.
If we talk about devices connected to hubs, believe it or not, I’m actually seeing the inverse of what should be… (I’m ok with the lsusb tree not matching up with connectors btw. I pretty much expected it was just a logical representation.)

If I go USB3 device → USB3 hub → full size USB3 port, I actually see the hub detected as USB2 and the device detected as USB3 (yep, not a typo :)). And when in this configuration, it takes some time to connect to the device from an application (several seconds longer than expected). Although, I do get the USB3 bandwidth & speeds I’d expect (yep, how does a USB3 device work as expected through a USB3 hub detected as USB2…)

Actually I was quite thankful when I could reduce the problem to a symptom of no usb3 device detected to as usb3 when directly connected to usb3, because the device->hub->port symptom was incredibly weird…

Nevertheless, I just finished a fresh install of jetpack 3.1 r28.1, so I will try again on Monday.
I will also have access to another system around that time too. I can’t rule out the possibility of a physical damage to some connector, trace, etc…

I’ll add updating to 28.2 as a task also.

Thank you again!

9

I know you’ve posted other “lsusb -t” trees, but could you post again for these cases:

  • No USB devices at all.
  • Just the USB3 HUB with nothing else on the full-sized connector.
  • Just the USB3 thumb drive directly on the full-sized port. A non-tree "lsusb" as well for this configuration.
  • The thumb drive on the USB3 HUB with the HUB on the full-sized port.

(I’m hoping to get a condensed summary where I know the exact configurations)

10

Hi Linuxdev,
Here are the lsusb trees as requested, as well as some others.
-No USB devices at all. → Test 1
-Just the USB3 HUB with nothing else on the full-sized connector. → Test 4.
-Just the USB3 thumb drive directly on the full-sized port. → Test 2.
–A non-tree “lsusb” as well for this configuration. → Test 2
-The thumb drive on the USB3 HUB with the HUB on the full-sized port. → Test 9.

Notes:

  • I also have a USB3 camera, and I should mention this is the ultimate goal: To get this camera detected as USB3 and have no “3-second delay” in accessing (Test 7 should result in OK, OK). I have tried several other cameras but they produce the same results.
  • Cold boot is defined as shutting down via sudo shutdown -h now, pulling board power, then attaching devices, applying power, and booting up with the pwr button.
  • Hotplug is defined as pulling out device, waiting 5 seconds, then plugging it back in.
  • This is on a clean re-install of Jetpack 3.1. I added the camera’s supporting software just before Test 7.
  • CORRECTION: I mentioned USB3Device–>USB3Hub–>FullSizePort = USB3Device detected as USB3, while USB3Hub detected as USB2. This is not the case after the re-install of Jetpack. Now I do see the USB3 hub detected as USB3, even after hotplugging it (Test 5).
    The powered hub is now the only USB3 device which will detect as USB3 when directly connected.

Thank you for your patience!!

Test 1:
Cold boot with nothing attached:
nvidia@tegra-ubuntu:~$ lsusb
Bus 002 Device 002: ID 0955:09ff NVidia Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M

Test 2:
Cold boot with only USB3 thumb drive directly connected to board:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
nvidia@tegra-ubuntu:~$ lsusb
Bus 002 Device 002: ID 0955:09ff NVidia Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 154b:00ad PNY
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Test 3:
Cold boot with only USB3 camera directly connected to board:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Miscellaneous Device, Driver=, 480M
|__ Port 3: Dev 2, If 1, Class=Miscellaneous Device, Driver=, 480M

Test 4:
Cold boot with only USB3 hub (powered) directly connected to board:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

Test 5:
Cold boot with USB3 thumb drive already directly connected, then hotplug thumb drive:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
[NOW HOTPLUG THUMBDRIVE]
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Test 6:
Cold boot with only USB3 powered hub already directly connected, then hotplug hub:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
[NOW HOTPLUG HUB]
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M

Test 7:
Cold boot with only USB3 camera already connected directly to board, then hotplug camera:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Miscellaneous Device, Driver=, 480M
|__ Port 3: Dev 2, If 1, Class=Miscellaneous Device, Driver=, 480M
[NOW TEST DEVICE ACCESS TIME]
nvidia@tegra-ubuntu:~$ cd Downloads/BaslerGrabTime/
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ ./Grab2
Calling Open() at 0.210203
Open() finished at 0.217781 <— OK
USB Connection: HighSpeed <— NOT OK (should be SuperSpeed)
[NOW HOTPLUG CAMERA]
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ ./Grab2
Initializing pylon
Initialized pylon at 0.000357
An exception occurred.
No device is available or no device contains the provided device info properties <— USB3 camera not detected at all anymore

Test 8:
Cold boot with camera–>powered hub–>board already connected:
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 4, If 0, Class=Miscellaneous Device, Driver=, 5000M
|__ Port 2: Dev 4, If 1, Class=Miscellaneous Device, Driver=, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
[NOW TEST DEVICE ACCESS TIME]
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ ./Grab2
Calling Open() at 0.132567
Open() finished at 3.20143 <— NOT OK (should be ~0.2 seconds)
USB Connection: SuperSpeed <— OK
[NOW HOTPLUG CAMERA]
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 5, If 0, Class=Miscellaneous Device, Driver=, 5000M
|__ Port 2: Dev 5, If 1, Class=Miscellaneous Device, Driver=, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
[NOW TEST DEVICE ACCESS TIME]
nvidia@tegra-ubuntu:~/Downloads/BaslerGrabTime$ ./Grab2
Calling Open() at 0.127676
Open() finished at 3.19326 <— this duration takes 3 seconds longer than expected
USB Connection: SuperSpeed <— but the device is detected as USB 3

Test 9:
Cold boot with thumbdrive–>powered hub–>board already connected:
nvidia@tegra-ubuntu:~$ lsusb
Bus 002 Device 005: ID 154b:00ad PNY
Bus 002 Device 003: ID 0451:8046 Texas Instruments, Inc.
Bus 002 Device 002: ID 0955:09ff NVidia Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0451:8044 Texas Instruments, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
[NOW HOTPLUG THUMBDRIVE]
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

11

Update. I’m beginning to wonder if this is hardware related to this unit.
After a clean install of Jetpack 3.2 (R28.2), the problem is unchanged:

nvidia@tegra-ubuntu:~$ head -n 1 /etc/nv_tegra_release

R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI: aarch64, D ATE: Fri Mar 2 04:58:16 UTC 2018

[COLD BOOT WITH THUMB DRIVE ALREADY INSERTED]
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
[HOTPLUG THUMB DRIVE]
nvidia@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/5p, 480M
|__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Note: The output is identical with and without the addition of usb_port_owner_info=2 to /boot/extlinux/extlinux.conf

12

In all cases I am assuming the full-sized USB connector was used for the port which connects to the Jetson.

I see the USB3 thumb drive shows only as USB2, as does the USB3 camera (neither are put in USB3 mode).

On the other hand, the HUB does indeed show as USB3. There may be influencing details, but the basic gist is that the USB3 port works and the items plugged in do not work (at least on that particular port)…things like signal quality can cause a USB3 device to work on one port but not on another. Here is the line showing this:

Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M

Hot plug of the USB3 HUB with nothing on it also functions correctly.

The r8152 is the internal ethernet controller, and this can be ignored for our purposes.

This test is interesting because the camera shows up as USB3 despite failing in some previous cases:

Test 8:
Cold boot with camera-->powered hub-->board already connected:

The actual camera time open was perhaps slow, but mode was USB3. Slow open could imply signal quality issues which were not severe enough to cause disconnect. In this case the signal is between camera and HUB, then again from HUB to Jetson. It is Camera->Jetson which fails, while the HUB->Jetson succeeds. Apparently signal is ok between HUB and Jetson, or between HUB and camera, but not between camera and Jetson.

The same results are verified with the thumb drive in test 9. Thumb drive to HUB has good signal, HUB to Jetson has good signal, but thumb drive to Jetson signal is insufficient to be in USB3 mode.

I can’t conclude where the source of a bad signal quality is. The problem is that signal quality is bound to the entire path from device to PHY, and no one segment shows failure at all times.

Someone from NVIDIA may have a suggestion for how to mark or test signal quality through added software debugging configuration somewhere, but I do not personally know of any way to do this without a USB3 analyzer (and those are quite expensive).

13

Hi matt,
Can you once again use Jetpack 2.2? You have seen it working on Jetpack 2.2. If it is a HW issue, it should fail with Jetpack 2.2 also.

14

Hi, sorry for the delay. Here’s a short update:
I tried on another TX1 devkit, and everything detects fine :).
I still have the delay in accessing the camera, but I believe this is at a higher level, maybe some difference in libusb, etc.

If anyone is interested, here are the ID’s of the boards. I’m not sure if it makes any difference for the detection problem:
699-82597-0000-302 D: USB3 detection problems + delay problems
699-82597-0000-500 C: Delay problems only

PS:
I will be chasing the delay problem now, and also taking some time off soon, so I might not be back to the forum to talk about the detection issue for a while.
But as another board detects things fine, I am ok with closing this case now.
I’ll reopen a separate one if the ‘delay problem’ needs it.

Thanks again all!