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@redhat.com] Sent: Tuesday, July 17, 2012 7:10 AM To: Steve Goodrich Cc: 'Kevin O'Connor'; seabios@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@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.