Isochronous USB Issues » History » Version 6
tnt, 02/09/2022 03:00 PM
1 | 1 | laforge | h1. Isochronous USB Issues |
---|---|---|---|
2 | |||
3 | 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]] interfaces. |
||
4 | |||
5 | |_.System/Board|_.USB Controller|_.Runs with 2 icE1usb interfaces| |
||
6 | |Raspberry Pi 3B|built-in|YES| |
||
7 | |Raspberry Pi 4|VIA XHCI|no| |
||
8 | |Thinkpad x260|Intel Corporation Sunrise Point-LP USB 3.0 xHCI CoStroller (rev 21)|no| |
||
9 | 5 | laforge | |PC-Engines APU2/APU3/APU4|AMD GX-412TC SoC|external:"with apu-ehci tool":https://git.sysmocom.de/sysmocom/apu-ehci, internal:YES| |
10 | 2 | tnt | |AMD Ryzen|Ryzen CPU|YES| |
11 | |AMD Ryzen|X570 chipset|YES| |
||
12 | 3 | tnt | |Odroid XU4|USB 2.0 port|YES| |
13 | |Odroid XU4|USB 3.0 ports|no| |
||
14 | 4 | tnt | |Soekris net5501|AMD CS5536 OHCI/EHCI|YES| |
15 | 2 | tnt | |
16 | 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. |
||
17 | 3 | tnt | 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) |
18 | 6 | tnt | |
19 | h2. Workarounds |
||
20 | |||
21 | h3. PC-Engines APU2/APU3/APU4 |
||
22 | |||
23 | The SoC contains both xHCI controllers and EHCI controllers and it's possible to select which port is routed to which controller. |
||
24 | 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. |
||
25 | |||
26 | h3. Intel Skylake and previous generations |
||
27 | |||
28 | 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@. |
||
29 | |||
30 | <pre> |
||
31 | setpci -H1 -d 8086:8c31 d0.l=0 |
||
32 | </pre> |
||
33 | |||
34 | with @8086:8c31@ being the vendor/device ID for the particular USB controller of the system. |
||
35 | |||
36 | |||
37 | h3. Intel xHCI controllers |
||
38 | |||
39 | Newer Intel platform (Apollo Lake and forward) don't include any EHCI controller anymore and so the workaround above is no longer applicable. |
||
40 | 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. |
||
41 | |||
42 | <pre> |
||
43 | [+] Found Intel xHCI controller at '/sys/devices/pci0000:00/0000:00:14.0' |
||
44 | [.] Previous HOST_CTRL_BW_MAX_REG value: 0f42528505647f42 |
||
45 | [.] Updated HOST_CTRL_BW_MAX_REG value: 0f425285b0647f42 |
||
46 | </pre> |
||
47 | |||
48 | This has been tested on the following controllers : |
||
49 | |||
50 | * @Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 36)@ |
||
51 | * @Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI [8086:5aa8] (rev 0b)@ |
||
52 | * @Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)@ |