On 05/11/16 10:59, Thomas Lamprecht wrote: > I changed out the QEMU-pure-efi.fd with the QEMU_CODE-pure-efi.fd and
Argh. I completely missed that. Sorry -- that was another problem (the main one). I couldn't immediately remember what file did what in Gerd's RPMs. Clearly, if you use two pflash chips, then you must not use the unified file (that is mapped r/o) for the first one! That will shift down the second one, which will not be accessed at all. > got it working, this is the primary error from my side, without this the > VARS file never got written as I used the firmware intended to be used > without an separate VAR store. Yes. > One thing is a little strange for me: For getting the Boot order to work > I have to first add an Boot entry with QEMU-disk:\EFI\BOOT\BOOTX64.EFI > only after that the bootindex parameter from the QEMU command works, > else a "Misc Device" is present in the boot list which also boots my OS, > so I guess that it is pointed at BOOTX64.EFI located on the QEMU disk. > So if I understand correctly the disk gets recognized but does not gets > connected with the bootindex settings (=the FwCfg) but if I add manually > an entry this "connection" works. So this behavior follows from the "expressiveness" of the OpenFirmware device paths that QEMU exports in the "bootorder" fw_cfg file, and that OVMF translates to UEFI device path *prefixes*. QEMU can only identify different devices; it cannot tell apart various files on the same device for booting. Whereas UEFI can. So, if you have two Boot#### options in your BootOrder that are on the same device (i.e., share a UEFI device path prefix up to and excluding the FilePath node), then the prefix that results from the translation will be able to match both. In such cases, OVMF simply picks the first match. (Side remark: if a UEFI boot option in question is short-form, then the above applies after OVMF expands the boot option to full-form, for matching.) This is usually not a problem, because when you install your guest OS, it will run "efibootmgr", which places the OS's boot option right at the top of the list. Any "Misc Device" option, for the same drive, will be added *after it* at the next boot, so when OVMF picks the first match, it will work fine. However, if you lose your boot options (or varstore) for whatever reason, then you will have to re-add the OS bootloader option manually, and also move it to the top of the list manually. (I think that a fallback / recovery option would do this automatically, if your OS installs one.) Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
