On Mon, 2013-01-21 at 16:59 -0800, Andrew Fish wrote: > Not sure if BdsGetBootTypeFromDevicePath() is broken, or functioning > as intended. Remember in EFI there is not a concept of a bootable > non-removable block IO device. The OS installs the OS loader as a > file and updates a variable to contain the path to the OS loader. This > allows an arbitrary number of operating systems to boot from a single > disk. So if you add a "bootable" disk into a system you still have to > manually config the file that is the OS loader. > > It is possible to add heuristics to know about well known loader > names, etc, but the open source code does not do any of this.
Yes, absolutely. Except that as discussed on the mailing list in the
not-so-distant past, it's very hard to tell what is "removable" and what
isn't these days, and currently there *is* a well-known loader name
of /etc/boot/boot${ARCHITECTURE}.efi which OVMF *will* attempt to boot.
If I invoke qemu with a certain disk image as IDE, it appears in the
boot menu and I can boot from it. If I invoke it with the same image a
virtio, it doesn't appear at all. Whatever the behaviour, it should be
*consistent* and not vary according to how the device is attached.
> If BdsGetBootTypeFromDevicePath() is broken it will be to not treat
> any device that produces Block IO as potentially bootable.
I'm not sure I can parse that sentence correctly. I've experimented with
treating every device that produces block IO as potentially bootable.
We'd certainly want them to get saner names than 'EFI Hard Disk 1'...
'EFI Hard Disk 37' if we're going to do that :)
And we probably *don't* want to register every *partition*.
> > I expected to see it appear *twice* in my boot menu; once for EFI
> > booting and once for the CSM. But neither of them appear...
>
> I've not thought about legacy BIOS for a long time, but you boot from
> C: or A:. It is up to the BIOS to define what is A: or what is C: The
> BBS spec allows selection of what is C: but that is a CSM and not EFI
> thing. You should be able to add a BBS device path node for C: and let
> the CSM figure out what is C:.
Except that in the CSM case, the "BIOS" isn't really in control; it's
supposed to do EFI's bidding. EFI passes the BBS_TABLE to the CSM which
controls the BCV priority. If the BBS_TABLE doesn't even *mention* the
virtio disk, then CSM doesn't know what priority it should have. To be
specific: the patch at
http://git.infradead.org/users/dwmw2/seabios.git/commitdiff/756273b1e8ed135a3178c5c2529c337471d460f5
would work fine on the CSM side for virtio disks, and would correctly select
which device is C: — if the EFI side actually gave me 'Legacy boot from VirtIO
disk' as an option in the menu and filled in the BBS_TABLE with it correctly.
Which it doesn't.
I suspect that the LegacyBiosBuildBbs() function *also* needs to list
all the devices that produce the Block IO protocol, and add them all to
the table?
And we also need to add a LUN field to BBS_TABLE, ideally, because we
might have more than one device behind each PCI function, and we need to
distinguish between them. Could we use some of the reserved bits in
BBS_STATUS_FLAGS for that?
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
