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?
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
There are two usb_port_owner_info specs in the original extlinux.conf, only one is needed.
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.
The manual from Tegra Linux Driver Package UBoot 19.3:
@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
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.
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.
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.
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.