[SeaBIOS] [RFC] SeaBIOS v2.0 and 32bit drivers
kevin at koconnor.net
Tue May 13 18:45:03 CEST 2014
On Tue, May 13, 2014 at 03:27:30PM +0100, David Woodhouse wrote:
> On Thu, 2014-04-24 at 22:02 -0400, Kevin O'Connor wrote:
> > I've been considering a possible architectural change to SeaBIOS.
> > Currently, SeaBIOS contains a mix of 16bit code and 32bit code. All
> > of the initialization and bootup code is done in regular 32bit mode,
> > but runtime code (the callbacks the OS uses) is generally run in 16bit
> > mode. I have been thinking about possibly changing this so that
> > hardware driver code runs exclusively in 32bit mode.
> > The biggest downside to this change would be problems running old DOS
> > era programs that attempt to run the BIOS in vm86 mode. Specifically,
> > the dos emm386 program is known to prevent 32 bit trampolines in
> > SeaBIOS from working. (There's been a bit of experience with AHCI
> > drivers running in 32bit mode (and now XHCI) so we have good
> > confidence that modern OSes wont present a problem.) To continue to
> > support these old DOS era programs I'm proposing we implement an SMI
> > to help trampoline to 32bit mode.
> This sounds broadly similar to the approach taken by some CSM
> implementations. Instead of having native device drivers in the CSM and
> actually taking over the hardware as SeaBIOS does, they use SMI to
> trampoline back into UEFI-side code and use the drivers there.
> If we're going to do this, it would be interesting to see if we can use
> the same protocol — both for thunking from 16-bit to 32-bit SeaBIOS
> code, and for thunking from the SeaBIOS CSM to OVMF/UEFI.
That is interesting. Do you have a link to code or a spec handy? (I
looked through the "Compatibility Support Module Specification" again
and I see it talks about SMMs, but it seems to say that what is
implemented is "IBV" specific.)
I have some SMI code for QEMU TCG at:
it's raw, but the basic idea is to implement the same logic in
stacks.c:call32() and romlayout.S:trampoline32() except by using an
SMI instead of the normal method of entering protected mode. That is,
the high level goal is to provide a function that can be called from
SeaBIOS 16bit C code which can run a SeaBIOS 32bit C function.
> Using the native UEFI drivers via such a thunk would resolve a number of
> the issues around who owns the hardware, and how we continue with a UEFI
> boot after a 'Legacy' boot attempt has failed (to detect the 0x55aa
> signature on a boot sector, for example).
One of my sub-goals with moving the drivers to 32bit mode is to make a
more clear separation between all the legacy interface code and the
hardware driver code. It sounds like such a separation would also
help with what you describe above. That said, I'm skeptical lots more
interaction with UEFI is a solution. :-)
More information about the SeaBIOS