summaryrefslogtreecommitdiff
path: root/OvmfPkg/Library
AgeCommit message (Collapse)Author
2015-08-06OvmfPkg: PlatformDebugLibIoPort: fix AsciiSPrint() format stringLaszlo Ersek
The LineNumber parameter of the DebugAssert() function has type UINTN. DebugAssert() passes it to AsciiSPrint() with the %d conversion specifier at the moment, but %d would require an INT32 argument. Fix this by casting LineNumber to UINT64, also employing the matching decimal conversion specifier, %Lu. (Another possibility would be to cast LineNumber to INT32, but a UINTN->INT32 cast is not value preserving, generally speaking.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Scott Duplichan <scott@notabs.org> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18173 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-28OvmfPkg: fix conversion specifiers in DEBUG format stringsLaszlo Ersek
Cc: Scott Duplichan <scott@notabs.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18095 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-26OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLibLaszlo Ersek
Currently we have the following call chain in OVMF: PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // signals End-of-Dxe // OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 1. saves S3 state // SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 2. saves INFO opcode in S3 boot script // 3. installs DxeSmmReadyToLockProtocol // The bottom of this call chain was introduced in git commit 5a217a06 (SVN r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That patch was necessary because there was no other way, due to GenericBdsLib calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary steps in the right order: - save S3 system information, - save a final (well, only) boot script opcode, - signal DxeSmmReadyToLock, closing the boot script, and locking down LockBox and SMM. The GenericBdsLib bug has been fixed in the previous patch -- the call in BdsLibBootViaBootOption() has been eliminated. Therefore, hoist the SaveS3BootScript() code, and call, from OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib: PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // signals End-of-Dxe // OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c] // // 1. saves S3 state // <--- SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] // // 2. saves INFO opcode in S3 boot script // 3. installs DxeSmmReadyToLockProtocol // The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS, not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without upsetting the relative order of the steps. 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: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18037 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-26OvmfPkg: PlatformBdsLib: signal End-of-Dxe event groupLaszlo Ersek
(Paraphrasing git commit 9cd7d3c5 / SVN r17713:) Currently, OvmfPkg fails to signal the End-of-Dxe event group when entering the BDS phase, which results in some loss of functionality, eg. variable reclaim in the variable driver, and the memory region splitting in the DXE core that belongs to the properties table feature specified in UEFI-2.5. As discussed on the edk2-devel mailing list here: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109 it is up to the platform BDS to signal End-of-Dxe, since there may be platform specific ordering constraints with respect to the signalling of the event that are difficult to honor at the generic level. (OvmfPkg specifics:) (1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration completes. According to the previous patch, that would trigger OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of action happened: - PCI enumeration completes - ACPI tables are installed by OvmfPkg/AcpiPlatformDxe - the FACS table becomes available Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table is available, we must delay the End-of-Dxe signal until after PCI enumeration completes (ie. root bridges are connected). (2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]. After the patch, we enter S3Ready() earlier than that, by signaling End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of this new call is correct as well, and the original call (that now becomes the chronologically second call) becomes a no-op: S3Ready() is protected against 2nd and later entries. 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: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18035 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: QemuBootOrderLib: recognize extra PCI root busesLaszlo Ersek
The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for a device that is plugged into the main PCI root bus, is: /pci@i0cf8/... Whereas the same device plugged into the N'th extra root bus results in: /pci@i0cf8,N/pci-bridge@0/... (N is in hex.) Extend TranslatePciOfwNodes() so that it not assume a single PCI root; instead it parse the extra root bus serial number if present, and resolve it in the translation to the UEFI devpath fragment. Note that the "pci-bridge@0" node is a characteristic of QEMU's PXB device. It reflects the actual emulated PCI hierarchy. We don't parse it specifically in this patch, because it is automatically handled by the bridge sequence translator added recently in SVN rev 17385 (git commit feca17fa4b) -- "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges". The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW device paths that we wish to recognize under this new scheme comprise 5 nodes. The initial "extra root bus" OFW fragment, visible at the top, takes up 2 nodes, after which the longest device-specific patterns (IDE disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each. 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: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17965 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: QemuBootOrderLib: introduce ExtraRootBusMapLaszlo Ersek
SeaBIOS requires the OpenFirmware device paths exported in the "bootorder" fw-cfg file to refer to extra (PXB) root buses by their relative positions (in increasing bus number order) rather than by actual bus numbers. However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID) device path nodes for extra PCI root buses with UID=bus_nr, not position. (These ACPI devpath UID values must, and do, match the UID values exposed in QEMU's ACPI payload, generated for PXB root buses.) Therefore the boot order matching logic will have to map extra root bus positions to bus numbers. Add a small group of utility functions to help with that. 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: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17964 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: connect all PCI root busesLaszlo Ersek
Currently we only connect the root bus with bus number 0, by device path. Soon we will possibly have several extra root buses, so connect all root buses up-front (bus number zero and otherwise), by protocol GUID. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17954 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: refine PCI host bridge assertionLaszlo Ersek
The ASSERT() in SetPciIntLine() assumes that Device 0 on "the" root bus corresponds to the PCI host bridge (00:00). This used to be true, but because we're going to have extra root buses (with nonzero bus numbers), soon this assumption may no longer hold. Check for the zero root bus number explicitly. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Regression-tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17953 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-14OvmfPkg: PlatformBdsLib: debug log interrupt line assignmentsLaszlo Ersek
These messages are helpful for comparing the assignments made by OVMF against those made by SeaBIOS. To SeaBIOS a small debug patch like the following can be applied: > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c > index ac39d23..9e61c22 100644 > --- a/src/fw/pciinit.c > +++ b/src/fw/pciinit.c > @@ -308,8 +308,12 @@ static void pci_bios_init_device(struct pci_device *pci) > > /* map the interrupt */ > int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN); > - if (pin != 0) > - pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin)); > + if (pin != 0) { > + int irqline = pci_slot_get_irq(pci, pin); > + > + pci_config_writeb(bdf, PCI_INTERRUPT_LINE, irqline); > + dprintf(1, "assigned irq line %d\n", irqline); > + } > > pci_init_device(pci_device_tbl, pci, NULL); > Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17952 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-10OvmfPkg: QemuFwCfgLib: avoid "variable set but not used" warning from GCCBill Paul
The FileReserved variable in QemuFwCfgFindFile() is only used to skip over the reserved field in file headers, which causes newer versions of GCC to flag it with a "variable set but not used" warning (which is normally not visible since as of right now these warnings are supressed). It's true that the value read into FileReserved is never used, but this is intentional. This patch adds a do-nothing reference to silence the warning. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bill Paul <wpaul@windriver.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17920 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: extract some bits and port offsets common to Q35 and I440FXLaszlo Ersek
The PMBA_RTE and ACPI_TIMER_OFFSET macros apply equally to both boards, plus they are triplicated between the various AcpiTimerLib instances. Define them centrally in "OvmfPlatforms.h". Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17436 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use the macros in "I440FxPiix4.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17435 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the macros in "Q35MchIch9.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17434 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-08OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridgesLaszlo Ersek
When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends to place some devices behind PCI bridges. This is then reflected in the "bootorder" fw_cfg file. For example: /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0 /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/disk@0,0 As yet QemuBootOrderLib doesn't support such OFW device paths. Add code that translates a sequence of pci-bridge nodes. In practice libvirt seems to insert two such nodes (*), hence increment EXAMINED_OFW_NODES with the same number. (* Background, paraphrasing Laine Stump's words: When the machine type is Q35, we create a dmi-to-pci bridge coming off of the pcie root controller, and a pci-to-pci bridge coming off of that, then attach most devices to the pci-to-pci bridge. This is done because you can't hotplug into pcie-root, can't (or at least shouldn't) plug a pci-to-pci bridge into pcie-root (so the next one has to be dmi-to-pci-bridge), and can't hotplug into dmi-to-pci-bridge (so you need to have a pci-to-pci bridge).) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17385 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-06OvmfPkg: Use the new PCDs defined in MdePkg and MdeModulePkg.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17318 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-27OvmfPkg: XenConsoleSerialPortLib: deal with output overflowArd Biesheuvel
It is the responsibility of the SerialPortLib implementation to deal with flow control if the underlying medium cannot keep up with the inflow of data. So in our SerialPortWrite () function, we should spin as long as we need to in order to deliver all the data instead of giving up and returning a smaller value than the number of bytes we were given. Also, remove the 'if (Sent > 0)' condition on the signalling of the event channel: if the buffer is full and we haven't been able to add any more data, it makes perfect sense to signal the event channel again, even if we have done so before when we did write the data. Also, this patch brings the implementation of XenSerialPortLib in sync with the library class documentation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: replace DebugLib dependency with open-coded ASSERT()] git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17079 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26OvmfPkg: Q35: Use correct ACPI PM control register:bitGabriel Somlo
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM IO space given in the PMBA register (offset 0x40) is enabled. PMBA must be configured *before* setting this bit. On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset 0x44, also with a default value of 0x00. Currently, OVMF hangs when Q35 reboots, because while PMBA is reset by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4) is not reset, since it has a completely different meaning on LPC. As such, the power management initialization logic in OVMF finds the "PMIOSE" bit enabled after a reboot and decides to skip setting PMBA. This causes the ACPI timer tick routine to read a constant value from the wrong register, which in turn causes the ACPI delay loop to hang indefinitely. This patch modifies the Base[Rom]AcpiTimerLib constructors and the PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead of PMREGMISC:PMIOSE when running on Q35. Reported-by: Reza Jelveh <reza.jelveh@tuhh.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: replace strict XenHypercallLib construction with explicit queryLaszlo Ersek
XenHypercallLib has two clients at the moment: XenBusDxe and XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86 platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib instance built into it fails to initialize, which triggers an ASSERT() in auto-generated code. Instead, let's call XenHypercallIsAvailable() in the driver's entry point, and exit cleanly when the driver is started on a non-Xen platform. Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't proceed if Xen is not available. In practice this check should never fail, because XenConsoleSerialPortLib is only used on ARM, and ArmXenHypercallLib is always available; but nonetheless we should be pedantic. Reported-by: Gabriel L. Somlo <gsomlo@gmail.com> Suggested-by: Jordan Justen <jordan.l.justen@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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17001 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()Laszlo Ersek
Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: Jordan Justen <jordan.l.justen@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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64Laszlo Ersek
In the next patch we'll add a simple query function to the XenHypercallLib library class that is supposed to be called by initialization code in modules. Among those, in constructors of dependent libraries too. Library construction ordering is ensured only between libraries with constructors, plus we shouldn't allow a dependent library with a constructor to call into any XenHypercallLib instances (the simple query function) before XenHypercallLib is constructed itself. For this reason, introduce an (empty) constructor for ARM & AARCH64 too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16999 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib namesLaszlo Ersek
Perform the following renames in order to stick with edk2 tradition more closely: XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib XenHypercallIntel -> X86XenHypercall In addition, we unify the INF files. This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to keep both bisectable (client code shouldn't break). Suggested-by: Jordan Justen <jordan.l.justen@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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16998 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel
This adds a XenIoMmioLib declaration and implementation that can be invoked to install the XENIO_PROTOCOL and a corresponding grant table address on a EFI handle. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: add Xen PV console SerialPortLib driverArd Biesheuvel
This implements a SerialPortLib instance that wires up to the PV console ring used by domU guests. Also imports the required upstream Xen io/console.h header. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16976 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: implement XenHypercallLib for ARMArd Biesheuvel
This patch adds an implementation of XenHypercallLib for both AArch64 and AArch32 execution modes on ARM systems. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16974 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel
This moves all of the Xen hypercall code that was private to XenBusDxe to a new library class XenHypercallLib. This will allow us to reimplement it for ARM, and to export the Xen hypercall functionality to other parts of the code, such as a Xen console SerialPortLib driver. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernelJordan Justen
Before we launch the QEMU kernel, we should signal the ReadyToBoot event. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16878 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-06OvmfPkg: Update PlatformBaseDebugLibIoPort libraryLiming Gao
Implement new API DebugPrintLevelEnabled() to base on PCD PcdFixedDebugPrintErrorLevel. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16797 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: PlatformBdsLib: get front page timeout from QEMULaszlo Ersek
Put QemuBootOrderLib's GetFrontPageTimeoutFromQemu() to use, so that OVMF's Platform BDS policy can consume QEMU's command line option -boot menu=on,splash-time=N RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16611 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"Laszlo Ersek
The QEMU command line option -boot menu=on is meant to have the guest firmware wait for a firmware-specific interval for the user to enter the boot menu. During the wait, the user can opt to enter the boot menu, or interrupt the wait and proceed to booting at once. If the wait interval elapses, the firmware should boot as it normally would. The QEMU command line option -boot menu=on,splash-time=N means the same, except the firmware should wait for cca. N milliseconds instead of a firmware-specific interval. We can approximate this behavior quite well for edk2's virtual platforms because the Intel BDS front page already supports a progress bar, with semantics similar to the above. Let's distill the fw_cfg bits underlying "-boot menu=on,splash-time=N" for the BDS policies, in the form of a timeout value they can pass to Intel's PlatformBdsEnterFrontPage(). If the boot menu is not requested, we return "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which is what the virtual platforms use right now. If the boot menu is requested without specifying the timeout, we return the same PCD, unless it would cause us to skip the boot menu at once. In the latter case, we return 3 seconds (as an approximation of the 2500 ms SeaBIOS default.) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware device paths: virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0 virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3 virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0 The new translation can be enabled with the "PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if the "survival policy" covers unselected boot options that start with the virtio-mmio VenHw() node. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: widen ParseUnitAddressHexList() to UINT64Laszlo Ersek
The OpenFirmware device path nodes that QEMU generates for virtio-mmio transports contain 64-bit hexadecimal values (16 nibbles) -- the base addresses of the register blocks. In order to parse them soon, ParseUnitAddressHexList() must parse UINT64 values. Call sites need to be adapted, as expected. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16574 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like" OFW device path fragments, let's turn the currently exclusive "PCI-like" translation into "just one" of the possible translations. - Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is tightly coupled to "PCI-like" translations. - Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro is specific to TranslatePciOfwNodes(). - Introduce a new wrapper function under the original TranslateOfwNodes() name. This function is supposed to try translations in some order until a specific translation returns a status different from RETURN_UNSUPPORTED. - Introduce a new Feature PCD that controls whether PCI translation is attempted at all. - The boot option "survival policy" in BootOrderComplete() must take into account if the user was able to select PCI-like boot options. If the user had no such possibility (because the Feature PCD was off for PCI-like translation), then we ought to keep any such unselected boot options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek
and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-17OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setupGabriel Somlo
Remove hard-coded list of PCI devices for which the Interrupt Line register is initialized. Instead, provide a "visitor" function to initialize the register only for present and applicable PCI devices. At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c, functions *_pci_slot_get_irq() and "map the interrupt" block from pci_bios_init_device()). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16398 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initializationGabriel Somlo
Merge PciInitialization() and AcpiInitialization() into a single function, PciAcpiInitialization(), and use a PCD set during PEI to detect the underlying platform type (PIIX4 or Q35/MCH) and therefore the addresses of the registers to be initialized. Add LNK[A-H] routing target initialization for the Q35 platform. Additionally, initialize PCI_INTERRUPT_LINE registers for the typical set of PCI devices included by QEMU with the Q35 machine type. The corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is cleaned up and the list of PIIX4 PCI devices updated to the list typically included with QEMU. NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE is hard-coded, and, depending on how QEMU devices are configured on the command line, may miss some devices, or (harmlessly) attempt to initialize devices which are not present in the system. A subsequent patch will replace this hard-coded list with a mechanism to correctly initialize PCI_INTERRUPT_LINE for applicable present PCI devices only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instanceGabriel Somlo
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against a valid, non-asserting version of PcdLib, then switch them over to using the "Dxe" instance of AcpiTimerLib (instead of the "Base" version). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIMGabriel Somlo
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may utilize global variables, use the "Base" AcpiTimerLib instance (instead of BaseRom) to take advantage of the improved efficiency of storing the timer register IO address in a global variable. This leaves only SEC using the BaseRomAcpiTimerLib instance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instancesGabriel Somlo
Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop custom boot timeout, revert to IntelFrameworkModulePkg'sLaszlo Ersek
PlatformBdsEnterFrontPage() already implements a keypress wait (for entering the setup utility at boot) with a nice progress bar, only OVMF has not been using it. Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s builtin wait has the following benefits: - It simplifies OVMF's BDS code. - Because now we call PlatformBdsEnterFrontPage() unconditionally, it actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit of the "OsIndications" variable, improving compliance with the UEFI specification. References: - https://bugzilla.redhat.com/show_bug.cgi?id=1153927 - http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487 - The progress bar looks nice. (And it keeps the earlier behavior intact, when the user presses a key on the TianoCore splash screen.) In any case, we set the timeout to 0 (which doesn't show the progress bar and proceeds to the boot options immediately) in order to keep the boot time down. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16310 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop superfluous "connect first boot option" logicLaszlo Ersek
This is again obviated by our earlier BdsLibConnectAll() call. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16309 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: optimize second argument in PlatformBdsEnterFrontPage() callLaszlo Ersek
The second parameter of said function is "ConnectAllHappened", and if set to TRUE, the function sets "gConnectAllHappened" to TRUE. This global variable in turn controls whether Intel BDS code *itself* calls BdsLibConnectAllDriversToAllControllers() in various places -- if the indicator is TRUE, then the "connect all" is assumed to have been performed, and Intel BDS doesn't do it itself. OVMF should pass TRUE as "ConnectAllHappened", because a few lines before our call to PlatformBdsEnterFrontPage(), we already connect everything with BdsLibConnectAll(), which includes the effects of BdsLibConnectAllDriversToAllControllers(): PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] BdsLibConnectAll() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c] BdsLibConnectAllDriversToAllControllers() PlatformBdsEnterFrontPage() [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16308 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: don't overwrite the BDS Front Page timeoutLaszlo Ersek
The PlatformBdsEnterFrontPage() function's first parameter, "TimeoutDefault", determines the behavior of the setup utility: - If (TimeoutDefault == 0), then the usual boot order is to be acted upon immediately. - If (TimeoutDefault == 0xFFFF), then the setup utility is entered unconditionally. - If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the PlatformBdsEnterFrontPage() function displays a progress bar, waiting for TimeoutDefault seconds. If the user presses a key, then the setup utility is entered, otherwise the normal boot option processing takes place. The TimeoutDefault parameter is supposed to be set from gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut which has the following (matching) documentation in "IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec": The number of seconds that the firmware will wait before initiating the original default boot selection. A value of 0 indicates that the default boot selection is to be initiated immediately on boot. The value of 0xFFFF then firmware will wait for user input before booting. OVMF does this actually -- see the Timeout variable in PlatformBdsPolicyBehavior() -- but right before calling PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF. This has been acceptable until now, because OVMF implements its own "wait for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(), completely avoiding the progress bar mentioned above. OVMF only calls PlatformBdsEnterFrontPage() when the user presses a key during its own "splash screen wait", and *then* it indeed makes sense to enter the setup utility unconditionally. However, even that way, the Timeout = 0xffff; assignment is superfluous, because 0xFFFF is already the default value of PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg doesn't override it in its DSC files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16307 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop useless return statementLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16306 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: remove dead call to PlatformBdsEnterFrontPage()Laszlo Ersek
This call has been dead since the conception of OvmfPkg (git commit 49ba9447 / SVN r8398), and only confuses readers -- let's remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16305 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg QemuFwCfgLib: Convert X64/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/IoLibExAsm.asm to X64/IoLibExAsm.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16290 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg QemuFwCfgLib: Convert Ia32/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/IoLibExAsm.asm to Ia32/IoLibExAsm.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16289 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert X64/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/JumpToKernel.asm to X64/JumpToKernel.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16288 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert Ia32/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/JumpToKernel.asm to Ia32/JumpToKernel.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16287 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-25OvmfPkg: Fix VS2005 build warningsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16171 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-09OvmfPkg: AcpiTimerLib: Access power mgmt regs based on host bridge typeGabriel Somlo
Pick the appropriate bus:dev.fn for accessing ACPI power management registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the device ID of the host bridge (assumed always present at 00:00.0). With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16066 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 05:18:13 +0000