xHCI driver

xHCI driver

[Bjørn Forsman]

Hi GRUB developers,

My name is Bjørn Forsman, first time poster. I've been tasked to make
an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
card (CCID) reader functionality. We already have a working CCID
driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
for that matter), so this is quite the learning experience :-)

I looked in the GRUB mailing list archive and found a couple of old
threads about xHCI[1], but it looks like there has never been an
attempt at writing that driver.

Some questions:

* Is there interest in xHCI driver for GRUB? If so I can post patches
when there is something that works (more or less).

* I see the iPXE project has an xHCI driver. Any thoughts on using
that as a basis? I'm a bit unsure about the licensing, whether iPXE is
GPLv2 *only* or "at your option, any later version". I guess if it's
GPLv2+ it is compatible with GRUB's GPLv3+, or else not. Correct?

Best regards,
Bjørn Forsman

[1]: The "xhci support?" thread from 2012 and "[PATCH]: xHCI/EHCI -
Windows - BIOS bug interaction." from late 2013 which added a quirk
for an Intel controller.

Re: xHCI driver

[Daniel Kiper]

Hi Bjorn,

On Fri, Nov 25, 2016 at 01:43:21PM +0100, Bjorn Forsman wrote:
> Hi GRUB developers,
>
> My name is Bjorn Forsman, first time poster. I've been tasked to make
> an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
> card (CCID) reader functionality. We already have a working CCID
> driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
> for that matter), so this is quite the learning experience :-)
>
> I looked in the GRUB mailing list archive and found a couple of old
> threads about xHCI[1], but it looks like there has never been an
> attempt at writing that driver.
>
> Some questions:
>
> * Is there interest in xHCI driver for GRUB? If so I can post patches
> when there is something that works (more or less).

Why not, go ahead. However, this will not be considered as 2.02 release material.

> * I see the iPXE project has an xHCI driver. Any thoughts on using
> that as a basis? I'm a bit unsure about the licensing, whether iPXE is

I have not checked GRUB and iPXE USB code but I have a feeling that
simple copy paste will not work. Though I think that we can use some
ideas or even some code chunks. At first I would check currently
existing GRUB EHCI and OHCI code. There is a chance that a lot of
stuff can be reused in new xHCI driver. If it is true then I would
check details in iPXE USB code.

> GPLv2 *only* or "at your option, any later version". I guess if it's
> GPLv2+ it is compatible with GRUB's GPLv3+, or else not. Correct?

Ohhh... This is difficult. At first please check licenses for source code
which you are going to use as a base/(source of knowledge) for GRUB xHCI
driver development and drop me a line. Then I will ask legal guys what
we should do.

Have a nice weekend,

Daniel

Re: xHCI driver

[Andrei Borzenkov]

25.11.2016 15:43, Bjørn Forsman пишет:
> Hi GRUB developers,
> 
> My name is Bjørn Forsman, first time poster. I've been tasked to make
> an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
> card (CCID) reader functionality. We already have a working CCID
> driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
> for that matter), so this is quite the learning experience :-)
> 

What platforms do you target? Note that on most platforms grub relies on
firmware services to access devices, so those direct hardware access
drivers simply are not used.

> I looked in the GRUB mailing list archive and found a couple of old
> threads about xHCI[1], but it looks like there has never been an
> attempt at writing that driver.
> 
> Some questions:
> 
> * Is there interest in xHCI driver for GRUB? If so I can post patches
> when there is something that works (more or less).
> 
> * I see the iPXE project has an xHCI driver. Any thoughts on using
> that as a basis? I'm a bit unsure about the licensing, whether iPXE is
> GPLv2 *only* or "at your option, any later version". I guess if it's
> GPLv2+ it is compatible with GRUB's GPLv3+, or else not. Correct?
> 
> Best regards,
> Bjørn Forsman
> 
> [1]: The "xhci support?" thread from 2012 and "[PATCH]: xHCI/EHCI -
> Windows - BIOS bug interaction." from late 2013 which added a quirk
> for an Intel controller.
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: xHCI driver

[Paul Menzel]

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

Dear Bjørn,


Am Freitag, den 25.11.2016, 13:43 +0100 schrieb Bjørn Forsman:

> My name is Bjørn Forsman, first time poster. I've been tasked to make
> an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
> card (CCID) reader functionality. We already have a working CCID
> driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
> for that matter), so this is quite the learning experience :-)
> 
> I looked in the GRUB mailing list archive and found a couple of old
> threads about xHCI[1], but it looks like there has never been an
> attempt at writing that driver.
> 
> Some questions:
> 
> * Is there interest in xHCI driver for GRUB? If so I can post patches
> when there is something that works (more or less).
> 
> * I see the iPXE project has an xHCI driver. Any thoughts on using
> that as a basis? I'm a bit unsure about the licensing, whether iPXE is
> GPLv2 *only* or "at your option, any later version". I guess if it's
> GPLv2+ it is compatible with GRUB's GPLv3+, or else not. Correct?

