On Mon, Jul 16, 2012 at 07:18:01AM -0600, Steve Goodrich wrote:
Thanks for the feedback, Kevin.
I don't think I understand the use case you are trying to address.
The use case is one I've got with a few customers who do not want end users to be able to change the boot order manually -- USB is a "last ditch" option, only to be used if all other devices fail, but they don't want users booting from their own USB drives if the other boot options are still functional. Also, these customers all have the same expectation with respect to bootorder: if the first drive is not bootable (even if it is present), then the next drive in the bootorder will be attempted. Thus, if the first drive is present but has no MBR (or its MBR has become corrupt), they expect the second drive to boot. Of course, the second drive can't boot in the current implementation since only the first drive can ever be 0x80.
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.
[...]
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.
-Kevin
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?
Regards, -- Steve G.
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.
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.
-
Gleb Natapov -
Kevin O'Connor -
Steve Goodrich