summaryrefslogtreecommitdiff
path: root/ArmPlatformPkg
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2015-02-23 16:03:51 +0000
committerlersek <lersek@Edk2>2015-02-23 16:03:51 +0000
commitb9a44dcae3f5ac9b0d62234232c9fd12afec47ed (patch)
tree5552733c90bc872dfe78779196608e4bde144a0e /ArmPlatformPkg
parentef8dba7da3bb9bef067d553a0ac53e216e085daf (diff)
downloadedk2-platforms-b9a44dcae3f5ac9b0d62234232c9fd12afec47ed.tar.xz
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
Diffstat (limited to 'ArmPlatformPkg')
-rw-r--r--ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
index 78c12d0009..1534c3dc04 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -423,8 +423,9 @@ NotifyPhase(
BitsOfAlignment = 0;
}
+ BaseAddress = mResAperture[0][0].MemLimit;
Status = gDS->AllocateMemorySpace (
- EfiGcdAllocateAnySearchBottomUp,
+ EfiGcdAllocateMaxAddressSearchTopDown,
EfiGcdMemoryTypeMemoryMappedIo,
BitsOfAlignment,
AddrLen,