-
Notifications
You must be signed in to change notification settings - Fork 5.2k
How can I force raspberry4 to use EHCI instead of XHCI? #3309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What does that mean? XHCI defines a standard register interface to a USB3 controller, but as Wikipedia say, "The xHCI architecture was designed to support all USB speeds, including SuperSpeed (5 Gbit/s) and future speeds, under a single driver stack." Your device on the USB bus shouldn't care how the USB host controller is programmed, only which versions of USB it supports (and whether it is compliant to those standards). |
Thank you @pelwell , I have some problems on connect lots of USB device to raspberry4 (on raspberry 3b+ is OK), based on this article WHY CAN'T I CONNECT MORE USB 3.0 DEVICES TO MY SYSTEM? seems I have to disable "USB 3.0" mode, so I want to change my question to "can I use USB2.0 mode on Raspberry 4?" |
How many is "lots of USB devices"? Please post the output of What are "some problems"? Please post the output of The article you linked conflates hub tree depth with number of xHCI slots. Both are independent limitations of the hardware - hub tree depth is constrained by the USB specification, the number of simultaneously connected devices is constrained by the xHCI hardware implementation. The hardware used on Pi 4 has a maximum of 32 slots. |
I plugged 1 device(contains 16 endpoints) on each USB port, so totally I should get 4x16=64 endpoints, but now only 36 or 37 endpoints can be found.
|
Interesting. The xhci controller is rejecting an ADDRESS_DEVICE command that assigns an Enabled device slot to a particular Device. The controller is erroring out with "device slot not enabled". This is weird because the xhci specification requires the host software to retrieve a slot ID from the controller and enable it prior to assigning a device address to it. Linux does this, and we can infer that the first command succeeded (no error message for "enable context command"). So why is the second command failing? |
What CDC devices are you using? |
Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant. |
Please. I am having about the same issue. Getting the following error with ‘dmesg’:
And just like the original poster said, 36 are loaded fine but the other 28 are not working. Seems like the same issue. |
Facing the same issue. Any update? |
I would also like to request re-opening this issue. XHCI-only controllersa are a nightmare for any but the most trivial USB use cases. They hide a lot of the important bits in proprietary firmware, and that firmware tends to be more buggy than the corresponding Linux kernel code for EHCI/OHCI/UICH (e.g. in terms of isochronous bandwidth allocation). So any way how we can disable XHCI (and loose superspeed) while maintaining the much more flexible and interoperable EHCI linux kernel driver feature set would be a big improvement. |
Your question doesn't make any sense. There are no EHCI interfaces on a Pi 4. |
Ok, then the logical choice is to buy devices with actual EHCI controllers in them. At least there one is not subject to arbitrary bugs (which one cannot fix) like broken isochronous bandwidth computation, arbitrary limits on number of endpoints, devices, ... |
I am willing to entertain arguments as to why EHCI (a hardware specification mandating a particular software interface) is better than XHCI (a hardware specification mandating another particular software interface) for the same underlying hardware implementation. |
Since you're asking: The problem is the level of interface combined with non-open-source bits: OHCI/UHCI/EHCI are closer to the hardware, while XHCI is at a higher level of abstraction, delegating more parts to the controller hard-wired logic or firmware. There are bugs in XHCI controllers that we cannot fix due to those parts being in hardware/firmware (for example, miscalculating the available isochronous bandwidth). In OHCI/UHCI/EHCI those bugs don't exist, as those parts are done inside the kernel. And even if such bugs existed, they could be fixed by anyone by altering the Linux kernel source code. |
I have similar problems and will change my PI4 for PI3 :) |
A hardware we used is incompatible with XHCI, I'm wondering how can I disable that since raspberry does not have BIOS.
The text was updated successfully, but these errors were encountered: