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 <[email protected]>
Reviewed-by: Olivier Martin <[email protected]>
---
Notes:
v2:
- fix typo in commit message (woring -> working)
ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
index 558786a..61231e9 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/PciHostBridgeDxe/PciHostBridge.c
@@ -416,8 +416,9 @@ NotifyPhase(
BitsOfAlignment = 0;
}
+ BaseAddress = mResAperture[0][0].MemLimit;
Status = gDS->AllocateMemorySpace (
- EfiGcdAllocateAnySearchBottomUp,
+ EfiGcdAllocateMaxAddressSearchTopDown,
EfiGcdMemoryTypeMemoryMappedIo,
BitsOfAlignment,
AddrLen,
--
1.8.3.1
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
