On Mon, Dec 09, 2019 at 01:09:11PM +0100, Gerd Hoffmann wrote:
On Fri, Dec 06, 2019 at 08:17:04PM -0800, Your Real Name wrote:
On Thu, Dec 05, 2019 at 07:06:37AM +0100, Gerd Hoffmann wrote:
Hi,
The priority value(the last argument we pass to boot_add_bev()) will affect the order of the boot list. The getRomPriority() will calculate the final priority based on the system provided BBS, etc. This is even true in CSM case. If we drop the getRomPriority call and instead do: boot_add_bev(FLATPTR_TO_SEG(rom), pnp->bev, pnp->productname, 0); then this bev entry will be the first boot option in the boot list because hard disk typically has priority larger than 100 (lower priority will be closer to the beginning of the boot list).
HD gets 103 (DefaultHDPrio). I'd suggest to use 104 (DefaultBEVPrio) instead of 0.
Or maybe better keep the getRomPriority() call and drop the rom_instance variable only. While getRomPriority() doesn't do anything for your use case (on physical hardware) it will have an effect when running as seabios as OVMF CSM in qemu.
As far as I know, QEMU only supports UEFI PCI Rom, not legacy PCI Rom:-)
qemu doesn't care at all ;)
It's the firmware which cares. seabios uses the legacy PCI Rom. OVMF uses the UEFI PCI Rom. OVMF with seabios as CSM can use both.
Building OVMF with CSM isn't very common though. A virtual machine can (unlike physical hardware) easily switch the fimware, so if you need legacy bios support you can just run seabios directly instead of going the CSM route.
I guess that is another patch which is not upstream? How about posting that too? Seeing the big picture (how do you handle boot order on physical hardware where you have no bootorder fw_cfg file) might be helpful for discussing this patch.
That patch is pretty easy but may not be appropriate for upstream because it's not generic. Basically in do_boot() we filter the boot entry from BEV[] by type. For example, we may want to try BEV device(pci rom) first, then we try HD drives. If there are multiple HD drives, then we filer by PCI IDs. All those orders and priorities are hard coded.
One option to deal with that would be to allow compiling in a fallback bootorder file, which seabios would use when it there isn't one supplied by qemu and the also isn't one provided by coreboot (in cbfs). Works only if bootorder matching can handle your needs. I think looking at PCI IDs doesn't work. BDFs will work though.
Yes, bootorder file doesn't handle PCI IDs. But we have plug-in HD drives so BDFs are dynamic on different system configuraton. In my casePCI ID is the only way to choose boot device, but it's not generic:-)
cheers, Gerd