From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cjGys-0004fB-8S for mharc-grub-devel@gnu.org; Wed, 01 Mar 2017 22:00:38 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjGyp-0004dp-50 for grub-devel@gnu.org; Wed, 01 Mar 2017 22:00:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjGyn-0007RH-Mg for grub-devel@gnu.org; Wed, 01 Mar 2017 22:00:35 -0500 Received: from mail-ua0-x234.google.com ([2607:f8b0:400c:c08::234]:33459) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjGyn-0007R3-GO for grub-devel@gnu.org; Wed, 01 Mar 2017 22:00:33 -0500 Received: by mail-ua0-x234.google.com with SMTP id c11so12828431uaa.0 for ; Wed, 01 Mar 2017 19:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QbZFJJAsdu6ISMTR4Z3nrZLoWeOa69A/HjeC/hRiwXk=; b=TQa+LEbPxxR+f0QeoZCrPPansaZ7bplhKBtXMm5uLtrHryod4pzAVtSQwsm5Ut0PmS QXCh2BW/JNn6kpzBNxBVgwcBC8HEyxxIEqFGYE0QPUhWsZGMNvRzd+vquRoG2pRFzmqY DYdbURfvMyzv5TH+1IWFUXFhDqh8ribgAplC3bsqRVj+5U9oJ8+R/DHqsUt/DGRrxnqE a8Pf3o8zro0A+PuRUCBIqghJug8iquPXFyMGIgm3ST9dBLoPTKp+9D5l6h1/p+quLZ5b 5Lb9NBaHgYri/A81fC4CK2+YYIh+9GTpsqy/FE1CGn2egjtRv0YJw5hIR+hkvDHlvydr tcpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QbZFJJAsdu6ISMTR4Z3nrZLoWeOa69A/HjeC/hRiwXk=; b=jzeGIHDsz59XS8rx15RlGXDTzXA/0uHLOpNMtP9gUd5nor5cv9YZa+3I6s/g+MB0Ve 3BV9+VdbHnV+ASZWhMr5cesFNW9gLHc+28ZHfiH8P7/xvw1dBlTRktPgQQEQIYfbDWUY yu+fsJWxZZec3OYk3YZNNU+MgUT6qwfWbKIMiCzh4g6MbhF7VOdrc1fCPkKtG/sufhj4 o+UF8AGFiAgQrAppsFY/lYdNsBKHqjsY+WRIHG9ckIlJo7GdujQjKEfSXplZYCo2WVag j4toynTB7+FNaSzxCqcavC0xaSUXx8wQMNJjzplB+HvlBCXBKMVHWnUolT0Vbpn2faS1 7CzQ== X-Gm-Message-State: AMke39kXd1p7Mevm7PGaKQW1UJNjXwkLnKbjlpvX/w4X3EAOsnV1L1TNGm8XLUdW6GOAZkoP6rgzknmktDB8SQ== X-Received: by 10.31.85.4 with SMTP id j4mr2056604vkb.1.1488423632644; Wed, 01 Mar 2017 19:00:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.240 with HTTP; Wed, 1 Mar 2017 19:00:32 -0800 (PST) In-Reply-To: References: From: Gailu Singh Date: Thu, 2 Mar 2017 08:30:32 +0530 Message-ID: Subject: Re: USB3.0 XHCI support on GRUB2 To: =?UTF-8?Q?Bj=C3=B8rn_Forsman?= Cc: Andrei Borzenkov , The development of GNU GRUB Content-Type: multipart/alternative; boundary=001a114e5abce631060549b6a1a1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::234 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 03:00:36 -0000 --001a114e5abce631060549b6a1a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the update. I will try your patches on Apollo lake and report back the results. Intel strategy seems to be XHCI only option on newer boards so sooner or later xhci support is required in Grub. Thanks for your effort to take initiative. On Wed, Mar 1, 2017 at 4:07 PM, Bj=C3=B8rn Forsman wrote: > On 1 March 2017 at 07:57, Andrei Borzenkov wrote: > > Yes, Bj=C3=B8rn Forsman intended to work on implementation. > > So now is apparently a good time to tell you about the status of that > implementation :-) > > > The good: > > I ported the xHCI driver from Coreboot / libpayload to GRUB. In basic > tests, it works. (I tested a Lenovo G50-80 laptop with Intel Wildcat > Point-LP USB xHCI controller [8086:9cb1].) > > > The bad: > > The code doesn't support HUBs and completely hangs on one xHCI > controller I tested (Intel NUC6i5SYH Skylake with Sunrise Point-LP > xHCI USB controller [8086:9d2f]). > > The HUB problem is due to GRUB using a different code path for HUBs > than normal devices. I implemented hooks for "control_transfer" and > "bulk_transfer" in GRUB USB stack, because that required little > changes and it made it easy to hook it up with the xHCI driver. But > when GRUB sees a HUB, it uses the "old" setup_transfer code path which > isn't implemented in the xHCI driver. > > I'm thinking the "hanging" issue (the controller never responds to a > basic "NOP" command) is a problem with the Coreboot driver itself, or > more specifically, the lack of a "quirk" handling for this controller. > But blaming that driver doesn't fix it. > > About the implementation. I tried to change as little code as > possible, both in GRUB and the Coreboot driver, thinking that it'd > make maintenance easier. My reasoning was (perhaps wrongly?) that > there is little help to get in the community, and if I reuse enough of > the Coreboot driver, I can easiliy re-import the driver if/when they > fix some bugs. This "change as little as possible" policy means that > now the xHCI driver initializes and tracks some state that also GRUB > USB stack does. It works but it's not something I think is good enough > to integrate in mainline GRUB. (That's one of the reasons why I didn't > tell you about the status earlier. I don't see how to make it "clean" > enough for mainline. Also, the above issues are sort of blockers in > themselves.) > > > The ugly :-) > > https://github.com/bjornfor/grub/tree/add-coreboot-xhci- > driver-2nd-attempt-v2 > > (I just cleaned up history and rebased on master, so it's less ugly > than it was a few hours ago.) > > Best regards, > Bj=C3=B8rn Forsman > --001a114e5abce631060549b6a1a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the update. I will try your patches on Apollo l= ake and report back the results. Intel strategy seems to be XHCI only optio= n on newer boards so sooner or later xhci support is required in Grub. Than= ks for your effort to take initiative.=C2=A0

