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