I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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@13722 6f19259b-4bc3-4df7-8a09-765794883524
The Index Register Base Address bitfield is selected by the binary mask
00000000 00000000 11111111 11000000, 0xFFC0; fix the typo.
Reported-by: Gleb Natapov <gleb@redhat.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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13720 6f19259b-4bc3-4df7-8a09-765794883524
Including the range of [0xFC000000, 0xFD000000) for PCI MMIO
allocation created a conflict for Xen's HVM loader.
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@13682 6f19259b-4bc3-4df7-8a09-765794883524
Fix IO-APIC range size.
Add HPET.
Take LAPIC base from PCD and fix range size.
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@13572 6f19259b-4bc3-4df7-8a09-765794883524
QEMU doesn't support MTRR emulation in some cases,
and therefore the MtrrLib calls may return an error.
In that case, we should silently ignore the error.
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12618 6f19259b-4bc3-4df7-8a09-765794883524
* Make PlatformPei aware of Xen
* Fix assigned PIO and MMIO ranges to be compatible with Xen
* Reserve Xen HVM address range
* Publish XenInfo HOB
* Don't program PIIX4 PMBA for Xen
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Reviewed-by: gavinguan
Signed-off-by: jljusten
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12091 6f19259b-4bc3-4df7-8a09-765794883524
When building in release mode on OVMF, the ASSERT_EFI_ERROR
macro is empty. So, to set the BootMode, in a release build,
it must be outside of ASSERT_EFI_ERROR.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11413 6f19259b-4bc3-4df7-8a09-765794883524
The contents of CMOS on boot can describe some aspects of
the system configuration. For example, the size of memory
available to qemu/kvm.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11264 6f19259b-4bc3-4df7-8a09-765794883524
* Only SEC is uncompressed now
* The MAIN FV with PEI & DXE can easily shrink and grow as needed
* The final output will now be OVMF.Fv rather than OVMF.fd
* The final output size will be a multiple of 64kb
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9672 6f19259b-4bc3-4df7-8a09-765794883524
OVMF utilizes EmuVariableFvbRuntimeDxe to provide an emulated
variable firmware volume block device for non-volatile variables.
This allows the VariableRuntimeDxe and FaultTolerantWriteDxe
to function without a real non-volatile backing store.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9317 6f19259b-4bc3-4df7-8a09-765794883524
Make use of EMU Variable driver's PcdEmuVariableNvStoreReserved to allow
NV variables to persist a VM system reset. The contents of the NV variables
will still be lost when the VM is shut down, but they appear to persist
when the efi shell reset command is run. (Tested with QEMU 0.10.0.)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9241 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
vanjeff
gikidy
mdkinney
hhtian
lgao4