From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fo.cableone.cmh.synacor.com (smtp-fo.cableone.cmh.synacor.com [64.8.70.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DD5921A1E1F for ; Wed, 5 Oct 2016 20:05:35 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=M88PEG4s c=1 sm=1 tr=0 a=F7HL8DhlWvVqsgDc77s/Qg==:117 a=FKkrIqjQGGEA:10 a=m0sRR0la7fUA:10 a=IkcTkHD0fZMA:10 a=20KFwNOVAAAA:8 a=otLtsZP2AAAA:8 a=i3X5FwGiAAAA:8 a=hqBzw_eTAAAA:8 a=RYJPnzK0AAAA:8 a=EQVovBLUAAAA:8 a=6u3s7alUdwR0_k7kzv4A:9 a=QEXdDO2ut3YA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=e_O65bzb51kRm2y5VmPK:22 a=gVyqtFkygESWxkzkOzyS:22 a=mmqRlSCDY2ywfjPLJ4af:22 a=bkWp_v3HvcftT6DRAIDL:22 a=71IlbOU7e524H-Equz-4:22 a=md20nNIlbyj33D6hWTAT:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: c3BhbWNvbGxlY3RvckBjYWJsZW9uZS5uZXQ= Received: from [10.203.0.111] ([10.203.0.111:53994] helo=md11.cableone.synacor.com) by mail.cableone.net (envelope-from ) (ecelerity 3.6.6.45965 r(Core:3.6.6.0)) with ESMTP id 68/92-05822-E7FB5F75; Wed, 05 Oct 2016 23:05:34 -0400 Date: Wed, 5 Oct 2016 23:05:34 -0400 (EDT) From: spam collector To: Laszlo Ersek Cc: edk2-devel@ml01.01.org Message-ID: <1208026991.99496554.1475723134167.JavaMail.zimbra@cableone.net> In-Reply-To: <280e3403-1821-396e-5243-54b770dcb01a@redhat.com> References: <1825038664.87486514.1475464584880.JavaMail.zimbra@cableone.net> <9f2b0b8c-9bfb-dd73-f7cb-cd6df775c237@redhat.com> <812341546.91963700.1475549145141.JavaMail.zimbra@cableone.net> <5c54ce38-9f0c-ac8d-c926-570ebc3dd720@redhat.com> <1747186652.93714260.1475599157436.JavaMail.zimbra@cableone.net> <94a76bd7-732c-c8f6-b8be-8175dd061b86@redhat.com> <1410853764.96270806.1475635626572.JavaMail.zimbra@cableone.net> <280e3403-1821-396e-5243-54b770dcb01a@redhat.com> MIME-Version: 1.0 X-Originating-IP: [174.126.140.68] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF49 (Win)/8.0.7_GA_6021) Thread-Topic: OVMF.fd and placement of EfiBootServicesData Thread-Index: IeMfoi5DRRw4AQ0emX34XSEet//BQg== Subject: Re: OVMF.fd and placement of EfiBootServicesData X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 03:05:36 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Laszlo Ersek" > To: "spam collector" > Cc: edk2-devel@ml01.01.org > 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" > >> To: "spam collector" > >> Cc: edk2-devel@ml01.01.org > >> 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. Also, the version of OVMF.fd is from http://www.tianocore.org/ovmf/ and I just noticed that that page has been recently changed. 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 , 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 , 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. 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. 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. 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. Thank you. I will get back with you on my findings. Ben