USB3.0 XHCI support on GRUB2

USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Hi Experts,

Is there any development on XHCI support on GRUB2? New Intel boards (e.g.
Apollo Lake) has only XHCI controller so none my USB device (keyboarrd,
mass storage) works on GRUB2 on this board.

If there is any work going on, I can help with testing/development but
don't know where to start from scratch.

Looking forward to your help.

[-- Attachment #2: Type: text/html, Size: 446 bytes --]

Fwd: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Hi Experts,

Is there any development on XHCI support on GRUB2? New Intel boards (e.g.
Apollo Lake) has only XHCI controller so none my USB device (keyboarrd,
mass storage) works on GRUB2 on this board.

If there is any work going on, I can help with testing/development but
don't know where to start from scratch.

Looking forward to your help.

[-- Attachment #2: Type: text/html, Size: 504 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Andrei Borzenkov]

Yes, Bjørn Forsman intended to work on implementation.

On Wed, Mar 1, 2017 at 9:14 AM, Gailu Singh <gailu96@gmail.com> wrote:
> Hi Experts,
>
> Is there any development on XHCI support on GRUB2? New Intel boards (e.g.
> Apollo Lake) has only XHCI controller so none my USB device (keyboarrd, mass
> storage) works on GRUB2 on this board.
>
> If there is any work going on, I can help with testing/development but don't
> know where to start from scratch.
>
> Looking forward to your help.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: USB3.0 XHCI support on GRUB2

[Bjørn Forsman]

On 1 March 2017 at 07:57, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> Yes, Bjørn 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ørn Forsman

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

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ørn Forsman <bjorn.forsman@gmail.com>
wrote:

> On 1 March 2017 at 07:57, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> > Yes, Bjørn 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ørn Forsman
>

[-- Attachment #2: Type: text/html, Size: 3441 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Andrei Borzenkov]

02.03.2017 06:00, Gailu Singh пишет:
> 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 physical platforms grub normally relies on firmware to access
devices. What exact problem do you solve? Why do you need direct xHCI
access? What firmware this board has (I presume, EFI)?

> On Wed, Mar 1, 2017 at 4:07 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
> wrote:
> 
>> On 1 March 2017 at 07:57, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>>> Yes, Bjørn 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ørn Forsman
>>
> 

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]

I am not using EFI. I am using coreboot with Intel FSP. Intel confirmed
that XHCI controller is initialized by FSP and any standard XHCI driver
should work on top of that.

Problem Details:

Requirement:
My requirement is to load GRUB2 as payload from coreboot and Load Linux
using GRUB2 (from USB pen drive and Hard Disk) based on grub menu selection

Problem I am facing:
1. GRUB2 does not recognize USB pen drive, so can not boot linux from USB
pen drive
2. GRUB2 does not recognize USB keyboard so not able to select menu entry

Board: Intel Oxbohill CRB (Apollo lake)



On Thu, Mar 2, 2017 at 9:29 AM, Andrei Borzenkov <arvidjaar@gmail.com>
wrote:

> 02.03.2017 06:00, Gailu Singh пишет:
> > 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 physical platforms grub normally relies on firmware to access
> devices. What exact problem do you solve? Why do you need direct xHCI
> access? What firmware this board has (I presume, EFI)?
>
> > On Wed, Mar 1, 2017 at 4:07 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
> > wrote:
> >
> >> On 1 March 2017 at 07:57, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >>> Yes, Bjørn 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ørn Forsman
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5183 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]

Getting Build error related to include path. Looks like some Makefile
problem

bus/usb/xhci/usb/xhci.c:36:26: fatal error: arch/virtual.h: No such file or
directory
 #include <arch/virtual.h>

On Thu, Mar 2, 2017 at 9:42 AM, Gailu Singh <gailu96@gmail.com> wrote:

> I am not using EFI. I am using coreboot with Intel FSP. Intel confirmed
> that XHCI controller is initialized by FSP and any standard XHCI driver
> should work on top of that.
>
> Problem Details:
>
> Requirement:
> My requirement is to load GRUB2 as payload from coreboot and Load Linux
> using GRUB2 (from USB pen drive and Hard Disk) based on grub menu selection
>
> Problem I am facing:
> 1. GRUB2 does not recognize USB pen drive, so can not boot linux from USB
> pen drive
> 2. GRUB2 does not recognize USB keyboard so not able to select menu entry
>
> Board: Intel Oxbohill CRB (Apollo lake)
>
>
>
> On Thu, Mar 2, 2017 at 9:29 AM, Andrei Borzenkov <arvidjaar@gmail.com>
> wrote:
>
>> 02.03.2017 06:00, Gailu Singh пишет:
>> > 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 physical platforms grub normally relies on firmware to access
>> devices. What exact problem do you solve? Why do you need direct xHCI
>> access? What firmware this board has (I presume, EFI)?
>>
>> > On Wed, Mar 1, 2017 at 4:07 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
>> > wrote:
>> >
>> >> On 1 March 2017 at 07:57, Andrei Borzenkov <arvidjaar@gmail.com>
>> wrote:
>> >>> Yes, Bjørn 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ørn Forsman
>> >>
>> >
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5907 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Bjørn Forsman]

