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)
|AMD Ryzen||X570 chipset
||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
|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)|
|PCI card||NEC Corporation uPD720200 USB 3.0 Host Controller
|StarFive VisionFive V2||VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller
|Fujitsu Futro S920||AMD GX-222GC SoC - AMD FCH USB XHCI Controller
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)
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 -H1 -d 8086:8c31 d0.l=0
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)