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