USB 3.0 hub not work on TX2

I have a USB 3.0 hub, the chip is RTS5411. It works find on my desktop, but not work on TX2.

The dmesg output is below.

[ 1427.500383] usb 1-2: new high-speed USB device number 4 using xhci-tegra
[ 1427.646533] usb 1-2: New USB device found, idVendor=0bda, idProduct=5411
[ 1427.653288] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1427.660451] usb 1-2: Product: 4-Port USB 2.0 Hub
[ 1427.665098] usb 1-2: Manufacturer: Generic
[ 1427.669977] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 1427.677224] hub 1-2:1.0: USB hub found
[ 1427.682276] hub 1-2:1.0: 4 ports detected
[ 1429.828373] xhci-tegra 3530000.xhci: entering ELPG
[ 1429.836951] xhci-tegra 3530000.xhci: entering ELPG done
[ 1429.846188] xhci-tegra 3530000.xhci: exiting ELPG
[ 1429.872700] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[ 1429.885597] xhci-tegra 3530000.xhci: exiting ELPG done
[ 1429.885617] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 1431.896388] xhci-tegra 3530000.xhci: entering ELPG
[ 1431.903948] xhci-tegra 3530000.xhci: entering ELPG done
[ 1431.914145] xhci-tegra 3530000.xhci: exiting ELPG
[ 1431.940687] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[ 1431.953593] xhci-tegra 3530000.xhci: exiting ELPG done
[ 1431.953614] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 1433.964393] xhci-tegra 3530000.xhci: entering ELPG
[ 1433.972201] xhci-tegra 3530000.xhci: entering ELPG done
[ 1433.982165] xhci-tegra 3530000.xhci: exiting ELPG

lsusb -t results

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M

randoms,

Is this usb2.0 hub the one you are using?

[ 1427.677224] hub 1-2:1.0: USB hub found
[ 1427.682276] hub 1-2:1.0: 4 ports detected

Hi randoms, please also connect the hub to external power supply and try again.

Yes. The TX2 board has two usb ports. The smaller one is usb 2.0 and the other is usb 3.0. My hub was connected to usb 3.0 port. But lsusb shows it was connected to the usb 2.0 port. And if I connect my hub to usb 2.0 port, it works fine in usb 2.0 mode.
I also tried to add external power supply, but no success.

Is this the dev carrier? Has the Jetson been flashed to a recent version (see “head -n 1 /etc/nv_tegra_release”)?

What is connected where in the first lsusb tree is a bit confusing. If you can log in via ssh or serial console and avoid using a keyboard, then you might run “lsusb -t” with these cases (and post the output and label so we know which is which):

  • USB3 HUB on the full-size type-A port. Nothing else connected.
  • USB2 HUB on the micro-USB port. Nothing else connected.
  • Both USB2 and USB3 HUBs connected at the same time. Nothing else connected.

Yes, it’s the dev carrier. And I also flashed the latest image.

The output of “head -n 1 /etc/nv_tegra_release”

# R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018

I only have an USB3 hub.

Results of “lsusb -t” when “USB3 HUB on the full-size type-A port”.
The USB3 hub can not work in this case. The results seem strange.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

Results of “lsusb -t” when “USB3 HUB on the micro-USB port. Nothing else connected”.
The USB3 hub can work in USB2 mode in this case.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M

And this is the “lsusb -t” output when the hub connected to the USB3 port of my desktop.
The USB3 hub can work in USB3 mode in this case.

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M

I found an USB2 hub, and here is the result “USB2 HUB on the full-size type-A port”
The USB2 hub can work in USB2 mode in this case.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 2: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M

The results of “USB2 HUB on the micro-USB port. Nothing else connected.”
The USB2 hub can work in USB2 mode in this case.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 1: Dev 15, If 0, Class=Hub, Driver=hub/4p, 480M

The results of “Both USB2 and USB3 HUBs connected at the same time. Nothing else connected.”
The USB3 hub on full-size type-A port and the USB2 hub on the micro-USB port.
The USB2 hub can work and the USB3 port cannot work in this case.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 1: Dev 15, If 0, Class=Hub, Driver=hub/4p, 480M
    |__ Port 2: Dev 16, If 0, Class=Hub, Driver=hub/4p, 480M

I’m not familiar with USB drivers, but it seems the USB3 port was not on the right bus.

Something does seem odd. However, it might just be the way the OTG (micro-USB) port is set up (explained further down). Even so, there does seem to be a legitimate problem.

Note that the “480M” at the end of a line implies USB2. A “5000M” implies USB3. Any USB3 HUB on a USB2 port should revert to USB2; any USB3 HUB on a USB3 root_hub should remain USB3. For reference, I am using R28.2.

