I flash my Jetson Tx1 with JetPack2.3 and I find that the full size usb3.0 port doesn't work?

When I plug USB2.0 device into the full size usb port,it can work as expected,but instead with a USB3.0 device,the system cannot identify this device.I use the command ‘lsusb -t’ and cannot find the device.I try to edit the extlinux.conf ,modify usb_port_owner_info=0 to usb_port_owner_info=2 and reboot Jetson Tx1 ,it alse doesn’t work.How to make the full size usb port work as USB3.0 mode? Thank you

USB3 mode is not enabled by default on the L4T of JetPack2.3. Most USB devices which work as USB3 will throttle back and run at USB2 speeds if a USB3 port is not available…but not all devices. There are some devices which have no purpose except at USB3 speeds…if no USB3 controller sees it, then the device never replies. What is the device?

Once you have done your usb_port_owner_info edit, what is the output of “lsusb -t”? The root HUB will be 480M if USB2, or 5000M if USB3. If 480M, then no possibility exists of a “pure” (without USB2 fallback mode) USB3 device working.

Hi,linuxdev
I try usb3.0 disk and usb3.0 camera to test the full size usb port.What i want to use is usb3.0 camera.Is there any other version of JetPack enableing the USB3.0 by default?
1.when usb_port_owner_info=0 reboot and plug the usb3.0 camera.“lsusb -t”:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/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=tegra-xhci/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

2.and the extlinux.conf is:
TIMEOUT 30
DEFAULT primary
MENU TITLE p2371-2180 eMMC boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 usbcore.autosuspend=-1 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=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait
usb_port_owner_info=2

3.when usb_port_owner_info=2. “lsusb -t”:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
|__ Port 1: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 1: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/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=tegra-xhci/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
So I edit usb_port_owner_info=2 and it still doesn’t work for usb3.0 camera.How can I enable the USB3.0 mode?Thank you.

Both of the “lsusb -t” entries show the port is at USB3 speeds on the r8152, but not the other ports, so it looks like you are correct. Because I see some USB3, but not where it is expected (explained below), there may be something else going on.

If you boot up fresh with no USB devices plugged in (except perhaps keyboard and mouse), and then monitor “dmesg” via the command “dmesg --follow”, what shows up if you then plug in the USB3 device?

NOTE: I’m currently looking at L4T R28.1 (which is flashed by JetPack 3.1), so some details may differ from your older version, but this TX1 is showing only bus 01 and bus 02 when I plug in devices to both the full-size-A connector and the micro connector (using type-A to full-size adapter to a HUB or to a USB hard drive). I would have to flash to an older version of L4T to duplicate your setup, but it still seems strange to see three bus enumerations. In older distributions your usb_port_owner_info=2 edit should work, so it seems something odd is going on. Do you have any custom USB additions, e.g., a PCIe HUB?

In order to know what the kernel actually thinks its boot command line was, what is the output of this?

cat /proc/cmdline

Also, what L4T version shows from:

head -n 1 /etc/nv_tegra_release

To see if hardware drivers are in place, do any of these show NOT ok?

sha1sum -c /etc/nv_tegra_release

FYI, the port edit you made should have done the job, but L4T R28.1 does enable the port as USB3 by default (this is flashed via JetPack3.1). However, it might be of use to figure out what is going on before you flash since some issues might imply the problem wouldn’t be fixed by flash.

