SeaBIOS and USB UHCI keyboard support

[Kevin O'Connor]

The latest SeaBIOS git has preliminary support for USB keyboards.
I've tested this on qemu and on my epia-cn.

For info on obtaining SeaBIOS see:
http://www.coreboot.org/SeaBIOS

This support is still a little "rough" - help with testing would be
appreciated, but don't expect it to be fully functional.

Known issues:

- only uhci controllers are supported - no ohci (nor ehci)

- not all keys are mapped (eg, no numeric keypad)

- no keyboard auto-repeat

- no keyboard led support

- if one types fast, they may see dup keys or missing keys

- no hub support (keyboard must be directly attached)

- usb bandwidth is not optimized (no scheduling)

That said, I can control the SeaBIOS boot and navigate through a grub
console with my usb keyboard.

-Kevin

[Peter Stuge]

Kevin O'Connor wrote:
> The latest SeaBIOS git has preliminary support for USB keyboards.

Neat!

Can you reuse part of libpayload USB? Maybe even on source level?

//Peter

[Arnaud Maye]

Hello Kevin,

This is awesome. I am going to try this this week on my hardwares and 
let you know the
results.

Thank you!

Arnaud

Peter Stuge wrote:
> Kevin O'Connor wrote:
> > The latest SeaBIOS git has preliminary support for USB keyboards.
>
> Neat!
>
> Can you reuse part of libpayload USB? Maybe even on source level?
>
> //Peter

*
*

[Stefan Reinauer]

Kevin O'Connor wrote:
> The latest SeaBIOS git has preliminary support for USB keyboards.
> I've tested this on qemu and on my epia-cn.
>
> For info on obtaining SeaBIOS see:
> http://www.coreboot.org/SeaBIOS
>
> This support is still a little "rough" - help with testing would be
> appreciated, but don't expect it to be fully functional.
>
> Known issues:
>
> only uhci controllers are supported - no ohci (nor ehci)
>
> not all keys are mapped (eg, no numeric keypad)
>
> no keyboard auto-repeat
>
> no keyboard led support
>
> if one types fast, they may see dup keys or missing keys
>
> no hub support (keyboard must be directly attached)
>
> usb bandwidth is not optimized (no scheduling)
>
> That said, I can control the SeaBIOS boot and navigate through a grub
> console with my usb keyboard.

Would it not make sense to pack USB keyboard functionality into our GSoC
project instead, and use one common USB stack for all our projects?
Especially since this renders usbrom completely unusable; no two USB
stacks can operate the hw reliably at the same time.

I'm a bit surprised by such action. Are you planning to add USB MSC
support as well? Should we stop the OHCI efforts too and wait for your
approach on that?

Stefan

[Joseph Smith]

On Tue, 29 Sep 2009 16:47:04 +0200, Stefan Reinauer 
wrote:
> Kevin O'Connor wrote:
> > The latest SeaBIOS git has preliminary support for USB keyboards.
> > I've tested this on qemu and on my epia-cn.
> >
> > For info on obtaining SeaBIOS see:
> > http://www.coreboot.org/SeaBIOS
> >
> > This support is still a little "rough" - help with testing would be
> > appreciated, but don't expect it to be fully functional.
> >
> > Known issues:
> >
> > only uhci controllers are supported - no ohci (nor ehci)
> >
> > not all keys are mapped (eg, no numeric keypad)
> >
> > no keyboard auto-repeat
> >
> > no keyboard led support
> >
> > if one types fast, they may see dup keys or missing keys
> >
> > no hub support (keyboard must be directly attached)
> >
> > usb bandwidth is not optimized (no scheduling)
> >
> > That said, I can control the SeaBIOS boot and navigate through a grub
> > console with my usb keyboard.
>
> Would it not make sense to pack USB keyboard functionality into our GSoC
> project instead, and use one common USB stack for all our projects?
> Especially since this renders usbrom completely unusable; no two USB
> stacks can operate the hw reliably at the same time.
>
> I'm a bit surprised by such action. Are you planning to add USB MSC
> support as well? Should we stop the OHCI efforts too and wait for your
> approach on that?

Great news Kevin!
I would have to agree with Stefan here, please share the wealth :-)