This is no device at all on USB for my TX2:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M

This is micro-USB with a USB3 HUB for my TX2 (because micro-USB is only USB2 the USB3 HUB must report as being USB2):

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 1: Dev 16, If 0, Class=Hub, Driver=hub/4p, 480M

Here’s the tree when I move the USB3 HUB to the full-sized type-A connector, and a mystery begins since I have only one HUB connected and it isn’t on the micro-USB port:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/3p, 5000M
    |__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-tegra/4p, 480M
    |__ Port 2: Dev 17, If 0, Class=Hub, Driver=hub/4p, 480M

Notice that USB3 properly migrates to the USB3 root_hub. What seems odd is that the micro-USB port shows a HUB! This might actually be valid operation if some sort of tricky switching is involved in the micro-USB port’s “On the Go” (“OTG”) design since this port can act as either a type-A host or a type-B device. I’ll call this a “ghost HUB”. Can someone at NVIDIA comment on whether this ghost HUB is valid and a result of being an OTG port and not a dedicated type-A port? If this anomaly is “normal” it would be good to document it. If this is not normal, then consider it a reported strangeness. Test case being HUB to micro-B as only USB connection, then switch it to full-sized USB with power still running (hot plug, not reboot cold plug) while monitoring “lsusb -t”.

Now in your case I believe your USB3 port is not functioning, at least not with that particular HUB. I think that the HUB you see on micro-USB as the USB3 HUB goes to the full-sized port is this “ghost HUB”. If that is the case, then it is unrelated to the USB3 port problem. This would be purely the result of the full-sized port not working with that particular HUB (can you verify anything else works on the full-sized port, e.g., a mouse or keyboard without a HUB?). By not having anything connected to this HUB there should be no issue with power causing it to drop out. But it is necessary to first verify something about your USB3 HUB before making that assumption…

Q: Is it correct (from previous posts) that this USB3 HUB is powered? Many powered HUBs revert to being powered from the host (instead of power cable…a.k.a., “unpowered”) if the power is disconnected, but this is not true of all powered HUBs (some HUBs simply disappear). Can you verify your power cable to the HUB puts out 5V?

Complication: In some cases a HUB may have some glitch related to sleep mode and could in theory (admittedly, this is rather unlikely) fail on one host depending on sleep mode, and yet work on another host when going in/out of sleep mode. This would still be an error, but the error would perhaps be software instead of hardware, so this is why I mention this. For all tests make sure the host has not gone into “sleep mode”. You can guarantee USB never sleeps via an edit to “/boot/extlinux/extlinux.conf”, and you should do this while testing. The “APPEND” key/value pair can have this added to disable autosuspend (reboot after this edit):

usbcore.autosuspend=-1

Example:

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 <u><b>usbcore.autosuspend=-1</b></u>

As part of a way to see if the HUB is recognized at all, please monitor “dmesg --follow”, and then unplug and plug the USB3 HUB into the full-sized USB port. See if anything shows up. If you didn’t add the “autosuspend=-1”, then make sure to do this right after boot to be sure there is no sleep or low power mode going on. If something shows up via “dmesg --follow” during the event, then you know the hardware actually sees the HUB even though “lsusb -t” doesn’t report it. It then becomes a software issue should dmesg show up and not indicate a signal error. If nothing shows up, or if a signal error is mentioned, then you know it is a hardware issue.

Finally, one last test (this should perhaps be the first test). See if all show as “ok” from:

sha1sum -c /etc/nv_tegra_release

Thank you for your explain in detail.

I have tested my hub both powered and not powered, and the results had no difference.
I can used ZED camera in USB3 mode on my board, so my USB3 port can work well on some devices.

After disable autosuspend, the “dmesg” shows

[  111.008595] usb 1-2: new high-speed USB device number 2 using xhci-tegra
[  111.154713] usb 1-2: New USB device found, idVendor=0bda, idProduct=5411
[  111.161427] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  111.168882] usb 1-2: Product: 4-Port USB 2.0 Hub
[  111.173775] usb 1-2: Manufacturer: Generic
[  111.179459] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[  111.187710] hub 1-2:1.0: USB hub found
[  111.192502] hub 1-2:1.0: 4 ports detected
[  119.887086] usb 1-2: USB disconnect, device number 2
[  119.893336] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[  121.745832] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[  121.752810] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

if not disable autosuspend, “dmesg” keeps reporting “entering ELPG” and “exiting ELPG”.