Hi,linuxdev.First thanks for your reply.
1.if I boot up fresh( only keyboard and mouse),I also can see the device Vendor as fllows:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
when i use command “mesg --follow”,I can see that:
[ 2.945082] usbcore: registered new interface driver r8152
[ 5.485981] r8152 2-1:1.0 eth0: v2.03.3 (2015/01/29)
[ 5.485986] r8152 2-1:1.0 eth0: This product is covered by one or more of the following patents:
so it may be a NVIDIA’s network device ?I see some other users also have this device.
2.When I plug in usb3.0 disk to the full-size-A connector,i cannot see anything about this device under the comamd of “dmesg --follow”,and I use the command “lsusb -t” ,i als0 cannnot see the device.But with a usb2.0 disk can work as expected.When i plug in usb3.0 camera to the full-size-A connector,it can detected the usb3.0 camera under the command “dmesg --follow”,as follows:
[ 3.799612] usb 1-3: New USB device found, idVendor=1e4e, idProduct=0568
[ 3.799618] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.799623] usb 1-3: Product: usb3.0 camera
[ 3.799627] usb 1-3: Manufacturer: tuguan
[ 3.799630] usb 1-3: SerialNumber: 00000000000000000002
[ 3.825930] uvcvideo: Found UVC 1.00 device usb3.0 camera (1e4e:0568)
but it will work in USB2.0 mode,when i see from “lsusb -t”.Sorry,this is a little different from previous description.But USB3.0 doesn’t work even if I edit usb_port_owner_info=0 to usb_port_owner_info=2.I see almost the same problem in your previous reply in #17 under other question,the link is as follows:
[url]https://devtalk.nvidia.com/default/topic/949486/jetson-tx1/usb-issues-with-l4t-24-1-/2[/url]
So it is can’t change the full-size-type A connector’s USB mode via this way?I see some users change the USB mode via changing the kernel,it seems too difficult.
3.I use the min connector and full-size connector,so I can see three bus form bus01 to bus03,if I only use full-size connector and i can only see bus1 and bus2.I never custom USB additions.

the command “cat /proc/cmdline” output as follows:

fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 usbcore.autosuspend=-1 usb_port_owner_info=2 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=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

the command “head -n 1 /etc/nv_tegra_release” output as follows:

R24 (release), REVISION: 2.1, GCID: 8028265, BOARD: t210ref, EABI: aarch64, DATE: Thu Nov 10 03:51:59 UTC 2016

the command “sha1sum -c /etc/nv_tegra_release” output are all ok.

Thank you again.

Let me verify the current L4T release you are using via this (I’m thinking probably the answer is R24.2.1):

head -n 1 /etc/nv_tegra_release

NOTE: Probably the best advice is to flash to R28.1 and then try it, but the problem is interesting, plus it may be of use to figure out what is going on even if you do flash to R28.1. Currently my TX1 is loaded with R28.1 so I’d need to reflash to test under older versions…I’m depending on logs I saved.

I think the posting of various logs and information is getting confusing and hard to track (I’m not sure which logs show under USB3 mode and which show under USB2 mode). I’m hoping to consolidate here to make sure mistakes are not being made. I may be asking for information here which is already posted, but this is so I can verify with so much going on (sorry, it may mean duplication of effort…this is part of the added overhead of remote debugging through a third party).

First, a problem restatement for your verification: It seems to be that you have two USB3 devices, one of which works on a USB3 port, the other which does not work on a USB3 port. One device is a camera, the other is an external USB hard drive. When the troublesome device is connected under USB3 it does not show up at all in “lsusb”, nor in dmesg. The other USB3 device works as expected. The device which does not work under USB3 does work if port mode is USB2. Is this correct?

Is it correct that it is the camera which fails under USB3? If so, then it isn’t a port mode issue since the port is in USB3 mode…this would be an issue of the USB3 pipe failing to see the device, perhaps because of a signal quality issue or power delivery being insufficient. Had the device not shown up in USB2 mode the story would be different…in that case it would be because the camera is pure USB3 without USB2 compatibility.

NOTE: For all cases of a missing signal an external HUB would be of use since it alters which PHY is used directly on the Jetson. For all cases of checking for power delivery issues a test should be run with an external HUB which is also externally powered…can you try a powered USB3 HUB? What kind of current HUB do you use? What kind of cable adapters do you use?

One more thing to verify: Once under USB2 mode, and once under USB3 mode, which mode is shown from this (it’ll be the “0” or “2”):

egrep 'usb_port_owner_info[=][0-9]' /proc/cmdline

