Harrison, Jon (SELEX GALILEO, UK) schrieb:
OK. So I seem to have got my build deploying seaBIOS (0.4.1) , but appear to have hit a major obstacle.
No USB Keyboard Support!? This is a complete show stopper for me.
I've seen a thread from last summer talking about adding USB Kbd support:: http://www.coreboot.org/pipermail/coreboot/2008-December/043714.html
Has anything happened anywhere on this ??
I'm now trying to decide whether I fancy my chances of adding CBFS support to FILO or USB keyboard to SeaBIOS more !!!
USB keyboard support for SeaBIOS will require that you emulate a standard PS/2 keyboard (io 0x60/0x62) interface in system management mode (SMM), passing the commands on to a USB stack (There is one in libpayload which should probably be used. It's the stack that is used in FILO for USB keyboard support, too). Right now there is only a SMM handler for i945/i82801gx, and it has no USB keyboard legacy emulation, but it can show you quite well what needs to be done to implement an SMM handler for a coreboot platform.
CBFS support in FILO (or libpayload, for that matter) is definitely the quicker approach.
Stefan
On Thu, Aug 20, 2009 at 02:06:07PM +0200, Stefan Reinauer wrote:
Harrison, Jon (SELEX GALILEO, UK) schrieb:
I'm now trying to decide whether I fancy my chances of adding CBFS support to FILO or USB keyboard to SeaBIOS more !!!
USB keyboard support for SeaBIOS will require that you emulate a standard PS/2 keyboard (io 0x60/0x62) interface in system management mode (SMM), passing the commands on to a USB stack (There is one in libpayload which should probably be used. It's the stack that is used in FILO for USB keyboard support, too). Right now there is only a SMM handler for i945/i82801gx, and it has no USB keyboard legacy emulation, but it can show you quite well what needs to be done to implement an SMM handler for a coreboot platform.
I believe it is possible to add USB keyboard support to SeaBIOS without requiring SMM mode. I believe a regular usb keyboard driver will work fine.
CBFS support in FILO (or libpayload, for that matter) is definitely the quicker approach.
Very true.
-Kevin
Am 21.08.2009 04:32, schrieb Kevin O'Connor:
I believe it is possible to add USB keyboard support to SeaBIOS without requiring SMM mode. I believe a regular usb keyboard driver will work fine.
That fails because many systems use port 0x60/0x64 as soon as they can, instead of the BIOS interface. So the system stops responding on the keyboard as soon as the keyboard driver is loaded - not very intuitive.
Patrick
Kevin O'Connor wrote:
On Thu, Aug 20, 2009 at 02:06:07PM +0200, Stefan Reinauer wrote:
Harrison, Jon (SELEX GALILEO, UK) schrieb:
I'm now trying to decide whether I fancy my chances of adding CBFS support to FILO or USB keyboard to SeaBIOS more !!!
USB keyboard support for SeaBIOS will require that you emulate a standard PS/2 keyboard (io 0x60/0x62) interface in system management mode (SMM), passing the commands on to a USB stack (There is one in libpayload which should probably be used. It's the stack that is used in FILO for USB keyboard support, too). Right now there is only a SMM handler for i945/i82801gx, and it has no USB keyboard legacy emulation, but it can show you quite well what needs to be done to implement an SMM handler for a coreboot platform.
I believe it is possible to add USB keyboard support to SeaBIOS without requiring SMM mode. I believe a regular usb keyboard driver will work fine.
Hm.. Last thing I heard is that most boot loaders don't call intXX functions but read int 0x60/0x64. I don't have definite numbers on that, though. I suppose if a normal driver would work, we could hook up another int in Jason's usbrom and we're good?
Stefan
On Fri, Aug 21, 2009 at 09:14:38AM +0200, Stefan Reinauer wrote:
Hm.. Last thing I heard is that most boot loaders don't call intXX functions but read int 0x60/0x64.
I just double checked - freedos, ntldr, winxp install, lilo, grub, and isolinux all read keys via the bios.
I don't have definite numbers on that, though. I suppose if a normal driver would work, we could hook up another int in Jason's usbrom and we're good?
I think hardware irq support is needed for keyboard.
-Kevin
On 8/22/09 3:54 PM, Kevin O'Connor wrote:
On Fri, Aug 21, 2009 at 09:14:38AM +0200, Stefan Reinauer wrote:
Hm.. Last thing I heard is that most boot loaders don't call intXX functions but read int 0x60/0x64.
I just double checked - freedos, ntldr, winxp install, lilo, grub, and isolinux all read keys via the bios.
Oh this is great news. I think your list is extensive enough to decide against a legacy emulation in SMM, given the trouble it would bring (Alternatively we could add an interface to SMM that usbrom could hook into, but that sounds like a big security issue on the second thought)
I don't have definite numbers on that, though. I suppose if a normal driver would work, we could hook up another int in Jason's usbrom and we're good?
I think hardware irq support is needed for keyboard.
What's required for this? Just set up an IRQ for the USB device and add a 16bit intXX handler?
Stefan
On Sat, Aug 22, 2009 at 04:15:10PM +0200, Stefan Reinauer wrote:
On 8/22/09 3:54 PM, Kevin O'Connor wrote:
I think hardware irq support is needed for keyboard.
What's required for this? Just set up an IRQ for the USB device and add a 16bit intXX handler?
In order to use the usb irq it will be necessary to figure out what irq line it is mapped to when the machine is in 8259 emulation mode. That should just require looking at the PCI_INTERRUPT_LINE field of pci config space - assuming coreboot is configured to set this properly. Once the line is known, it's not too difficult to map a handler and ack the irqs.
However, Rudolf raised a potential problem - when an OS later reconfigures the machine out of 8259 emulation mode, it may get confused by a pending usb irq. (The native irq may be level based.)
One trick I think SeaBIOS can implement is rapid polling by configuring the RTC to trigger 1024 times a second. It can then check for usb activity using hardware irqs without having to use the usb irq.
-Kevin
Am 23.08.2009 02:05, schrieb Kevin O'Connor:
On Sat, Aug 22, 2009 at 04:15:10PM +0200, Stefan Reinauer wrote:
On 8/22/09 3:54 PM, Kevin O'Connor wrote:
I think hardware irq support is needed for keyboard.
What's required for this? Just set up an IRQ for the USB device and add a 16bit intXX handler?
Sorry I chime in so late. Do you need the hardware irq support to prevent losing events? If so, the USB stack takes care of it: The keyboard driver prepares a schedule of configurable length in advance. By default, it's setup that this schedule is able to survive at least 200 msecs, and that could be increased, so we won't need the ~1msec resolution. And even if not, the USB HID only sends data every 10msec, if I remember correctly.
Patrick
On Sun, Aug 23, 2009 at 09:10:17AM +0200, Patrick Georgi wrote:
Sorry I chime in so late. Do you need the hardware irq support to prevent losing events? If so, the USB stack takes care of it: The keyboard driver prepares a schedule of configurable length in advance. By default, it's setup that this schedule is able to survive at least 200 msecs, and that could be increased, so we won't need the ~1msec resolution. And even if not, the USB HID only sends data every 10msec, if I remember correctly.
The main thing would be to not lose events. If it can buffer enough events then this wouldn't be a problem. Does OHCI have the same ability to queue events?
The secondary thing is keyboard repeat. As I understand it the repeat has to be implemented in software. The software needs to know roughly when the key is pressed and released in order to implement the repeat accurately.
-Kevin
Am 23.08.2009 16:10, schrieb Kevin O'Connor:
The main thing would be to not lose events. If it can buffer enough events then this wouldn't be a problem. Does OHCI have the same ability to queue events?
OHCI is supposed to be even more advanced, and I think so, but I'm not sure. I'll tell you once I tested leandro's work.
The secondary thing is keyboard repeat. As I understand it the repeat has to be implemented in software. The software needs to know roughly when the key is pressed and released in order to implement the repeat accurately.
Keyboard repeat can be done by the keyboard, I think.
Patrick
-
Kevin O'Connor -
Patrick Georgi -
Stefan Reinauer