entering ELPG
[   94.459552] xhci-tegra 3530000.xhci: entering ELPG done
[   94.469710] xhci-tegra 3530000.xhci: exiting ELPG
[   94.496230] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[   94.509240] xhci-tegra 3530000.xhci: exiting ELPG done
[   94.509263] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[   96.519234] xhci-tegra 3530000.xhci: entering ELPG
[   96.526895] xhci-tegra 3530000.xhci: entering ELPG done
[   96.537019] xhci-tegra 3530000.xhci: exiting ELPG
[   96.563523] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[   96.576510] xhci-tegra 3530000.xhci: exiting ELPG done
[   96.576530] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[   98.586550] xhci-tegra 3530000.xhci: entering ELPG
[   98.594252] xhci-tegra 3530000.xhci: entering ELPG done
[   98.604326] xhci-tegra 3530000.xhci: exiting ELPG
[   98.630844] xhci-tegra 3530000.xhci: Firmware timestamp: 2017-12-07 10:50:08 UTC, Version: 55.09 release
[   98.643750] xhci-tegra 3530000.xhci: exiting ELPG done
[   98.643771] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[  100.653919] xhci-tegra 3530000.xhci: entering ELPG
[  100.661582] xhci-tegra 3530000.xhci: entering ELPG done
[  100.671704] xhci-tegra 3530000.xhci: exiting ELPG

I also checked the “sha1sum -c /etc/nv_tegra_release”, and it was all ok.

But my USB hub is still not working. “lsusb -t” shows the same output.

There is a mistake in your exmaple. I should append “usbcore.autosuspend=-1” to /boot/extlinux/extlinux.conf not “autosuspend=-1”, right?

You are correct on the “usbcore.autosuspend=-1”. I had this in one location, but failed to use the full syntax in another location. I’ve updated to reflect this.

While reading this keep in mind that Jetsons are typically designed to be able to use as little power as possible. Autosuspend will rarely occur as often on a PC as it will on a Jetson. When autosuspend does take place there is different software involved versus when running normally. I believe you’ve run into a compatibility issue between the Jetson and how that HUB handles autosuspend.

According to the logs and your ZED camera it is safe to say the port works in normal operation. Either the HUB is not handling low power mode correctly, or the software on the Jetson is not handling it correctly. I have no way to test which is at fault. If possible would someone from NVIDIA comment on the ELPG error and a way to determine if it is just this HUB with issues, or if it is instead a software issue on the Jetson itself?

Meanwhile I’ll suggest to keep the “usbcore.autosuspend=-1” as a workaround.

Could you provide which BSP you are using? Is it jetpack3.2, 3.1 or 3.2.1?

It’s jetpack 3.3

randoms,

May I ask where to buy this usb hub? It looks like a compatibility issue. Also, is there any newer hub firmware to update?

randoms,

We need your help to enable some log on it to see what is going on.

  1. Please try the attached xusb FW with the following steps.
A. backup the original FW under /lib/firmware
        "sudo mv /lib/firmware/tegra18x_xusb_firmware /lib/firmware/tegra18x_xusb_firmware_backup"
    B. replace the FW in attachment with the name tegra18x_xusb_firmware under /lib/firmware/
        "sudo cp DIRECTORY_OF_FW/xusb_sil_rel_fw /lib/firmware/tegra18x_xusb_firmware"
    C. reboot device and check whether FW is replaced or not with dmesg or
         "sudo cat /sys/devices/3530000.xhci/tegra-firmware/3530000.xhci/version"
  1. Please help to get the log with the following steps to enable dynamic debug on xhci and usbcore
A. get root permission (sudo -s)
    B. enable dynamic debug 
         "echo 'module usbcore +p' > /sys/kernel/debug/dynamic_debug/control"
         "echo 'module xhci_hcd +p' > /sys/kernel/debug/dynamic_debug/control"
         "echo 8 > /proc/sys/kernel/printk"
    C. reproduce issue (plug your usb hub)

Then dmesg should have lots of log than before.

xusb_sil_rel_fw.tar.gz (73.4 KB)

I bought it from https://detail.tmall.com/item.htm?id=45710655554.

I follow your instruction, but there was no ‘tegra-firmware’ directory in /sys/devices/3530000.xhci.

And I also enabled dynamic debug. dmesg output is in the attachment.
plugin.log (68.9 KB)
out.log (9.97 KB)

randoms,

It is okay, if you make sure you have changed the firmware correctly.

So tegra still fails to detect hub even with new firmware? Is the ELPG entering/exiting error still?

I don’t see that error in your log anymore, so just want to confirm.

When testing the new firmware be sure that “usbcore.autosuspend=-1” is not used.

Hi random, for comparison, please also try r28.1 to know if it is specific to r28.2.1

I confirmed that the firmware was updated. But the hub was still not working.
I removed “usbcore.autosuspend=-1” and tested again, the result is in attachment.

I have lots of works on my TX2, so flash a new image is not easy to me.
dmesg.log (83.4 KB)