[SeaBIOS] Bootorder Failover (Patch)

[Steve Goodrich]

There's certainly no reason to add an artificial limitation.  

Does QEMU (or XEN, for that matter) often have an invalid/unbootable drive
in its boot order?  Granted, SeaBIOS is used a lot in those environments,
but not exclusively (obviously, since I'm trying to use it in a
coreboot-based project).  But this issue has apparently not come up in the
emulated environments, otherwise I suspect that the "read the MBR before
adding to the drive list" would have been added a long time ago.

However, I'm happy to change the implementation if someone can help me
figure out how to read a sector directly (i.e. without using the int 13h
calls).

	-- Steve G.

> -----Original Message-----
> From: Gleb Natapov [mailto:gleb at redhat.com]
> Sent: Tuesday, July 17, 2012 7:10 AM
> To: Steve Goodrich
> Cc: 'Kevin O'Connor'; seabios at seabios.org
> Subject: Re: [SeaBIOS] Bootorder Failover (Patch)
> 
> On Tue, Jul 17, 2012 at 06:43:01AM -0600, Steve Goodrich wrote:
> > > From: Kevin O'Connor [mailto:kevin at koconnor.net]
> > > If checking for an MBR is sufficient to determine if the drive is
> > > "bootable" then I'd suggest adding an option to read and validate the
> > > MBR in the POST phase prior to assigning a drive id to it.
> >
> > I had looked into this, but could not trace out the functions/methods
that
> > would allow me to read a single sector from the device.  Can you give me
a
> > pointer on this?
> >
> > > [...]
> > > > Why is it not safe to alter the IDMap in the boot phase?  Is it
unsafe
> > to
> > > > allow it to change before the device has actually booted, or is it
only
> > > > unsafe to change once the device has transferred execution to the
OS?
> > >
> > > The BIOS specs call for making the f-segment read-only after the POST
> > > phase ends.  This is implemented under QEMU (and only on QEMU).  The
> > > "IDMap" variable (along with all variables marked with VAR16) is
> > > stored in the f-segment.
> >
> > What BIOS specs are you referring to?  I don't recall seeing those.
> >
> > Also, since this is currently targeted at a production coreboot/SeaBIOS
> > environment, would it be sufficient to make the feature dependent upon
the
> > BIOS being built for coreboot?
> >
> If it makes sense for QEMU why add the limitation?
> 
> --
> 			Gleb.