[Kevin O'Connor]

Hi Stefan,

On Tue, Sep 29, 2009 at 04:47:04PM +0200, Stefan Reinauer wrote:
> Kevin O'Connor wrote:
> > The latest SeaBIOS git has preliminary support for USB keyboards.
> > I've tested this on qemu and on my epia-cn.
>
> Would it not make sense to pack USB keyboard functionality into our GSoC
> project instead, and use one common USB stack for all our projects?
> Especially since this renders usbrom completely unusable; no two USB
> stacks can operate the hw reliably at the same time.
>
> I'm a bit surprised by such action.

I'm sorry you were surprised.  I sent a note last month that I was
going to look at this.  I am truly sorry for the surprise and for any
disappointment.

SeaBIOS needs USB support in order to be usable on many platforms.  I
want SeaBIOS to be a "turn key" solution - that is, I want a vendor to
be able to boot up coreboot+seabios and say, "hey, this 'just works'".

I would prefer to pull in an external solution than implement a new
one.  Unfortunately, there isn't an external solution that works
today.

I looked closely at the libpayload code; I felt it would not work well
in the constrained environment that SeaBIOS runs in.  I believe
libpayload could be extended to support that constrained environment,
but I worry that would be an unnecessary burden on the other users of
libpayload (which aren't so constrained).

The support in SeaBIOS is currently 1029 lines of code - it is a
direct, no nonsense, just make it work implementation.
> Are you planning to add USB MSC
> support as well? Should we stop the OHCI efforts too and wait for your
> approach on that?

If someone steps forward with a solution that "just works", then I
will happily defer to that person.  Otherwise, I will continue to add
new features as I get time.

The next thing I am planning to look at is basic ohci keyboard
support, and then fleshing out the current keyboard support (eg,
auto-repeat, keyboard leds).

-Kevin

[Mansoor]

Its really a great news!!!. I will test this on my hardware (Intel Atom
(Silverthorne) & SCH US15W (Poulsbo) chipset)

A dumb question here... 
Why SeaBIOS have constrains? 
Can't we elaborate SeaBIOS as a driver part of coreboot? I mean a legacy
BIOS interrupts part(with constrains) + a driver section (includes support
for various drivers like USB keyboard USB mouse USB CDROM Hard disk etc)
without any constrains so that we can make use of current implementations
from Linux or other open source

Do you have any plan to support USB CD-ROM ?

-----Original Message-----

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Kevin O'Connor
Sent: Wednesday, September 30, 2009 6:24 AM
To: Stefan Reinauer
Cc: coreboot
Subject: Re: [coreboot] SeaBIOS and USB UHCI keyboard support

Hi Stefan,

On Tue, Sep 29, 2009 at 04:47:04PM +0200, Stefan Reinauer wrote:
> Kevin O'Connor wrote:
> > The latest SeaBIOS git has preliminary support for USB keyboards.
> > I've tested this on qemu and on my epia-cn.
>
> Would it not make sense to pack USB keyboard functionality into our GSoC
> project instead, and use one common USB stack for all our projects?
> Especially since this renders usbrom completely unusable; no two USB
> stacks can operate the hw reliably at the same time.
>
> I'm a bit surprised by such action.

I'm sorry you were surprised.  I sent a note last month that I was
going to look at this.  I am truly sorry for the surprise and for any
disappointment.

SeaBIOS needs USB support in order to be usable on many platforms.  I
want SeaBIOS to be a "turn key" solution - that is, I want a vendor to
be able to boot up coreboot+seabios and say, "hey, this 'just works'".

I would prefer to pull in an external solution than implement a new
one.  Unfortunately, there isn't an external solution that works
today.

I looked closely at the libpayload code; I felt it would not work well
in the constrained environment that SeaBIOS runs in.  I believe
libpayload could be extended to support that constrained environment,
but I worry that would be an unnecessary burden on the other users of
libpayload (which aren't so constrained).

The support in SeaBIOS is currently 1029 lines of code - it is a
direct, no nonsense, just make it work implementation.
> Are you planning to add USB MSC
> support as well? Should we stop the OHCI efforts too and wait for your
> approach on that?

If someone steps forward with a solution that "just works", then I
will happily defer to that person.  Otherwise, I will continue to add
new features as I get time.

The next thing I am planning to look at is basic ohci keyboard
support, and then fleshing out the current keyboard support (eg,
auto-repeat, keyboard leds).

-Kevin

[Peter Stuge]

Kevin O'Connor wrote:
> The support in SeaBIOS is currently 1029 lines of code - it is a
> direct, no nonsense, just make it work implementation.

I think that is wonderful! Good job!
> The next thing I am planning to look at is basic ohci keyboard
> support, and then fleshing out the current keyboard support (eg,
> auto-repeat, keyboard leds).

The USB option ROM is still a tricky point. How to make it co-exist
with USB support in SeaBIOS?

If the option ROM works out well, maybe it could instead offer the
keyboard services?

//Peter

[Kevin O'Connor]

On Wed, Sep 30, 2009 at 09:18:21PM +0200, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > The support in SeaBIOS is currently 1029 lines of code - it is a
> > direct, no nonsense, just make it work implementation.
>
> I think that is wonderful! Good job!

Thanks!
> > The next thing I am planning to look at is basic ohci keyboard
> > support, and then fleshing out the current keyboard support (eg,
> > auto-repeat, keyboard leds).
>
> The USB option ROM is still a tricky point. How to make it co-exist
> with USB support in SeaBIOS?

As Stefan pointed out, there can be only one driver of a usb
controller.  Anything else would be too fragile.
> If the option ROM works out well, maybe it could instead offer the
> keyboard services?

Yes - an option ROM can support keyboard.  However, a real 16bit
option ROM implementation is going to impose the same constraints on
libpayload as SeaBIOS.  Alternatively, the option rom could give up
support for vm86 mode callers and reserve lots of high ram to avoid
those constraints.  It still wouldn't be simple - the rom would need
to implement the bios calls for disk and kbd (seabios src/disk.c
src/kbd.c src/bregs.h src/entryfuncs.S = 1792 lines of code) and may
need to implement self uncompression (to reduce its rom code size).
I'd say it's doable, but not easy.

-Kevin

[Peter Stuge]

Kevin O'Connor wrote:
> > The USB option ROM is still a tricky point. How to make it co-exist
> > with USB support in SeaBIOS?
>
> As Stefan pointed out, there can be only one driver of a usb
> controller.  Anything else would be too fragile.

Yeah. The debug port can be used in parallell with another USB stack,
but that's only good for debug transfers.
> > If the option ROM works out well, maybe it could instead offer
> > the keyboard services?
>
> Yes - an option ROM can support keyboard.

..
> I'd say it's doable, but not easy.

I don't know what the result was/is from the GSoC project. You are
aware that there has been a GSoC project for a USB option ROM, right?

//Peter