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. cheers, Gerd _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
