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 > [email protected] > http://lists.gnu.org/mailman/listinfo/grub-devel > >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