On 5 March 2017 at 16:11, Gailu Singh <gailu96@gmail.com> wrote:
> Getting Build error related to include path. Looks like some Makefile
> problem
>
> bus/usb/xhci/usb/xhci.c:36:26: fatal error: arch/virtual.h: No such file or
> directory
>  #include <arch/virtual.h>

What are your build commands?

This worked for me in a Ubuntu 16.04 machine (64-bit):

git clone https://github.com/bjornfor/grub/
git checkout add-coreboot-xhci-driver-2nd-attempt-v2
./autogen.sh
./configure --prefix=$PWD/_install
make
make install

Best regards,
Bjørn Forsman

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

git clone https://github.com/bjornfor/grub/
git checkout add-coreboot-xhci-driver-2nd-attempt-v2
./autogen.sh
./configure --with-platform=coreboot
make
------------------

BTW I changed the include directive in C files just to compile it and would
like to update that I included xhci module in grub.elf but there is no sign
of life on USB keyboard that is connected to USB3.0 on Intel Oxbohill CRB
(Apollolake SOC).

Thanks.

On Sun, Mar 5, 2017 at 8:55 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
wrote:

> On 5 March 2017 at 16:11, Gailu Singh <gailu96@gmail.com> wrote:
> > Getting Build error related to include path. Looks like some Makefile
> > problem
> >
> > bus/usb/xhci/usb/xhci.c:36:26: fatal error: arch/virtual.h: No such file
> or
> > directory
> >  #include <arch/virtual.h>
>
> What are your build commands?
>
> This worked for me in a Ubuntu 16.04 machine (64-bit):
>
> git clone https://github.com/bjornfor/grub/
> git checkout add-coreboot-xhci-driver-2nd-attempt-v2
> ./autogen.sh
> ./configure --prefix=$PWD/_install
> make
> make install
>
> Best regards,
> Bjørn Forsman
>

[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Bjørn Forsman]

On 5 March 2017 at 18:22, Gailu Singh <gailu96@gmail.com> wrote:
> git clone https://github.com/bjornfor/grub/
> git checkout add-coreboot-xhci-driver-2nd-attempt-v2
> ./autogen.sh
> ./configure --with-platform=coreboot
> make
> ------------------
>
> BTW I changed the include directive in C files just to compile it and would
> like to update that I included xhci module in grub.elf but there is no sign
> of life on USB keyboard that is connected to USB3.0 on Intel Oxbohill CRB
> (Apollolake SOC).

Just for reference, what is the PCI product and device ID of that
controller? If you get to the grub shell, type "xhci" to view it.

Best regards,
Bjørn Forsman

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 4185 bytes --]

Though I get shell but I am unable to use it as keyboard is not working and
serial console also does not work because board has only memory mapped UART
not supported in grub

There seems to be two controller with vendor and device id as follows
8086:5aa8
8086:5aaa

This is based on lspci output on Linux

