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.
I'm fine to drop the getRomPriority call and pass 0 to the boot_add_bev() call since I need manually adjust do_boot() logic anyway for my case.
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.
cheers, Gerd