The project libpayload, which is used quite a lot in the coreboot
community, also provides a well tested xHCI driver [2], which you could
use, as it’s BSD licensed.


Thanks,

Paul


> [1]: The "xhci support?" thread from 2012 and "[PATCH]: xHCI/EHCI -
> Windows - BIOS bug interaction." from late 2013 which added a quirk
> for an Intel controller.

[2]: https://review.coreboot.org/cgit/coreboot.git/tree/payloads/libpay
load/drivers/usb

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: xHCI driver

[Bjørn Forsman]

On 25 November 2016 at 22:39, Daniel Kiper <dkiper@net-space.pl> wrote:
> Hi Bjorn,
>
> On Fri, Nov 25, 2016 at 01:43:21PM +0100, Bjorn Forsman wrote:
>> GPLv2 *only* or "at your option, any later version". I guess if it's
>> GPLv2+ it is compatible with GRUB's GPLv3+, or else not. Correct?
>
> Ohhh... This is difficult. At first please check licenses for source code
> which you are going to use as a base/(source of knowledge) for GRUB xHCI
> driver development and drop me a line. Then I will ask legal guys what
> we should do.

${ipxe_src}/src/drivers/usb/xhci.c indicates GPLv2+ in its file header comment.
But there is this page, http://ipxe.org/licensing, indicating that to
be absolutely sure of the license, I have to run something like "make
bin/808610de.rom.licence". And I don't know which target to build yet,
hence my uncertainty about the license :-)

Best regards,
Bjørn Forsman

Re: xHCI driver

[Bjørn Forsman]

On 26 November 2016 at 10:29, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 25.11.2016 15:43, Bjørn Forsman пишет:
>> Hi GRUB developers,
>>
>> My name is Bjørn Forsman, first time poster. I've been tasked to make
>> an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
>> card (CCID) reader functionality. We already have a working CCID
>> driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
>> for that matter), so this is quite the learning experience :-)
>
> What platforms do you target?

i386 PC platform.

> Note that on most platforms grub relies on
> firmware services to access devices, so those direct hardware access
> drivers simply are not used.

You mean like (USB) disk access? Yes, I recently found out about that.
I wondered how GRUB was able to boot a Linux system on my USB 3.0
ports without xhci drivers, but then I learned about 1) all the stuff
that BIOS does and 2) how GRUB uses the BIOS to access disks
(${grub_src}/grub-core/disk/i386/pc/biosdisk.c).

For our project, smartcard reader over USB 3.0, we have to implement
that ourself. BIOS has support for that (AFAICT). (On the other hand,
looks like UEFI might have something.)

Best regards,
Bjørn Forsman

Re: xHCI driver

[Andrei Borzenkov]

On Mon, Nov 28, 2016 at 11:48 AM, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:
> On 26 November 2016 at 10:29, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
>> 25.11.2016 15:43, Bjørn Forsman пишет:
>>> Hi GRUB developers,
>>>
>>> My name is Bjørn Forsman, first time poster. I've been tasked to make
>>> an xHCI driver for GRUB at my $dayjob. The end goal is to have smart
>>> card (CCID) reader functionality. We already have a working CCID
>>> driver on top of EHCI. I have no prior experience with xHCI (nor EHCI
>>> for that matter), so this is quite the learning experience :-)
>>
>> What platforms do you target?
>
> i386 PC platform.
>

Yes, that is good example of what I mean.

>> Note that on most platforms grub relies on
>> firmware services to access devices, so those direct hardware access
>> drivers simply are not used.
>
> You mean like (USB) disk access? Yes, I recently found out about that.
> I wondered how GRUB was able to boot a Linux system on my USB 3.0
> ports without xhci drivers, but then I learned about 1) all the stuff
> that BIOS does and 2) how GRUB uses the BIOS to access disks
> (${grub_src}/grub-core/disk/i386/pc/biosdisk.c).
>

As soon as you load any driver that touches hardware directly on PC
BIOS platform, this driver disables disk access via biosdisk. Which in
turn means that some features that rely on BIOS become unavailable
(most prominent - chainloading of other loader code).

Effectively this means you switch to different platform that cannot be
called "PC BIOS" anymore.

> For our project, smartcard reader over USB 3.0, we have to implement
> that ourself. BIOS has support for that (AFAICT). (On the other hand,
> looks like UEFI might have something.)
>

Yes, UEFI specification lists smart card access protocol. I do not
know whether this is actually implemented by vendors; but any
implementation for grub should provide hardware independent part and
driver to access card itself.