root@localhost:~# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5af0] (rev 0b)
00:00.1 Signal processing controller [1180]: Intel Corporation Device
[8086:5a8c] (rev 0b)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device
[8086:5a84] (rev 0b)
00:0e.0 Audio device [0403]: Intel Corporation Device [8086:5a98] (rev 0b)
00:0f.0 Communication controller [0780]: Intel Corporation Device
[8086:5a9a] (rev 0b)
00:11.0 Unclassified device [0050]: Intel Corporation Device [8086:5aa2]
(rev 0b)
00:12.0 SATA controller [0106]: Intel Corporation Device [8086:5ae3] (rev
0b)
00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad8] (rev fb)
00:13.2 PCI bridge [0604]: Intel Corporation Device [8086:5ada] (rev fb)
00:13.3 PCI bridge [0604]: Intel Corporation Device [8086:5adb] (rev fb)
00:14.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad6] (rev fb)
00:14.1 PCI bridge [0604]: Intel Corporation Device [8086:5ad7] (rev fb)
00:15.0 USB controller [0c03]: Intel Corporation Device [8086:5aa8] (rev 0b)
00:15.1 USB controller [0c03]: Intel Corporation Device [8086:5aaa] (rev 0b)
00:16.0 Signal processing controller [1180]: Intel Corporation Device
[8086:5aac] (rev 0b)
00:16.1 Signal processing controller [1180]: Intel Corporation Device
[8086:5aae] (rev 0b)
00:16.2 Signal processing controller [1180]: Intel Corporation Device
[8086:5ab0] (rev 0b)
00:16.3 Signal processing controller [1180]: Intel Corporation Device
[8086:5ab2] (rev 0b)
00:17.0 Signal processing controller [1180]: Intel Corporation Device
[8086:5ab4] (rev 0b)
00:17.1 Signal processing controller [1180]: Intel Corporation Device
[8086:5ab6] (rev 0b)
00:17.2 Signal processing controller [1180]: Intel Corporation Device
[8086:5ab8] (rev 0b)
00:17.3 Signal processing controller [1180]: Intel Corporation Device
[8086:5aba] (rev 0b)
00:18.0 Signal processing controller [1180]: Intel Corporation Device
[8086:5abc] (rev 0b)
00:18.1 Signal processing controller [1180]: Intel Corporation Device
[8086:5abe] (rev 0b)
00:18.2 Signal processing controller [1180]: Intel Corporation Device
[8086:5ac0] (rev 0b)
00:18.3 Signal processing controller [1180]: Intel Corporation Device
[8086:5aee] (rev 0b)
00:19.0 Signal processing controller [1180]: Intel Corporation Device
[8086:5ac2] (rev 0b)
00:19.1 Signal processing controller [1180]: Intel Corporation Device
[8086:5ac4] (rev 0b)
00:19.2 Signal processing controller [1180]: Intel Corporation Device
[8086:5ac6] (rev 0b)
00:1b.0 SD Host controller [0805]: Intel Corporation Device [8086:5aca]
(rev 0b)
00:1c.0 SD Host controller [0805]: Intel Corporation Device [8086:5acc]
(rev 0b)
00:1e.0 SD Host controller [0805]: Intel Corporation Device [8086:5ad0]
(rev 0b)
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:5ae8] (rev 0b)
00:1f.1 SMBus [0c05]: Intel Corporation Device [8086:5ad4] (rev 0b)
02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network
Connection [8086:157b] (rev 03)
root@localhost:~#

On Mon, Mar 6, 2017 at 3:13 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
wrote:

> On 5 March 2017 at 18:22, Gailu Singh <gailu96@gmail.com> wrote:
> > git clone https://github.com/bjornfor/grub/
> > git checkout add-coreboot-xhci-driver-2nd-attempt-v2
> > ./autogen.sh
> > ./configure --with-platform=coreboot
> > make
> > ------------------
> >
> > BTW I changed the include directive in C files just to compile it and
> would
> > like to update that I included xhci module in grub.elf but there is no
> sign
> > of life on USB keyboard that is connected to USB3.0 on Intel Oxbohill CRB
> > (Apollolake SOC).
>
> Just for reference, what is the PCI product and device ID of that
> controller? If you get to the grub shell, type "xhci" to view it.
>
> Best regards,
> Bjørn Forsman
>

