On Fri, Jul 13, 2012 at 09:32:21AM -0600, Steve Goodrich wrote:
Legacy MBRs on HDDs and USB MSCs allow booting only from device id 0x80. This is OK for platforms that have only one HDD or USB device to boot from, but causes problems if the end user wants to have more than one HDD or USB MSC device in the boot order (and if those devices are present, but not bootable).
[...]
With the code in this patch, the system would behave like this:
- Assign HDD1 as device 0x80 and attempt to boot
- boot fails because the device is not bootable
- Rotate the boot order to be HDD2, Floppy, USB1, USB2, HDD1, making HDD2 device 0x80
The problem with this approach is that there is no way to change the drive id of hard drives controlled via option roms (eg, scsi drives). So, if a scsi drive is made 0x80 this scheme does not work at all, and if a scsi drive is not 0x80 there is no way to boot from it.
Thoughts?
I don't think I understand the use case you are trying to address. If a user has a stable set of drives attached they can configure the boot order via the bootorder file. If the user is attaching drives for one-off boots, they can hit F12 and choose which drive to boot from. What is the use case for a user that does not have a stable attachment of drives and is unable to hit F12?
On a technical note, the patch has some implementation issues: the use of "#if"s is undesirable - the compiler can weed out unused code and variables; SeaBIOS no longer uses the EBDA for internal storage - use global variables with the "VARLOW" decoration instead; it's not safe to alter IDMap in the boot phase as global variables are read-only after POST phase ends.
-Kevin
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.
So, if a scsi drive is made 0x80 this scheme does not work at all, and if a scsi drive is not 0x80 there is no way to boot from it.
You mention SCSI drives, and I'm not as familiar with those as I'd prefer. For this case, there are two options: Disable the Failover or Enable it. If the Failover is disabled, you get the behavior you had before. If Failover is enabled and the SCSI drive is 0x80 and it boots, then the code would progress as before. If Failover is enabled, the SCSI drive is 0x80 and it does not boot, at least the Failover would allow something to boot. As I see it, either the SCSI drive is bootable or not. If it's bootable, Failover makes no difference. If the SCSI drive is not bootable, Failover gives another drive the chance to boot.
On a technical note, the patch has some implementation issues...
I'll review the stuff you mentioned regarding Technical Notes. Certainly the use of "#if" is a style issue and can easily be changed, and the stuff I've got in the EBDA can be moved to global storage. I'm curious, though: 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?
Regards, -- Steve G.
-
Kevin O'Connor -
Steve Goodrich