[coreboot] USB Support on Apollo Lake

[Zoran Stojsavljevic]

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 at 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!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170323/ebf00a28/attachment.html>