[-- Attachment #2: Type: text/html, Size: 6235 bytes --]

Re: USB3.0 XHCI support on GRUB2

[Gailu Singh]

[-- Attachment #1: Type: text/plain, Size: 5311 bytes --]

Hi Bjørn,

This is to confirm you that xhci worked fine on my board with pen drive
though still my usb keyboard is not working but that is not so critical and
will look in to that later. It was the problem at my end while including
the module in my elf image.

Thanks for your great effort on this.

Need some input on naming convention though. when I run ls command I find
that usb pen drive pluged in to same port is sometime listed as usb1, on
next reboot usb7, sometime usb5 and so on. Is there a way to fix that usb
plugged in to same port is always listed as same on every power recycle.

in grub menu if I specify (usb1) next time menu does not work automatically
and I need to edit it on nearly every power cycle, occasionally it is
listed with same name as in last power cycle.

Thank you once again for taking initiative on this feature.

On Mon, Mar 6, 2017 at 3:28 PM, Gailu Singh <gailu96@gmail.com> wrote:

> Though I get shell but I am unable to use it as keyboard is not working
> and serial console also does not work because board has only memory mapped
> UART not supported in grub
>
> There seems to be two controller with vendor and device id as follows
> 8086:5aa8
> 8086:5aaa
>
> This is based on lspci output on Linux
>
> root@localhost:~# lspci -nn
> 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5af0] (rev 0b)
> 00:00.1 Signal processing controller [1180]: Intel Corporation Device
> [8086:5a8c] (rev 0b)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Device
> [8086:5a84] (rev 0b)
> 00:0e.0 Audio device [0403]: Intel Corporation Device [8086:5a98] (rev 0b)
> 00:0f.0 Communication controller [0780]: Intel Corporation Device
> [8086:5a9a] (rev 0b)
> 00:11.0 Unclassified device [0050]: Intel Corporation Device [8086:5aa2]
> (rev 0b)
> 00:12.0 SATA controller [0106]: Intel Corporation Device [8086:5ae3] (rev
> 0b)
> 00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad8] (rev fb)
> 00:13.2 PCI bridge [0604]: Intel Corporation Device [8086:5ada] (rev fb)
> 00:13.3 PCI bridge [0604]: Intel Corporation Device [8086:5adb] (rev fb)
> 00:14.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad6] (rev fb)
> 00:14.1 PCI bridge [0604]: Intel Corporation Device [8086:5ad7] (rev fb)
> 00:15.0 USB controller [0c03]: Intel Corporation Device [8086:5aa8] (rev
> 0b)
> 00:15.1 USB controller [0c03]: Intel Corporation Device [8086:5aaa] (rev
> 0b)
> 00:16.0 Signal processing controller [1180]: Intel Corporation Device
> [8086:5aac] (rev 0b)
> 00:16.1 Signal processing controller [1180]: Intel Corporation Device
> [8086:5aae] (rev 0b)
> 00:16.2 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ab0] (rev 0b)
> 00:16.3 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ab2] (rev 0b)
> 00:17.0 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ab4] (rev 0b)
> 00:17.1 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ab6] (rev 0b)
> 00:17.2 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ab8] (rev 0b)
> 00:17.3 Signal processing controller [1180]: Intel Corporation Device
> [8086:5aba] (rev 0b)
> 00:18.0 Signal processing controller [1180]: Intel Corporation Device
> [8086:5abc] (rev 0b)
> 00:18.1 Signal processing controller [1180]: Intel Corporation Device
> [8086:5abe] (rev 0b)
> 00:18.2 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ac0] (rev 0b)
> 00:18.3 Signal processing controller [1180]: Intel Corporation Device
> [8086:5aee] (rev 0b)
> 00:19.0 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ac2] (rev 0b)
> 00:19.1 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ac4] (rev 0b)
> 00:19.2 Signal processing controller [1180]: Intel Corporation Device
> [8086:5ac6] (rev 0b)
> 00:1b.0 SD Host controller [0805]: Intel Corporation Device [8086:5aca]
> (rev 0b)
> 00:1c.0 SD Host controller [0805]: Intel Corporation Device [8086:5acc]
> (rev 0b)
> 00:1e.0 SD Host controller [0805]: Intel Corporation Device [8086:5ad0]
> (rev 0b)
> 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:5ae8] (rev 0b)
> 00:1f.1 SMBus [0c05]: Intel Corporation Device [8086:5ad4] (rev 0b)
> 02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network
> Connection [8086:157b] (rev 03)
> root@localhost:~#
>
> On Mon, Mar 6, 2017 at 3:13 PM, Bjørn Forsman <bjorn.forsman@gmail.com>
> wrote:
>
>> On 5 March 2017 at 18:22, Gailu Singh <gailu96@gmail.com> wrote:
>> > git clone https://github.com/bjornfor/grub/
>> > git checkout add-coreboot-xhci-driver-2nd-attempt-v2
>> > ./autogen.sh
>> > ./configure --with-platform=coreboot
>> > make
>> > ------------------
>> >
>> > BTW I changed the include directive in C files just to compile it and
>> would
>> > like to update that I included xhci module in grub.elf but there is no
>> sign
>> > of life on USB keyboard that is connected to USB3.0 on Intel Oxbohill
>> CRB
>> > (Apollolake SOC).
>>
>> Just for reference, what is the PCI product and device ID of that
>> controller? If you get to the grub shell, type "xhci" to view it.
>>
>> Best regards,
>> Bjørn Forsman
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7861 bytes --]