Zoran Stojsavljevic wrote:
since BSW (including APL-I, former BXT-I), there is ONLY USB 3.0 xHCI root hub.
It's too bad that EHCI has been removed.
The xHCI register model is broken in that it requires dedicated hardware (registers) for each connected USB device, and Intel's xHCI implementation included hardware registers for only 32 connected devices, thus actually not being compliant with the basic requirement of up to 127 devices.
The (maybe) efficient method is to put on xHCI 3.0 passive Belkin USB 2.0 bridge as bypass, maybe this can make this transition smooth.
That can unfortunately not work.
The root *hub* is actually not a problem, but as Werner pointed to it's the xHCI register and operational model, which is incompatible with that of EHCI.
xHCI means (completely) different hardware than EHCI.
Only the ports on the user side of an xHCI host controller are backwards compatible, not the interface on the CPU side.
In fact that's why the name changed. The HCI part of EHCI and xHCI stands for Host Controller Interface, ie. the CPU side of the USB controller.
Gailu Singh wrote:
If I understood it correctly the usb 2.0 card I was planning to use over pcie is not going to work as we can't mix with usb3.0 root hub, so not worth even trying that option.
Not correct. An additional EHCI host controller has nothing to do with any host controller built-into CPU, chipset or SoC.
I think your additional EHCI HC will work fine, as long as the EHCI- supporting software (I suppose GRUB 2) discovers and uses that HC instead of trying to use the Intel xHCI one. I do not expect any problem here, specifically because xHCI even appears different from EHCI on the PCI bus. It should just work.
Would you mind sharing the product details of xHCI 3.0 passive Belkin USB 2.0 bridge so that I can buy and try that.
This however can not work, again because xHCI hardware is per definition not supported by EHCI-supporting software, regardless of what you connect to a USB port on the other end of the controller.
//Peter
Hello Peter,
You answered to Gailu instead of me, I do not object, just The Opposite!
I'll just add my thoughts to your reply (in *RED*).
Zoran _______
On Thu, Mar 23, 2017 at 2:46 PM, Peter Stuge peter@stuge.se wrote:
Zoran Stojsavljevic wrote:
since BSW (including APL-I, former BXT-I), there is ONLY USB 3.0 xHCI
root
hub.
It's too bad that EHCI has been removed.
*Clocking tree domains (their proper use and I/F) remain mystery for INTEL HW designers. Why? :-(*
The xHCI register model is broken in that it requires dedicated
hardware (registers) for each connected USB device, and Intel's xHCI implementation included hardware registers for only 32 connected devices, thus actually not being compliant with the basic requirement of up to 127 devices.
*Excellent. I have learned something new. Whole Coreboot community did, I hope. Thank you for that, Peter.*
The (maybe) efficient method is to put on xHCI 3.0 passive Belkin USB
2.0 bridge as bypass, maybe this can make this transition smooth.
That can unfortunately not work.
*I also think this is not appropriate way to solve the problem with APL-I Coreboot USB connectivity. Only for OS USB drivers' capabilities, as I found fixing my problem with USB printer on WIN10 64 Pro.*
The root *hub* is actually not a problem, but as Werner pointed to
it's the xHCI register and operational model, which is incompatible with that of EHCI.
xHCI means (completely) different hardware than EHCI.
*Agreed.*
Only the ports on the user side of an xHCI host controller are
backwards compatible, not the interface on the CPU side.
*Again, I have learned very new stuff. I Hope, Coreboot community learned this too! Priceless. :-)*
In fact that's why the name changed. The HCI part of EHCI and xHCI
stands for Host Controller Interface, ie. the CPU side of the USB controller.
*Well... Excellent point again! :thumb up:*
Gailu Singh wrote:
If I understood it correctly the usb 2.0 card I was planning to use over pcie is not going to work as we can't mix with usb3.0 root hub, so not worth even trying that option.
Not correct. An additional EHCI host controller has nothing to do with any host controller built-into CPU, chipset or SoC.
I think your additional EHCI HC will work fine, as long as the EHCI-
supporting software (I suppose GRUB 2) discovers and uses that HC instead of trying to use the Intel xHCI one. I do not expect any problem here, specifically because xHCI even appears different from EHCI on the PCI bus. It should just work.
*Gailu, Peter is again on the right path!*
*Gailu, as Re: to your thoughts: I did not say that. I said the following: In BYT, you have some BSP option to fix: either you'll use root hub xHCI USB 3.0, either root hub EHCI USB 2.0 . You could NOT mix these two (as per above Peter's explanation)*
*In APL-I, there is NO option to use root hub EHCI USB 2.0, since this one is scrapped from silicon. You can use ONLY root hub xHCI USB 3.0. So, maybe, after all, if there is an option in Coreboot (the appropriate driver for PCIe root EHCI USB 2.0 hub card), than your approach can very well work. :-)*
Would you mind sharing the product details of xHCI 3.0 passive Belkin USB
2.0 bridge so that I can buy and try that.
This however can not work, again because xHCI hardware is per definition not supported by EHCI-supporting software, regardless of what you connect to a USB port on the other end of the controller.
*I second this! **Kudos all to Peter Stuge! **Thank you, Peter!*
-
Peter Stuge -
Zoran Stojsavljevic