[SOLVED] [L4T 21.1] Enable USB 3.0

Has anybody been able to enable the USB port as 3.0 in the L4T 21.1 release? I’ve changed the jetson-tk1.conf ODMDATA Environment variable to 0x6209C000 setting as described in the documentation to set the USB port as 3.0 before flashing. However, after flashing the Jetson, the port reports back as 2.0.

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            3.10
  iManufacturer           3 Linux 3.10.40-g8c4516e ehci_hcd
  iProduct                2 Tegra EHCI Host Controller
  iSerial                 1 tegra-ehci.2
 ...

On 19.3, using the same procedure, the port reports back as 3.0:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         3 
  bMaxPacketSize0         9
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
  bcdDevice            3.10
  iManufacturer           3 Linux 3.10.24-gf455cd4 tegra-xhci
  iProduct                2 Nvidia xHCI Host Controller
  iSerial                  1 tegra-xhci
 ...

I’ve done it a few times for 21.1, in case I bungled it as well as recreating on 19.3. Each time it worked on 19.3, but not on 21.1. What else needs to be done?

I haven’t tried this yet (I don’t have any USB3 devices) but noticed the one which is successful lists tegra-xhci driver while the failed newer one lists tegra-ehci.2 (the iSerial part). Just speculation that perhaps firmware has to be USB3 during boot followed by USB3 drivers…that in the failed case maybe it’s setting up firmware correctly but then loading the incorrect USB2 driver. Is the USB3 driver in 3.10.40 still tegra-xhci?

How is your U-Boot configuration ?
What is the current value of usb_port_owner_info ?
usb_port_owner_info=2 #use USB 3.0

L4T 19.3 with U-Boot:
ubuntu@tegra-ubuntu:~$ cat /boot/extlinux.conf
TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 SD Card boot options

LABEL primary
MENU LABEL primary kernel
LINUX zImage
FDT tegra124-pm375.dtb

  APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M 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 usb_port_owner_info=2 fbcon=map:1 commchip_id=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk1p1 rw rootwait

http://bitkistl.blogspot.co.at/2014/03/evaluating-jetson-tk1-board.html

Thanks linuxdev and peba.

L4T 21.1 now uses U-Boot as the default boot loader. I’ll guess that the ODMDATA environment variable was used for configuring Fastboot.

The boot configuration file is located here: /boot/extlinux/extlinux.conf
There are several example configuration files in that directory which describe how to boot from different devices.

The new config file switches the USB port to 3.0, and boots from the default internal flash memory.
usb_port_owner_info=2 #USB 3.0

Here’s the new config file:

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/zImage
FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M 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 usb_port_owner_info=2 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

====
Notes:

  1. There are two usb_port_owner_info specs in the original extlinux.conf, only one is needed.

  2. This file can be changed on the Jetson board after you flash it, and the changes will take effect. A different option may be to modify the host side before flashing.

  3. The manual from Tegra Linux Driver Package UBoot 19.3:

https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra_Linux_Driver_Package_UBoot_R19.3.pdf

states that you should be able to interrupt the boot sequence by pressing any key during boot. That did not work for me.

Neat, great tip! That appears to work well. Modifying the /boot/extlinux/extlinux.conf to select between USB 2 and 3 via U-Boot is a quick edit:

Interrupting boot via serial terminal:

Selecting (1):

Selecting (2):

@Kangalow
Are you sure it makes sense to set the
usb_port_owner_info value two times in the config ?

Could it be that the value is taken which is set as last ?
You could try to add usb_port_owner_info=0 a third time at the end
of this config file.

@peba
To be honest, I’m not quite sure what to make of the kernel parameters at this point. Note that I just changed the existing extlinux.conf file, which has the extra entry. I don’t know how it was originally generated, I thought it was generated as a result of compiling the device tree; now I don’t know. When I look at the source code in the kernel (board-ardbeg.c, the Jetson is BOARD_PM375) it indeed appears that usb_port_owner_info is a static int set before calling ardbeg_usb_init() and ardbeg_xusb_init() to setup the USB ports.

It could be that someone in charge had a working version of the kernel parameters for another board, and mistakenly added an extra entry. Then replicated it for all of the samples for different boot options (SD, USB, etc). But there are two USB ports, I’m not sure how you would set them up independently after glancing at the code.

I did notice that the Grinch kernel took out the extra entry. Since I can’t say I fully understand what’s going on at this point (I couldn’t easily figure out where the usb_port_owner_info is set from the kernel parameter parser, for example) I just would fallback to modifying the least amount of code that I could to get it to work for now.

I’m sure you’re more experienced than I am in this area, so I’ll defer to your judgement.

Duplicate usb_port_owner_info entry is really NOT necessary, and this variable is not a per port setting, but is global, This will likely be fixed in the next release

The reason for R21.1 to show it as 2.0, but 3.0 in R19.3 is because,
u-boot is the default bootloader in R21.1, and fastboot is default in R19.3,
and ODM data changes won’t affect u-boot, ODM data changes will get affected only in case of fastboot

Though changes are done to jetson-tk1.conf file for CMDLINE_ADD, it won’t affect extlinux.conf, one has to explicitly change the cmdline in respective extlinux.conf under bootloader/ardbeg/ directory

Thanks @peba and @sundeep471. It’s good to know that people are keeping an eye out for issues like this!

I changed the answer up top accordingly for the lost souls that follow.

Has anyone encountered this?
unable to initialize libusb: -99

And /dev/bus/usb doesn’t show.

This is after editing extlinux.conf to support usb 3.0, in R21.1.

Not an answer (I do not have USB3 to test), but a related observation. Switching from USB2 to USB3 means changing drivers, and drivers would be responsible for providing device special files. Sometimes user space configuration is also required (which might differ when drivers change).

Thanks for your reply, linuxdev.
It seems weird that even the root hub isn’t showing in ‘lsusb’. The switch to USB 3.0 through boot configuration seemed to work fine for everyone else, and I’m trying to understand what’s different in my system. Is there something I can do to check what’s wrong?
Thanks again.

Just for reference, I’m running USB2 on R19.3. I see root HUBs with the basic lsusb as:

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Which of the two root HUBs goes away under lsusb when set to USB3? Bus 2 or Bus 1? (the same bus should be listed for both USB2 and USB3)

Sorry, I wasn’t clear before - any operation involving usb, including ‘lsusb’ results with the error message I’ve mentioned:
unable to initialize libusb: -99
So, I’m not getting any output from ‘lsusb’ at all.

Try running “sudo strace -olog.txt lsusb”. LOTS of log will output, but see if anything interesting pops up towards the end of the log.

FYI, on my R19.3 I can use lsusb and strace of lsusb without error. Anything from “ltrace” of “lsusb” fails and causes remote terminal lockup.

Try this lsusb command…lsusb fails for me like this when no special arguments are given to ltrace:

# ltrace lsusb
__libc_start_main(0x9429, 1, 0xbe82a804, 0x13195PTRACE_SINGLESTEP: Input/output error
3037 couldn't continue when handling __libc_start_main (0x9270) at 0x9270

If I specify libusb in ltrace:

# ltrace --library='libusb*' lsusb
lsusb->libusb_init(0xbee84684, 0xb6ed1518, 0, 1PTRACE_SINGLESTEP: Input/output error
3759 couldn't continue when handling libusb_init (0x938c) at 0x938c

Is the result the same for you of ltrace with and without the “–library” option?

Hi, i have the same issue, “unable to initialize libusb: -99” and no /dev/bus/

But it only occurs if trying to boot with usb3.0. If i set usb_port_owner_info=0, usb is fully working (2.0 of course)

I’m running The Grinch with L4T21.1

# ltrace lsusb
__libc_start_main(0x9429, 1, 0xbe4d4854, 0x13195PTRACE_SINGLESTEP: Input/output error
4643 couldn't continue when handling __libc_start_main (0x9270) at 0x9270
# ltrace --library='libusb*' lsusb
lsusb->libusb_init(0xbe0d66d4, 0xb66c8518, 0, 1PTRACE_SINGLESTEP: Input/output error
3170 couldn't continue when handling libusb_init (0x938c) at 0x938c
#strace -olog.txt lsusb
...
openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fcntl64(3, F_GETFD)                     = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 200 entries */, 32768)   = 4120
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
write(2, "unable to initialize libusb: -99"..., 33) = 33
exit_group(1)                           = ?
+++ exited with 1 +++

Seems like lsusb fails, because no usb controller is found http://superuser.com/a/698010

It seems at least part of this error exists in R19.3 (just ltrace issues with USB2…USB3 does not seem to be any additional issue for ltrace on R19.3), but changes slightly in R21.1. It’s very common in strace logs to see lots of attempts to open things when the system is just looking through all search paths until it finds one which works. In the case of USB3 on R21.1 it does seem likely lsusb is confused into thinking there is no USB controller. I’m wondering if some of the issue is related to old USB2 firmware/code mixing with USB3 code…this could possibly confuse libusb.

Probably the way to check things will not be simple. At this point it would be nice to try some gdb tricks, but there are a number of difficulties there…on my R19.3 I don’t see a debug symbol package for usbutils package, plus I’m still running R19.3 and do not have USB3 hardware.

maybe you meant something different, but the error is independant from attached hardware. tried usb2, usb3 and empty port → all the same

I simply have had no reason to configure and flash for USB3 (my USB interests are currently limited mainly to HID, most of which actually run at USB1.1 speeds…on occasion USB2…USB3 would currently complicate life for me). It seems though that part of the issues may exist in an altered format under USB2.

Interesting sidenote: I inserted a MiniPCIe-Card with a USB3 Controller and this one works, even with SuperSpeed. Nothing else was changed. The port on the board however is still not functional.

Oh and lsusb shows hardware again.