Hardware Projects » E1/T1 Hardware Interface (including icE1usb)

h1. 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":https://git.sysmocom.de/sysmocom/apu-ehci), 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)|

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)

h2. Workarounds

h3. 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":https://git.sysmocom.de/sysmocom/apu-ehci allows such re-routing and thus allow the port to be used for a icE1usb with both ports enabled.

h3. 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":https://www.systutorials.com/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux/ , but in a gist, this can be done with a register write done with @setpci@.

<pre>

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

</pre>

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

h3. 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 attachment:xhci-bw-override.c utility.

<pre>

[+] 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

</pre>

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)@