diff options
| author | Laszlo Ersek <lersek@redhat.com> | 2015-02-23 16:03:51 +0000 |
|---|---|---|
| committer | lersek <lersek@Edk2> | 2015-02-23 16:03:51 +0000 |
| commit | b9a44dcae3f5ac9b0d62234232c9fd12afec47ed (patch) | |
| tree | 5552733c90bc872dfe78779196608e4bde144a0e /ArmPlatformPkg | |
| parent | ef8dba7da3bb9bef067d553a0ac53e216e085daf (diff) | |
| download | edk2-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.c | 3 |
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,
|