Project

General

Profile

Actions

Isochronous USB Issues

It seems there are many XHCI implementations out there that have problems properly computing the isochronous bandwidth limits and hence refuse to activate both icE1usb USB interfaces (One USB interface corresponds to one E1 line).

System/Board USB Controller Runs with 2 icE1usb interfaces
Raspberry Pi 3B built-in no
Raspberry Pi 4 VIA XHCI no
Thinkpad x260 Intel Corporation Sunrise Point-LP USB 3.0 xHCI CoStroller (rev 21) no
PC-Engines APU2/APU3/APU4 AMD GX-412TC SoC external XHCI: no (not even with apu-ehci tool), internal EHCI:no
AMD Ryzen Ryzen CPU (3700X) [1022:149c] YES
AMD Ryzen X570 chipset [1022:149c] YES but only in USB port/bus attached to cpu lanes, not chipset lanes
Odroid XU4 USB 2.0 port YES
Odroid XU4 USB 3.0 ports no
Soekris net5501 AMD CS5536 OHCI/EHCI YES
NVidia USB-C port on RTX2070S [10de:1ad8] no
AR9331 (carambola2) chipidea-usb2/EHCI no (not even with 1 icE1usb interface, different errors whether using a USB2 hub or not)
Beaglebone green built-in musb YES (more testing needed)
--- NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] no

Note that in all cases, the device needs to be the sole full speed device on the bus since it uses all the full speed bandwidth and AFAICT all root-hubs are single-TT.
It seems that a hub connected to a EHCI/OHCI port works too, but a hub connected to a XHCI port, even one working without hub, doesn't work. (Currently tested only on Ryzen since it's the only working XHCI controller)

Workarounds

PC-Engines APU2/APU3/APU4

The SoC contains both xHCI controllers and EHCI controllers and it's possible to select which port is routed to which controller.
The apu-ehci tool allows such re-routing and thus allow the port to be used for a icE1usb with both ports enabled.

Intel Skylake and previous generations

Similarly to the APU above, older Intel platform also included both EHCI and xHCI controllers in the hardware and it's possible to re-route ports to the EHCI controller instead. This is explained in this blog post , but in a gist, this can be done with a register write done with setpci.

setpci -H1 -d 8086:8c31 d0.l=0

with 8086:8c31 being the vendor/device ID for the particular USB controller of the system.

Intel xHCI controllers

Newer Intel platform (Apollo Lake and forward) don't include any EHCI controller anymore and so the workaround above is no longer applicable.
Instead it is possible to tweak a debug register to override the bandwidth computation. This can be done with the attached xhci-bw-override.c utility.

[+] Found Intel xHCI controller at '/sys/devices/pci0000:00/0000:00:14.0'
[.] Previous HOST_CTRL_BW_MAX_REG value: 0f42528505647f42
[.] Updated  HOST_CTRL_BW_MAX_REG value: 0f425285b0647f42

This has been tested on the following controllers :

  • Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 36)
  • Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI [8086:5aa8] (rev 0b)
  • Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)

Updated by roox 7 days ago · 17 revisions

Add picture from clipboard (Maximum size: 48.8 MB)