OvmfPkg: enable PIIX4 IO space in the PEI phase

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

0 files changed, 0 insertions, 0 deletions