tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

ArmVirtualizationPkg/PciHostBridgeDxe: get MMIO BARs from our own aperture 

This is our MMIO space map:

> GCD:AddMemorySpace(Base=0000000010000000,Length=000000002EFF0000)
>   GcdMemoryType   = MMIO
>   Capabilities    = 0000000000000001
>   Status = Success
> GCDMemType Range                             Capabilities     Attributes
> ========== ================================= ================ ================
> NonExist   0000000000000000-0000000003FFFFFF 0000000000000000 0000000000000000
> MMIO       0000000004000000-0000000007FFFFFF C000000000000001 8000000000000001

NorFlashDxe adds this, but does not allocate it.

> NonExist   0000000008000000-000000000900FFFF 0000000000000000 0000000000000000
> MMIO       0000000009010000-0000000009010FFF C000000000000001 8000000000000001

Added by RealTimeClockRuntimeDxe, but also not allocated.

> NonExist   0000000009011000-000000000FFFFFFF 0000000000000000 0000000000000000
> MMIO       0000000010000000-000000003EFEFFFF C000000000000001 0000000000000000

Added by ourselves.

> NonExist   000000003EFF0000-000000003FFFFFFF 0000000000000000 0000000000000000
> SystemMem  0000000040000000-00000000BFFFFFFF 800000000000000F 0000000000000008*
> NonExist   00000000C0000000-0000FFFFFFFFFFFF 0000000000000000 0000000000000000

In the EfiPciHostBridgeAllocateResources phase, we allocate memory BARs
bottom up, from whichever MMIO range comes first and has room left.
Unfortunately, this places memory BARs into MMIO ranges that belong to
other devices. (Arguably, their respective drivers should not just add,
but immediately allocate those ranges as well.)

(

  This problem is not seen in OVMF / PcAtChipsetPkg, because there we
  allocate bottom-up from the range

    [max(2GB, top-of-low-RAM), 0xFC000000).

  (See the MMIO resource descriptor HOB created in MemMapInitialization()
  [OvmfPkg/PlatformPei/Platform.c].)

  That MMIO range fits in the static [2GB, 4GB) aperture given in
  "mResAperture" in PcAtChipsetPkg/PciHostBridgeDxe; plus other MMIO
  ranges (IO-APIC, HPET, LAPIC, flash chip) are higher than 0xFC000000.
  Hence the bottom-up BAR allocation in OvmfPkg always finds the right
  MMIO range first.

)

In ArmVirtualizationPkg/PciHostBridgeDxe we can solve the problem by
working our way downwards from the top of our own aperture.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16906 6f19259b-4bc3-4df7-8a09-765794883524
This commit is contained in:
Laszlo Ersek 2015-02-23 16:03:51 +00:00 committed by lersek
parent ef8dba7da3
commit b9a44dcae3
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
View File

@ -423,8 +423,9 @@ NotifyPhase(
BitsOfAlignment = 0;
}
BaseAddress = mResAperture[0][0].MemLimit;
Status = gDS->AllocateMemorySpace (
EfiGcdAllocateAnySearchBottomUp,
EfiGcdAllocateMaxAddressSearchTopDown,
EfiGcdMemoryTypeMemoryMappedIo,
BitsOfAlignment,
AddrLen,