summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/Sec: Support SECTION2 DXEFV typesThomas Palmer2016-07-271-3/+13
| | | | | | | | | | | | | | | | Support down-stream projects that require large DXEFV sizes greater than 16MB by handling SECTION2 common headers. These are already created by the build tools when necessary. Use IS_SECTION2 and SECTION2_SIZE macros to calculate accurate image sizes when appropriate. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix NB->MB typo in commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Sec: Use EFI_COMMON_SECTION_HEADER to avoid castsThomas Palmer2016-07-271-4/+5
| | | | | | | | | | | Drop superfluous casts. There is no change in behavior because EFI_FIRMWARE_VOLUME_IMAGE_SECTION is just a typedef of EFI_COMMON_SECTION_HEADER. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: silence X64 VS2015x86 warningLaszlo Ersek2016-07-181-1/+1
| | | | | | | | | | | | | | | | | | VS2015x86 reports the following warning for "OvmfPkg/PlatformPei/MemDetect.c": > MemDetect.c(357): error C2220: warning treated as error - no 'object' > file generated > MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to > 'UINT32', possible loss of data LowerMemorySize is first assigned from GetSystemMemorySizeBelow4gb(), which returns UINT32. Change the type of LowerMemorySize accordingly. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warningsLaszlo Ersek2016-07-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32, the VS2015x86 compiler emits the following: > XenSupport.c(41): error C2220: warning treated as error - no 'object' > file generated > XenSupport.c(41): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(48): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(49): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(50): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(222): warning C4244: 'function': conversion from 'UINT64' > to 'UINTN', possible loss of data > XenSupport.c(241): warning C4244: 'function': conversion from 'UINT64' > to 'UINTN', possible loss of data PciLib functions take UINTN addresses that were encoded with the PCI_LIB_ADDRESS() macro. We carry addresses from the macro invocations to the function calls in two UINT64 variables however. This loses no data, but it alerts VS2015x86. Change the variable types to UINTN. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfgLaszlo Ersek2016-07-154-0/+142
| | | | | | | | | | | | | | | | | | Under certain circumstances, QEMU exposes the "etc/msr_feature_control" fw_cfg file, with a 64-bit little endian value. The firmware is supposed to write this value to MSR_IA32_FEATURE_CONTROL (0x3a), on all processors, on the normal and the S3 resume boot paths. Utilize EFI_PEI_MPSERVICES_PPI to implement this feature. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Fixes: https://github.com/tianocore/edk2/issues/97 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek2016-07-156-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek2016-07-154-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | No module in OvmfPkg uses these PCDs any longer. The first PCD mentioned is declared by OvmfPkg, so we can remove even the declaration. The second PCD comes from IntelFrameworkModulePkg. The module that consumes PcdS3AcpiReservedMemorySize is called "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable in OVMF. The 32KB gap that used to be the S3 permanent PEI memory is left unused in MEMFD for now; it never hurts to have a few KB available there, for future features. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3Laszlo Ersek2016-07-152-14/+30
| | | | | | | | | | | | | | | | | | | | | Move the permanent PEI memory for the S3 resume boot path to the top of the low RAM (just below TSEG if the SMM driver stack is included in the build). The new size is derived from CpuMpPei's approximate memory demand. Save the base address and the size in new global variables, regardless of the boot path. On the normal boot path, use these variables for covering the area with EfiACPIMemoryNVS type memory. PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused in PlatformPei; remove them. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for CpuMpPeiLaszlo Ersek2016-07-151-1/+23
| | | | | | | | | | | | | | | | | | | | CpuMpPei will have to place the AP startup vector in memory under 1MB. For this, CpuMpPei borrows memory under 1MB, but it needs a memory resource descriptor HOB to exist there even on the S3 resume path (see the GetWakeupBuffer() function). Produce such a HOB as an exception on the S3 resume path. CpuMpPei is going be dispatched no earlier than PlatformPei, because CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid, and PlatformPei calls PublishSystemMemory(). Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: add missing auto variable initializationArd Biesheuvel2016-07-131-0/+1
| | | | | | | | | | | The E820EntriesCount variable in XenPublishRamRegions() may be referenced without being initialized on RELEASE builds, since the ASSERT that fires if the call to XenGetE820Map() fails is compiled out in that case. So initialize it to 0. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek2016-07-138-0/+390
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
* OvmfPkg/PlatformBootManagerLib: remove stale FvFile boot optionsLaszlo Ersek2016-07-132-0/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Removes any boot options that point to binaries built into the firmware and have become stale due to any of the following: - DXEFV's base address or size changed (historical), - DXEFV's FvNameGuid changed, - the FILE_GUID of the pointed-to binary changed, - the referenced binary is no longer built into the firmware. For example, multiple such "EFI Internal Shell" boot options can coexist. They technically differ from each other, but may not describe any built-in shell binary exactly. Such options can accumulate in a varstore over time, and while they remain generally bootable (thanks to the efforts of BmGetFileBufferByFvFilePath()), they look bad. Filter out any stale options. This functionality is not added to QemuBootOrderLib, because it is independent from QEMU and fw_cfg. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: add a Name GUID to each Firmware VolumeLaszlo Ersek2016-07-133-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but the detailed description can be found in Volume 3 of the Platform Init spec (which is at 1.4a currently). Adding an FvNameGuid statement to [FV.xxx] has the following effects (implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"): - The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not directly, see below). - An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to address. This object is not followed by any EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only specifies the Name GUID for the firmware volume. The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found in the Build directory as a separate file (20 bytes in size): Build/Ovmf*/*_GCC*/FV/*.ext - The new data consume 48 bytes in the following volumes: SECFV, FVMAIN_COMPACT, DXEFV. They comprise: - 16 padding bytes, - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize fields, and Type=EFI_FV_FILETYPE_FFS_PAD), - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above), - 4 padding bytes. (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point immediately past EFI_FIRMWARE_VOLUME_HEADER.) The sizes of the firmware volumes don't change, only their internal usages grow by 48 bytes. I verified that the statements and calculations in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid. - The new data consume 0 bytes in PEIFV. This is because PEIFV has enough internal padding at the moment to accomodate the above structures without a growth in usage. In the future, firmware volumes can be identified by Name GUID (Fv(...) device path nodes), rather than memory location (MemoryMapped(...) device path nodes). This is supposed to improve stability for persistent device paths that refer to FFS files; for example, UEFI boot options. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Fix typos in commentsGiri P Mudusuru2016-07-084-9/+9
| | | | | | | | | | | - accessibla to accessible - exeuction to execution Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Re-add the Driver Health ManagerBruce Cran2016-06-286-0/+6
| | | | | | | | | | | | | | | The Driver Health HII menu is not an integral part of the MdeModulePkg BDS driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now we have to get the same functionality explicitly from DriverHealthManagerDxe. Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: set SMM stack size to 16KBLaszlo Ersek2016-06-063-0/+3
| | | | | | | | | | | | | | | | | | | | | | The default stack size (from UefiCpuPkg/UefiCpuPkg.dec) is 8KB, which proved too small (i.e., led to stack overflow) across commit range 98c2d9610506^..f85d3ce2efc2^, during certificate enrollment into "db". As the edk2 codebase progresses and OVMF keeps including features, the stack demand constantly fluctuates; double the SMM stack size for good measure. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1341733 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformBootManagerLib: Connect the Xen drivers before loading NvVarsGary Lin2016-06-022-2/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | When OVMF tried to load the file-based NvVars, it checked all the PCI instances and connected the drivers to the mass storage device. However, Xen registered its PCI device with a special class id (0xFF80), so ConnectRecursivelyIfPciMassStorage() couldn't recognize it and skipped the driver connecting for Xen PCI devices. In the end, the Xen block device wasn't initialized until EfiBootManagerConnectAll() was called, and it's already too late to load NvVars. This commit connects the Xen drivers in ConnectRecursivelyIfPciMassStorage() so that Xen can use the file-based NvVars. v3: * Introduce XenDetected() to cache the result of Xen detection instead of relying on PcdPciDisableBusEnumeration. v2: * Cosmetic changes Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: raise DXEFV size to 10 MBGary Lin2016-05-313-9/+9
| | | | | | | | | | | | | | | | | | | | | | | We reached the size limit again. Building OVMF with the following command $ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE and it ended up with GenFds.py... GenFv: ERROR 3000: Invalid : error 7000: Failed to generate FV the required fv image size 0x900450 exceeds the set fv image size 0x900000 Since the new UEFI features, such as HTTPS, are coming, we need a larger DEXFV eventually. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformBootManagerLib: keep the logo after connecting devicesLaszlo Ersek2016-05-271-5/+0
| | | | | | | | | | | | | OVMF (unlike ArmVirtPkg) has traditionally cleared the screen after connecting devices. This is not really necessary, and keeping the logo up while the progress bar is advancing at the bottom looks great. So don't clear the screen. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformBootManagerLib: bring back the progress barLaszlo Ersek2016-05-271-0/+17
| | | | | | | | | | | | | | | | | | OVMF's Platform BDS used to have a nice progress bar (with IntelFrameworkModulePkg BDS). We can restore it by copying the PlatformBootManagerWaitCallback() function verbatim from Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c It can be tested by passing the following option to QEMU (5 seconds): -boot menu=on,splash-time=5000 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformBootManagerLib: rebase boot logo display to BootLogoLibLaszlo Ersek2016-05-277-712/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the course of porting OvmfPkg to the MdeModulePkg BDS, commit 817fb3ac2a78 OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBoot open-coded the EnableQuietBoot() function (and its dependencies / friends) from IntelFrameworkModulePkg BDS. This code duplication can be avoided; the functionality is available from the following three libraries in MdeModulePkg: - BootLogoLib: provides the BootLogoEnableLogo() function. It does not provide the internal ConvertBmpToGopBlt() function -- that one is delegated to ImageDecoderLib (function DecodeImage()). - ImageDecoderLib: a general library that registers decoder plugins for specific image formats, and provides the generic DecodeImage() on top. - BmpImageDecoderLib: one of said decoder plugins, for handling BMP images (which is the format of our logo). In this patch, we revert 817fb3ac2a78, and atomically incorporate the above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42: Nt32Pkg: Use BootLogoLib for logo and progress bar drawing. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/SerializeVariablesLib: Relax check for the read-only variableGary Lin2016-05-261-0/+5
| | | | | | | | | | | | | | | | | | When OVMF tried to restore the variables from the file-based NvVars, it failed to set the read-only variable and aborted the restoration with this message: Variable Check ReadOnly variable fail Write Protected - 04B37FE8-F6AE-480B-BDD5-37D98C5E89AA:VarErrorFlag Since it's a read-only variable maintained by the firmware, it's pointless to restore the previous value, so the check can be relaxed to allow EFI_WRITE_PROTECTED returned from SetVariable. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/SerializeVariablesLib: convert line endings to uniform CRLFLaszlo Ersek2016-05-262-889/+889
| | | | | | | | | | | | | "SerializeVariablesLib.h" is pure LF, while "SerializeVariablesLib.c" is mixed (its only CRLF terminators are from commit e678f9db899ad). Convert them both with "unix2dos". "git show -b" produces no code hunks for this patch. Due to its simple and mechanic nature (and because it blocks the application of another patch), it's being committed without review. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSMLaszlo Ersek2016-05-258-0/+409
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLibLaszlo Ersek2016-05-257-4/+4
| | | | | | | | | | | | | | | This completes the transition to the new BDS. The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter listLaszlo Ersek2016-05-253-22/+11
| | | | | | | | | | | | | | | | With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no longer need the BootOptionList parameter in the SetBootOrderFromQemu() prototype. Update the library class header file (including the function's documentation), and adapt the library instance and the call sites. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove QemuBootOrderLib instanceLaszlo Ersek2016-05-254-2312/+0
| | | | | | | | | | | | This library instance is no longer referenced. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PlatformBdsLib instanceLaszlo Ersek2016-05-255-2178/+0
| | | | | | | | | | | | This library instance is no longer referenced. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove USE_OLD_BDS build fallback macroLaszlo Ersek2016-05-256-69/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reasons: - USE_OLD_BDS requires duplicating updates between OVMF's library instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples: d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 1da761664949 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 - The Xen community has embraced the new BDS. Examples: 14b2ebc30c8b OvmfPkg/PlatformBootManagerLib: Postpone the shell registration 49effaf26ec9 OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen - OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as NetworkPkg/HttpBootDxe now requires UefiBootManagerLib: 50a65824c74a NetworkPkg: Use UefiBootManagerLib API to create load option. We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is TRUE. - The new BDS has been working well; for example it's the only BDS available in ArmVirtPkg: 1946faa710e6 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in examplesLaszlo Ersek2016-05-251-2/+2
| | | | | | | | | | | | | | The "UNIXGCC Debug" section happens to name PlatformBdsLib and IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering those even as a fallback option. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: provide 10 * 4KB of PCI IO Port space on Q35Laszlo Ersek2016-05-171-0/+10
| | | | | | | | | | | | | | | | | | | | This can accommodate 10 bridges (including root bridges, PCIe upstream and downstream ports, etc -- see <https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c12> for more details). 10 is not a whole lot, but closer to the architectural limit of 15 than our current 4, so it can be considered a stop-gap solution until all guests manage to migrate to virtio-1.0, and no longer need PCI IO BARs behind PCIe downstream ports. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg/PlatformPei: set PCI IO port aperture dynamicallyLaszlo Ersek2016-05-175-16/+30
| | | | | | | | | | | | | | | | | | Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our PciHostBridgeLib instance.) Take special care to keep the GCD IO space map unchanged on all platforms OVMF runs on. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg: determine PMBA value dependent on host bridge device IDLaszlo Ersek2016-05-174-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei are modified together in order to keep VMs functional across a bisection: they all must agree on the PMBA value used. ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it gets linked into the debug agent, therefore the same restrictions apply to it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for powering off the virtual machine, thus the extra cost of a PCI config space read, compared to a PcdGet16(), should be negligible. This is the patch that moves the PMBA to IO port 0x0600 on Q35 in practice. The ResetSystemLib change is easiest to verify with the "reset -s" command in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF, PcAtChipsetPkg/KbcResetDxe). Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg: introduce ICH9_PMBASE_VALUELaszlo Ersek2016-05-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the ICH9 spec, PMBASE "provides 128 bytes of I/O space for ACPI, GPIO, and TCO logic. This is placed on a 128-byte boundary". On the Q35 machine type of QEMU, our current PMBASE setting of 0xB000 is the only thing that prevents us from lowering the base of the PCI IO port aperture from 0xC000. (The base must be aligned to 0x1000 due to PCI bridge requirements.) By moving our PMBASE to 0x0600 (moving the register block to 0x0600..0x067F inclusive), which is also what SeaBIOS uses on Q35, we will be able to lower the PCI IO port aperture base to 0x6000 (the next IO port under it being taken by the "vmport" device, at fixed 0x5658), while steering clear of other QEMU devices. On PIIX4, freeing up the 0x1000 IO ports at 0xB000 wouldn't help much, because the 0xA000 block right below it is occupied by unmovable devices (see <https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c19> for details). Doing this for Q35 only has two more benefits: - It won't interfere with Xen guests, - The Q35 machine type with the smallest version number is "pc-q35-2.4", which is guaranteed to have an ACPI generator. This matters because the ACPI tables (FACP, DSDT) have to reflect the PM base address that we program. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg: add and use industry standard macro PIIX4_PMBA_MASKLaszlo Ersek2016-05-174-3/+5
| | | | | | | | | | | | | | | | We already have the identical purpose (but different value) macro for ICH9, namely ICH9_PMBASE_MASK in "OvmfPkg/Include/IndustryStandard/Q35MchIch9.h". Also, stop bit-negating signed integer constants. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUELaszlo Ersek2016-05-1710-24/+14
| | | | | | | | | | | | | | | | | | | | | In the next patches, we'll differentiate the PMBA IO port address that we program on PIIX4 vs. Q35. Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However, because we need this value in BaseRomAcpiTimerLib too (which cannot access RAM and dynamic PCDs), it must remain a build time constant. We will introduce its Q35 counterpart later. As first step, replace the PCD with a new macro in "OvmfPlatforms.h"; Jordan prefers the latter to fixed PCDs in this instance. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg/AcpiTimerLib: don't use possibly unset PMBA register (PEI phase)Laszlo Ersek2016-05-171-2/+1
| | | | | | | | | | | | | We should store the right value to the PMBA (if the PMBA needs initialization) before setting mAcpiTimerIoAddr from the PMBA. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: f122712b42af3d63902c2c141e90d2c200df6790 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
* OvmfPkg/XenBusDxe: duplicate twice-iterated VA_LIST in XenStoreVSPrint()Zenith4322016-05-171-1/+4
| | | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: add spaces before macro invocation parentheses; clean up subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Postpone the shell registrationGary Lin2016-05-121-6/+7
| | | | | | | | | | | | | | | | | | | | | | We currently register the shell before creating the boot options for the block devices and the network devices, so the boot manager boots into the internal shell if the user doesn't specify the boot order. However, Xen doesn't support fw_cfg, so there is no way to change the boot order with the external command, and the firmware will always boot into the internal shell if the user doesn't interfere the boot process. This patch postpones the shell registration after MdeModulePkg/BDS creates all the boot options for the block and network devices, so that firmware will try to boot the block/network devices first. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353Laszlo Ersek2016-05-121-5/+5
| | | | | | | | | | | | | | | | | | | | | On the Q35 machine type of QEMU, there is no port multiplier connected to the on-board SATA controller. Therefore the AtaAtapiPassThru driver update for Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353> changes the middle number (the Port Multiplier Port Number) in the Sata() device path nodes from 0x0 to 0xFFFF. Adapt the translation from OpenFirmware in QemuBootOrderLib. (Note: QemuBootOrderLib is deprecated at this point (see USE_OLD_BDS in the DSC files), but until we remove it, it should be kept in sync with QemuNewBootOrderLib.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
* OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353Laszlo Ersek2016-05-121-5/+5
| | | | | | | | | | | | | | | | | On the Q35 machine type of QEMU, there is no port multiplier connected to the on-board SATA controller. Therefore the AtaAtapiPassThru driver update for Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353> changes the middle number (the Port Multiplier Port Number) in the Sata() device path nodes from 0x0 to 0xFFFF. Adapt the translation from OpenFirmware in QemuNewBootOrderLib. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
* OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over XenRuiyu Ni2016-05-114-1/+539
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com>
* OvmfPkg/PciHostBridgeLib: Change InitRootBridge prototypeRuiyu Ni2016-05-111-38/+93
| | | | | | | | | The patch re-factors the code without functionality impact. Next patch will add code to support OVMF above Xen. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PciHostBridgeLib: Set correct Base/Limit for absent resourceRuiyu Ni2016-05-111-3/+3
| | | | | | | | | In order to match the previous commit, Base must be strictly larger than Limit if some type of aperture is not available on a PCI root bridge. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Modify FDF/DSC files for RamDiskDxe's adding NFIT report featureHao Wu2016-05-106-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware Interface Table (NFIT). A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE in MdeModulePkg. To make the NFIT reporting feature working properly under OVMF, the patch will set the Pcd to TRUE in OVMF DSC files. Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device using ASL code which is put in a Secondary System Description Table (SSDT) according to the ACPI 6.1 spec. Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in OVMF FDF files. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
* OvmfPkg/OvmfPkgIa32X64.dsc: Move PcdShellFile to [PcdsFixedAtBuild.X64]Ruiyu Ni2016-05-041-1/+1
| | | | | | | | PcdShellFile is never used in the PEI phase. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use MdeModulePkg/BDSRuiyu Ni2016-05-046-12/+126
| | | | | | | | | | | | By default the new MdeModulePkg/BDS is used. If USE_OLD_BDS is defined to TRUE, IntelFrameworkModulePkg/BDS is used. Fixes: https://github.com/tianocore/edk2/issues/62 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Remove unused C structures definitionsRuiyu Ni2016-05-041-47/+0
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Fix gcc-4.8 Ia32 build failureRuiyu Ni2016-05-041-0/+2
| | | | | | | | | | | | | | | | The Width and Height assignment suppresses an invalid gcc-4.8 warning on Ia32. These warnings look unjustified to me. Namely, near the beginning of the function, there is a while(1) loop. In that loop, ConvertBmpToGopBlt() is called unconditionally. If the call fails, the rest of the loop body is not reached (where the Height and Width variables are used -- the compiler warns about their use in the switch statement). If the call succeeds, then the variables are set. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBootRuiyu Ni2016-05-043-0/+709
| | | | | | | | | | EnableQuietBoot and DisableQuietBoot are copied from IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c. Because these two functions are not in UefiBootManagerLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-23 16:33:28 +0000