On Wed, Mar 1, 2017 at 4:07 PM, Bj=C3=B8rn= Forsman <bjorn.forsman@gmail.com> wrote:
On 1 March 2017 at 07:57, Andrei Bor= zenkov <arvidjaar@gmail.com&g= t; wrote:
> Yes, Bj=C3=B8rn Forsman intended to work on implementation.

So now is apparently a good time to tell you about the status of tha= t
implementation :-)


The good:

I ported the xHCI driver from Coreboot / libpayload to GRUB. In basic
tests, it works. (I tested a Lenovo G50-80 laptop with Intel Wildcat
Point-LP USB xHCI controller [8086:9cb1].)


The bad:

The code doesn't support HUBs and completely hangs on one xHCI
controller I tested (Intel NUC6i5SYH Skylake with Sunrise Point-LP
xHCI USB controller [8086:9d2f]).

The HUB problem is due to GRUB using a different code path for HUBs
than normal devices. I implemented hooks for "control_transfer" a= nd
"bulk_transfer" in GRUB USB stack, because that required little changes and it made it easy to hook it up with the xHCI driver. But
when GRUB sees a HUB, it uses the "old" setup_transfer code path = which
isn't implemented in the xHCI driver.

I'm thinking the "hanging" issue (the controller never respon= ds to a
basic "NOP" command) is a problem with the Coreboot driver itself= , or
more specifically, the lack of a "quirk" handling for this contro= ller.
But blaming that driver doesn't fix it.

About the implementation. I tried to change as little code as
possible, both in GRUB and the Coreboot driver, thinking that it'd
make maintenance easier. My reasoning was (perhaps wrongly?) that
there is little help to get in the community, and if I reuse enough of
the Coreboot driver, I can easiliy re-import the driver if/when they
fix some bugs. This "change as little as possible" policy means t= hat
now the xHCI driver initializes and tracks some state that also GRUB
USB stack does. It works but it's not something I think is good enough<= br> to integrate in mainline GRUB. (That's one of the reasons why I didn= 9;t
tell you about the status earlier. I don't see how to make it "cle= an"
enough for mainline. Also, the above issues are sort of blockers in
themselves.)


The ugly :-)

https://github.com/bjor= nfor/grub/tree/add-coreboot-xhci-driver-2nd-attempt-v2

(I just cleaned up history and rebased on master, so it's less ugly
than it was a few hours ago.)

Best regards,
Bj=C3=B8rn Forsman

--001a114e5abce631060549b6a1a1--