summaryrefslogtreecommitdiff
path: root/OvmfPkg/Library/PlatformBdsLib
AgeCommit message (Collapse)Author
2016-12-26OvmfPkg: Remove unused PackageGuo Mang
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Guo Mang <mang.guo@intel.com>
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: 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-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-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-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-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-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-08-13Fix VS2013 build failure.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15795 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-31OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware pathPaolo Bonzini
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough to match a UEFI device path; a typical cases is a NIC that is assigned from the host to the guest. Add a catch-all case for PCI devices, and reuse it for NICs since it works well for those too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: QemuBootOrder: don't leak unreferenced boot optionsLaszlo Ersek
The Boot#### variables that have become unreferenced in the new BootOrder variable won't ever be automatically reused for booting. They are "unreachable" resources that take up room in the variable store. Make an effort to remove them. This should plug the leak which, given sufficient reboots, exhausts the variable store with stale Boot#### variables and renders the VM unbootable. Reported-by: Michael Chang <mchang@suse.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@15327 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: remove historic (now defunct) boot mode hackLaszlo Ersek
When PI can distinguish the "full config" boot mode from "assume no changes", then the following BDS logic is correct: if BootMode == BOOT_WITH_FULL_CONFIGURATION: // // connect all devices // create & append each default boot option that's missing // BdsLibConnectAll BdsLibEnumerateAllBootOption else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES: // // just stick with current BootOrder and the Boot#### variables // referenced by it // In theory, the first branch is intended to run infrequently, and the "assume no changes" branch should run most of the time. However, some platforms can't tell these two boot modes apart. The following substitute had been introduced: // // Technically, always assume "full config", but the BootMode HOB is // actually meaningless wrt. to "full config" or "assume no changes". // ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION); // // Key off the existence of BootOrder. Try to prepare an in-memory list // of boot options, based on BootOrder and the referenced Boot#### // variables. // Status = BdsLibBuildOptionFromVar() // // If that succeeded, we'll treat it as "assume no changes". If it // failed (*only* if it failed), we'll build default boot options, // calling it "full config": // if EFI_ERROR(Status): BdsLibConnectAll() BdsLibEnumerateAllBootOption(BootOptionList) What we have now in OVMF is a mixture of the hack, and the behavior that's theoretically correct for "full config": - We assert "full config" -- this is OK. - We call "connect all" and "enumerate all" deliberately -- this is OK too. It matches "full config" which we assert. - However, we also have the hack in place, which had been meant as an alternative. In order to clean this up, we either need to restore the hack to its original form (ie. comment out the unconditional calls again), or we ought to remove the hack altogether. The unconditional "connect all" + "enumerate all" calls are the correct approach for OVMF, because we want, in fact, to start with "full config". The QEMU boot order specification and the set of emulated devices might change "out of band", which excludes "assume no changes". In other words, removing the hack corresponds to the "real production" case that the comment hints at. Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must preserve the BdsLibBuildOptionFromVar() function call, in order to refresh the in-memory list with the new boot priorities. (The last step of BdsLibEnumerateAllBootOption() is such a call 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15326 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-09OvmfPkg: QemuBootOrder: initialize IsFinal variable to make MSVC happyMauro Faccenda
The BOOLEAN IsFinal variable initialization isn't properly seen by MSVC. To make it compile OVMF the variable needs to be initialized. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mauro Faccenda <faccenda@gmail.com> 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@15214 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-29OvmfPkg: QemuBootOrder: handle QEMU's "-boot strict=on" optionLaszlo Ersek
When this option is passed to qemu, it appends the word HALT to the "bootorder" fw_cfg file, as last entry. For example, /pci@i0cf8/ethernet@3/ethernet-phy@0 /pci@i0cf8/scsi@4/disk@0,0 HALT The option's purpose is to prevent SeaBIOS from booting from devices that have not been specified explicitly (with bootindex=N device properties nor -boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from default locations (after boot fails from all of the listed locations). The HALT string currently causes OVMF to reject the entire "bootorder" fw_cfg contents, with "parse error". This is not good, because since a recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped working for libvirt users. OVMF's SetBootOrderFromQemu() function actually implements the idea behind "-boot strict=on": it drops all boot options not in the fw_cfg list. (*) Therefore, let's recognize HALT, and just do what we've been doing all along. (*) Except the UEFI shell, according to the survival policy in BootOrderComplete(), but the memory mapped UEFI shell is not expressible via fw_cfg anyway, and its preservation has been requested on edk2-devel. Hence it's a good boot option to keep in any case. 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@15197 6f19259b-4bc3-4df7-8a09-765794883524
2013-11-12OvmfPkg/BdsPlatform: don't restore NvVars from disk when flash is presentLaszlo Ersek
QemuFlashFvbServicesRuntimeDxe provides actual persistent storage for non-volatile variables. When it is active, any on-disk NvVars file counts as a stale source of variables -- hence don't load these files in BDS. This also allows Secure Boot settings (eg. enrolled keys) to survive cold VM reboots. 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@14844 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: keep some boot options that have not been selectedLaszlo Ersek
Some of the active boot options that have not been selected over fw_cfg should be preserved at the end of the boot order. For now we're adding back everything that starts with neither PciRoot() nor HD(). This includes the UEFI shell, memory-mapped from the firmware image. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: mark UEFI boot options selected by fw_cfgLaszlo Ersek
This will allow us to identify those UEFI boot options (while keeping their relative order) that have *not* been selected by fw_cfg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14667 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: collect active UEFI boot options in advanceLaszlo Ersek
In preparation for the next patch, collect active UEFI boot options in advance into a new array. Rebase the current inner loop (the matching loop) to this array. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> [jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14666 6f19259b-4bc3-4df7-8a09-765794883524
2013-09-13OvmfPkg: QemuBootOrder: expand relative device paths in UEFI boot optionsLaszlo Ersek
The prefix matching logic in Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options to specify full (absolute) device paths. However, partial (relative) device paths starting with a HD() node are valid for booting. By not recognizing them, QemuBootOrder.c misses (and deletes) valid boot options that would otherwise match the user's preference. Just like BdsLibBootViaBootOption() expands such paths with the BdsExpandPartitionPartialDevicePathToFull() function for booting, do the same in QemuBootOrder.c for prefix matching. This moves the very first call to BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The following call tree explains it: BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c] BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c] This should be fine, for two reasons: - the new, earlier call is still under BdsEntry(), - BdsExpandPartitionPartialDevicePathToFull() expects to be called repeatedly, even with the same set of HD() device paths. This function implements its own caching for device paths, likely for performance reasons. That fits this patch well because whatever device paths we expand under PlatformBdsPolicyBehavior() can be quickly looked up in BdsBootDeviceSelect(), so no work (ie. BdsLibConnectAllDriversToAllControllers()) should be wasted. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
2013-07-26Update all the code to consume the ConvertDevicePathToText, ↵Ruiyu Ni
ConvertDevicePathNodeToText, ConvertTextToDevicePath and ConvertTextToDeviceNode APIs in DevicePathLib. Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14505 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-15OvmfPkg: QemuBootOrder: recognize Ethernet OFW device pathsjljusten
Tested with the e1000, ne2k_pci, pcnet, rtl8139, and virtio iPXE UEFI oprom drivers distributed with qemu-1.5.0-rc1. Also tested with Intel's e1000 driver. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14367 6f19259b-4bc3-4df7-8a09-765794883524
2013-01-16OvmfPkg: LoadLinuxLib: Zero kernel parameters instead of passing garbagejljusten
We're supposed to zero everything in the kernel bootparams that we don't explicitly initialise, other than the setup_header from 0x1f1 onwards for a precisely defined length, which is copied from the bzImage. We're *not* supposed to just pass the garbage that we happened to find in the bzImage file surrounding the setup_header. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14052 6f19259b-4bc3-4df7-8a09-765794883524
2012-11-02OvmfPkg: Add support for qemu's -kernel parameterjljusten
If QEMU's -kernel parameter was used, then download the kernel from the FwCfg interface, and launch it. (See -kernel, -initrd, -append) The application uses the LoadLinuxLib to boot the kernel image. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13923 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-18OvmfPkg: QemuBootOrder: recognize virtio-scsi devicesjljusten
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13868 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-08OvmfPkg: QemuBootOrder: recognize virtio-blk OFW device pathsjljusten
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13801 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-08OvmfPkg: QemuBootOrder: lower the required number of OFW nodes to 2jljusten
2 nodes in an OpenFirmware device path are sufficient for the generic check at the beginning of TranslateOfwNodes(). The driver specific branches check for the necessary nodes individually. The number of nodes saved for examination is unchanged. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13800 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-08OvmfPkg: QemuBootOrder: whitespace fixjljusten
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13799 6f19259b-4bc3-4df7-8a09-765794883524
2012-10-03VS2005 and DDK3790 tool chain tags require typecasts to BOOLEAN to compile.mdkinney
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13779 6f19259b-4bc3-4df7-8a09-765794883524
2012-08-27OvmfPkg: get boot order from QEMUjljusten
Set the boot order based on configuration retrieved from QEMU. Attempt to retrieve the "bootorder" fw_cfg file from QEMU. Translate the OpenFirmware device paths therein to UEFI device path fragments. Match the translated fragments against the enumerated BootOptionList, and rewrite the BootOrder NvVar so that it corresponds to the order described in fw_cfg. The user is expected to configure working boot options first. Tested via virt-manager's boot order widget. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13683 6f19259b-4bc3-4df7-8a09-765794883524
2012-08-13OvmfPkg: have PlatformBdsLib::PciInitialization conform to the _PRSjljusten
Also set some INTLN values, informatively. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13627 6f19259b-4bc3-4df7-8a09-765794883524
2012-08-13OvmfPkg: PlatformBdsLib: the balloon device (RAM Memory) is in slot 5jljusten
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13626 6f19259b-4bc3-4df7-8a09-765794883524
2012-07-10OvmfPkg BDS: Remove support for loading vgabios-cirrus.bin from 0xc0000jljusten
Older QEMU versions would load vgabios-cirrus.bin at 0xc0000 in system RAM. We would then find this ROM, and try to run it, since it would be our QEMU Video driver. Now, the QEMU Video driver is just merged into the main OVMF firmware image, so this support is unused. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13522 6f19259b-4bc3-4df7-8a09-765794883524
2012-05-04OvmfPkg PlatformBdsLib: Set SCI_EN bit of PMCNTRLjljusten
If the bit is not set, then the only method ACPI defines for setting it is to use the SMI SCI enable code path. Since OVMF does not support SMM, we must enable the bit during boot. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Bei Guan <gbtju85@gmail.com> Reviewed-by: Bei Guan <gbtju85@gmail.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13278 6f19259b-4bc3-4df7-8a09-765794883524
2012-03-14Improve robustness when scanning PCI Option ROM.rsun3
Signed-off-by: rsun3 Reviewed-by: geekboy15a git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13095 6f19259b-4bc3-4df7-8a09-765794883524
2010-10-13OVMF BDS: Don't call BdsLibSaveMemoryTypeInformationjljusten
This call can cause a reset, and is most critical for ACPI S3/S4 resume situations. OVMF does not support S3/S4. OVMF does not have true non-volatile variable support, so this call could cause a continuous reset situation in certain scenarios. (The BdsLibSaveMemoryTypeInformation may set an non-volatile variable, and then reset with the assumption that the variable will still exist during the next boot.) Additionally, some version of QEMU appear to hang when the port 64 reset is initiated. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10927 6f19259b-4bc3-4df7-8a09-765794883524
2010-07-04Update OVMF BDS Library to call GenericBdsLib function to save ↵mdkinney
gEfiMemoryTypeInformation git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10627 6f19259b-4bc3-4df7-8a09-765794883524
2010-04-28Update the copyright notice formathhtian
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10439 6f19259b-4bc3-4df7-8a09-765794883524
2010-04-06Update the modules with the different module GUID to avoid the different ↵lgao4
modules with the same module GUID. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10344 6f19259b-4bc3-4df7-8a09-765794883524
2010-02-25Clean up EFI_SPECIFICATION_VERSION and PI_SPECIFICATION_VERSION.klu2
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10074 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-20 09:51:18 +0000