Re: GRUB and USB questions

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, Sarah. And welcome to our mailing list. Perhaps you remember me:
we met in Bordeaux and I asked about using xhci in polling mode. I
looked into spec since then and USBSTATUS register should be enough. I
promised to write to you about it but I had too many things to do lately.
On 08/26/2010 10:10 PM, Sarah Sharp wrote:
> I have a couple of questions about how GRUB handles USB.  I'm a Linux
> kernel developer, not a GRUB developer, so please bare with me. :)
>
> I heard that GRUB does not support EHCI host controllers yet.  Is
> that still true?
There is one person who said he'll do EHCI. However we have heard
anything from him since then, perhaps he abandonded
>   If so, how does GRUB work on the newer Intel chipsets
> with rate matching hubs (EHCI host controllers without an integrated
> UHCI/OHCI companion controller)?
>   
Not well. We've received a bug report about those
> Does GRUB use the PS2 keyboard emulation that the BIOS provides during
> boot?  Or does it directly use the USB device through the UHCI or OHCI
> controller?
>   
Default is to use BIOS services. But it's possible:
 to switch to PS/2 emulation with:
terminal_input at_keyboard
or to direct usage of USB device by:
insmod uhci
(or ohci depending on the host controller)
Currently there is an issue with the way we implement it (using
GET_REPORT instead of polling interrupt pipe). I solved it in keylayouts
branch but it needs some cleanup
> How does GRUB handle booting off of a USB device?  Will it need to have
> support for the host controller the device is under to work, or can it
> use some support from the BIOS instead?
>   
There are 3 different approaches:
- BIOS support. This is needed to load the GRUB from the USB device. If
it's present GRUB uses it unless otherwise instructed. Such support is
usually present on mobos with integrated controller. Unfortunately
quality of BIOS is too often well below any expectations. It often
ignores some devices altogether (e.g. often the case with cardreaders),
mishandles SMM and causes trouble at handaout or is hit by other bugs
(like having 128GiB limit on USB even if bigger SATA drives work fine on
same platform)
- Option ROM. Basically devices (e.g. PCI-express USB card) can add sort
of plugins to BIOS. Theoretically it allows to have same functionality
as standard BIOS support. In practice many BIOSes just don't load them
or have bugs which make such devices misbehave.
- GRUB native support. This allows GRUB to load kernels even from
devices otherwise unaccessible from BIOS or in cases when no
grub+coreboot or grub by itself is used as firmware. If the machine
isn't grub-firmware-one such support still doesn't allow GRUB itself to
be loaded from such BIOS-invisible disk but allows to load kernels from
it if grub itself is installed on main disk. Experience proved this
fonctionality to be useful.
Would it be possible for Intel to spare some resources for GRUB USB
support? It's something small in comparison with e.g. Linux USB support
(we have no threads, our performance requirements are softer and so on).
Our most-qualified coders are unfortunately busy. Also in case of xHCI I
doubt anyone of them has the hardware (I know it doesn't cost a lot, but
I have no appropriate available slots for it. My laptop is pretty
unexpandable)
> Thanks!
>
> Sarah Sharp
> Open Source Technology Center
> Intel Corp
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature