On 10/06/16 05:05, spam collector wrote: > ----- Original Message ----- >> From: "Laszlo Ersek" <[email protected]> >> To: "spam collector" <[email protected]> >> Cc: [email protected] >> Sent: Wednesday, October 5, 2016 8:28:46 AM >> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData >> >> On 10/05/16 04:47, spam collector wrote: >>> >>> ----- Original Message ----- >>>> From: "Laszlo Ersek" <[email protected]> >>>> To: "spam collector" <[email protected]> >>>> Cc: [email protected] >>>> Sent: Tuesday, October 4, 2016 10:22:34 AM >>>> Subject: Re: [edk2] OVMF.fd and placement of EfiBootServicesData >> >>>> * The first stage improvement is the following command line: >>>> >>>> qemu-system-x86_64 -pflash OVMF.fd >>> >>> This did not work either with or without the NvVars file present. >> >> I think I'll need a more complete issue riport then -- what is your >> exact QEMU command line, and what OVMF binary are you using? > > "..\qemu-system-i386w.exe" -m 256 -localtime > -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 > -pflash ..\OVMF.fd -parallel file:para.txt > > Remember that I am running this in WinXPSP3.
First, I can't "remember" it, because this is the first time you state that. :) Second, WinXPSP3 as host machine, really?... :) Anyway, if both your QEMU and OVMF builds are okay / fresh enough, using OVMF with TCG (i.e., not KVM) should work, yes. > Also, the version of > OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed > that that page has been recently changed. That's a coincidence, but not a random one. Users have been repeatedly confused by the r15214 binary, which at this point was more than 2.5 years old. Just before your query, I noticed <https://bugs.launchpad.net/qemu/+bug/1622582> (and marked it invalid); the reporter of that issue was also tripped up by the ancient r15214 build. So I asked Jordan to please update the page you reference, with a link to Gerd's RPMs, which are bleeding edge builds. > You use to be able to > download the OVMF.fd directly from that page. It was r15214, which > I found out yesterday, is an older version. > >>> I did find a few RPM files and one of them contained: >>> OVMF_CODE-pure-efi.fd >>> and >>> OVMF_VARS-pure-efi.fd >> >> Yes, they are from Gerd's "edk2.git-ovmf-ia32" package (since you >> mention IA32), from <http://www.kraxel.org/repos/>, and they are >> recommended to use. > > I also could not get these to work. I will do a little more > research into why not and be sure to let you know. > >> Otherwise, download the "edk2.git-ovmf-ia32" or "edk2.git-ovmf-x64" RPM >> file (as needed) from <https://www.kraxel.org/repos/jenkins/edk2/>, and >> extract it with: >> >> rpm2cpio FILENAME | pax -r -v >> >> The extracted files you want are: >> >> usr/share/edk2.git/ovmf-*/OVMF_CODE-pure-efi.fd >> usr/share/edk2.git/ovmf-*/OVMF_VARS-pure-efi.fd >> usr/share/edk2.git/ovmf-*/UefiShell.iso > > These are the three files I used and could not get the shell to load. > I will try a few other things and get back with you. > > Please note that I am using the Windows port of QEMU from > https://qemu.weilnetz.de/ on a WinXP host, if that makes any > difference. It could make a difference. I've never ever used Windows binaries of QEMU. OTOH several people on this list have used such with success, so I can't say definitely either way. > > Also, one more question. I can make my GPT image either have a legacy > MBR with two entries pointing to one partition each or I can have a > Protected MBR that encompasses the whole GPT, both partitions, and the > backup items. > > With the r15214 version and: > > "..\qemu-system-i386w.exe" -m 256 -localtime > -drive file=uefi.bin.vhd,format=raw,if=ide,media=disk,index=0 > -bios ..\OVMF.fd -parallel file:para.txt > > it would boot to the shell either way and load and run my BOOT.efi file > just fine, whether I had a Legacy MBR or a PMBR. Does this make a > difference with the new image(s) you mention above. Sorry, I don't have any particular expertise with GPT. I believe the PartitionDxe driver that's built into OVMF received some updates over that 2.5y interval that I mentioned above. > Also, please note that the hard drive image is a VHD image, a > raw image with a single sector at the end for the VHD info so that > Oracles VM Box will boot it. This means that the backup GPT header > is *not* the last sector of the disk. As far as I know, QEMU supports VHDX. However, you pass a VHD image to -drive with format=raw. That looks very broken. I guess I'd suggest matching the actual image format with the format=... property. If you pass format=raw, the VHD metadata at the end of the image will be visible to the guest (as garbage). > The > > -bios OVMF.fd > > version boots it just fine in QEMU, but I thought I would mention > this in case the new code expects it to be in the last sector. I'm quite certain all GPT drivers in the guest expect a valid disk image, and format=raw, on a VHD disk image, seems to break that. Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
