* USB3.0 XHCI support on GRUB2 @ 2017-03-01 5:50 Gailu Singh 2017-03-01 6:14 ` Fwd: " Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-01 5:50 UTC (permalink / raw) To: grub-devel [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Fwd: USB3.0 XHCI support on GRUB2 2017-03-01 5:50 USB3.0 XHCI support on GRUB2 Gailu Singh @ 2017-03-01 6:14 ` Gailu Singh 2017-03-01 6:57 ` Andrei Borzenkov 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-01 6:14 UTC (permalink / raw) To: grub-devel [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-01 6:14 ` Fwd: " Gailu Singh @ 2017-03-01 6:57 ` Andrei Borzenkov 2017-03-01 10:37 ` Bjørn Forsman 0 siblings, 1 reply; 13+ messages in thread From: Andrei Borzenkov @ 2017-03-01 6:57 UTC (permalink / raw) To: The development of GNU GRUB, bjorn.forsman, gailu96 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-01 6:57 ` Andrei Borzenkov @ 2017-03-01 10:37 ` Bjørn Forsman 2017-03-02 3:00 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Bjørn Forsman @ 2017-03-01 10:37 UTC (permalink / raw) To: Andrei Borzenkov; +Cc: The development of GNU GRUB, gailu96 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-01 10:37 ` Bjørn Forsman @ 2017-03-02 3:00 ` Gailu Singh 2017-03-02 3:59 ` Andrei Borzenkov 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-02 3:00 UTC (permalink / raw) To: Bjørn Forsman; +Cc: Andrei Borzenkov, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-02 3:00 ` Gailu Singh @ 2017-03-02 3:59 ` Andrei Borzenkov 2017-03-02 4:12 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Andrei Borzenkov @ 2017-03-02 3:59 UTC (permalink / raw) To: Gailu Singh, Bjørn Forsman; +Cc: The development of GNU GRUB 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 >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-02 3:59 ` Andrei Borzenkov @ 2017-03-02 4:12 ` Gailu Singh 2017-03-05 15:11 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-02 4:12 UTC (permalink / raw) To: Andrei Borzenkov; +Cc: Bjørn Forsman, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-02 4:12 ` Gailu Singh @ 2017-03-05 15:11 ` Gailu Singh 2017-03-05 15:25 ` Bjørn Forsman 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-05 15:11 UTC (permalink / raw) To: Andrei Borzenkov; +Cc: Bjørn Forsman, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-05 15:11 ` Gailu Singh @ 2017-03-05 15:25 ` Bjørn Forsman 2017-03-05 17:22 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Bjørn Forsman @ 2017-03-05 15:25 UTC (permalink / raw) To: Gailu Singh; +Cc: Andrei Borzenkov, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-05 15:25 ` Bjørn Forsman @ 2017-03-05 17:22 ` Gailu Singh 2017-03-06 9:43 ` Bjørn Forsman 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-05 17:22 UTC (permalink / raw) To: Bjørn Forsman; +Cc: Andrei Borzenkov, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-05 17:22 ` Gailu Singh @ 2017-03-06 9:43 ` Bjørn Forsman 2017-03-06 9:58 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Bjørn Forsman @ 2017-03-06 9:43 UTC (permalink / raw) To: Gailu Singh; +Cc: Andrei Borzenkov, The development of GNU GRUB 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-06 9:43 ` Bjørn Forsman @ 2017-03-06 9:58 ` Gailu Singh 2017-04-02 18:05 ` Gailu Singh 0 siblings, 1 reply; 13+ messages in thread From: Gailu Singh @ 2017-03-06 9:58 UTC (permalink / raw) To: Bjørn Forsman; +Cc: Andrei Borzenkov, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: USB3.0 XHCI support on GRUB2 2017-03-06 9:58 ` Gailu Singh @ 2017-04-02 18:05 ` Gailu Singh 0 siblings, 0 replies; 13+ messages in thread From: Gailu Singh @ 2017-04-02 18:05 UTC (permalink / raw) To: Bjørn Forsman; +Cc: Andrei Borzenkov, The development of GNU GRUB [-- 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 --] ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-04-02 18:05 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-01 5:50 USB3.0 XHCI support on GRUB2 Gailu Singh 2017-03-01 6:14 ` Fwd: " Gailu Singh 2017-03-01 6:57 ` Andrei Borzenkov 2017-03-01 10:37 ` Bjørn Forsman 2017-03-02 3:00 ` Gailu Singh 2017-03-02 3:59 ` Andrei Borzenkov 2017-03-02 4:12 ` Gailu Singh 2017-03-05 15:11 ` Gailu Singh 2017-03-05 15:25 ` Bjørn Forsman 2017-03-05 17:22 ` Gailu Singh 2017-03-06 9:43 ` Bjørn Forsman 2017-03-06 9:58 ` Gailu Singh 2017-04-02 18:05 ` Gailu Singh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.