Some information: The camera appears to be a standard USB Video Class (thus you will see references to “Driver=uvcvideo” under “lsusb -t”. In all cases where this line shows under lsusb it implies USB has done its job and has handed off to the standard UVC driver. Since no “lsusb -t” shows up under USB3 it implies USB itself has failed, not the UVC driver. I would like to verify that when this occurs there is still a root_hub line in “lsusb -t” which shows a speed of “5000M” at the end of the line…this verifies USB3 mode. This would also make the next debug step to be use of an externally powered USB3 HUB to see if anything changes. Should this help, then it implies flashing to a new software version would not help since power/hardware issues would remain. Testing with an externally powered USB3 HUB will simplify your future steps.

I would also like to verify that in USB3 mode the working USB3 hard drive shows up in “lsusb -t” with “5000M” on its speed listing at the right side of its “lsusb -t” line. This will validate software and hardware of the Jetson itself…leave the camera disconnected during this test.

Thanks,linux.
I have already flashed to R28.1,but the problem still exists.
Yes,I have two USB3 device,one is USB3 disk and another is USB3 camera.In the previous version of JetPack2.3,if I directly plug in the USB3 disk to the full-size-tpyeA connector(with no hub),the USB3 disk will not work.Then I directly plug in the USB3 camera to this port,the camera will work under USB2 mode rather than USB3.Even if I edit usb_port_owner_info=0 to usb_port_owner_info=2 and rebbot ,the result is the same.So in this two conditions ,the connector both don’t work as USB3 and can work as USB2.
Now,I have flashed to R28.1,but the result still the same.I can see the USB3 bus as follow,but when I plug in the USB3 device to the full-size-tpyeA connetcor,it still don’t work as USB3.I can see USB3 bus using comamnd “lsusb -t”,does that mean the USB3 have already been enabled???But why I can’t let my device work as USB3 mode??? I am so confusing.
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
I have a powered USB3 HUB,I plug in this hub to the full-size-typeA connector and powerd by anthor USB lane.and then I plug in USB3 camera and USB3 disk,both of them will not work,When i get a USB2 HUB instead of The USB3 HUB ,this two device can work as USB2.
SO the full-size connector cannot work as USB3.I suspect the full-size connector have been borken??
Are there any ways to verify this??In your Tx1,do you have this device dirver=r8152?and what use of this device??
I really don’t how to solve this problem.Actually I want to connect four usbcamera to the Tx1,but the bandwith of USB2 is’t enough and it can only connect two USb2.0 camera,so I want to use two USB3 camera and even more work under USB3 mode,so it can achieve my goal.
Thanks again.

Ok, so it isn’t the camera which fails then, it is the disk. A disk does use more power, especially on start-up. Power seems more likely to be an issue (especially under USB3 where power limits put more stress on USB devices powered by host instead of by powered HUB). There may be some effect from having exceeded the port’s ability to deliver power and then switching to another device on that port (e.g., power reset may not have completed on the bus…in which case the camera would not show up since it is not powered…switching to USB2 may change power delivery).

Having R28.1 also fail in the same manner tends to strengthen the probability of non-software causes.

Seeing “5000M” on “lsusb -t” confirms the port is in USB3 mode. The micro-USB port of course will always be in USB2 mode, so “5000M” is proof the full-sized USB type-A port is running at USB3 speeds.

The r8152 is the ethernet chip from Realtek which is connected through a USB lane (networking on a TX1 does not go through PCIe).

The HUB test is good, but I am confused by what you mean when you say “powered by another USB lane”. Is this not powered by an outside power adapter?

Note that if there is an excess power drain the port is designed to shut off power delivery. This could be from too much power drain by all devices combined when on an unpowered port, but it could also be from a defect in the hardware being plugged in. There is a possibility that there is a fault in the disk. When in USB2 mode standards change, and so it is actually reasonable that a USB3 device could fail in USB3 mode with a defect, yet work in USB2 mode. It isn’t necessarily the Jetson failing, it might be the Jetson reacting to failed external hardware. Can you explain more about the powered HUB? And are you sure the HUB itself did not fail in some way (powered HUBs revert to pulling power from the host if the external power is not supplied)?

Note that if you use a verbose listing from lsusb for the HUB that it should tell you if it is externally powered or not. If you use just plain “lsusb”, then there will be an “ID” given. Match that ID to your powered HUB, then get a verbose listing. I’ll use ID “0955:7721” as an example, but substitute for your HUB (make it a fresh boot and don’t plug anything into the HUB if possible…a keyboard/mouse would probably be ok if needed):

lsusb -d 0955:7721 -vvv

Added note: If a non-powered HUB is used, then no two devices combined can exceed the rated standard maximum power threshold. A single USB device consuming close to full allowed power would imply no other devices can be added.