On Jul 3, 2020, at 11:06 AM, Laszlo Ersek <lersek@...
On 07/03/20 01:03, Andrew Fish via groups.io wrote:
PciHostBridgeDxe calls the PciHostBridgeGetRootBridges() function fromthe platform's "PciHostBridgeLib" instance. The function outputs anarray of PCI_ROOT_BRIDGE structures that describe the PCI root bridgeson the system, including the various resource apertures for each bridge(expressed as device address ranges).Then PciHostBridgeDxe tries to allocate the described apertures from theaccording resource type GCD spaces (after translating the address rangesin question from device addresses to host addresses).The attempt to allocate any one such aperture consists of three steps,(1) make sure the GCD memory map covers the aperture with compatibledescriptor(s), (2) set the aperture range to uncacheable (for MMIO only;not defined for IO), (3) actually allocate the aperture.In step (1), there's a slight trick. We don't call gDS->AddIoSpace() /gDS->AddMemorySpace() indiscriminately, because the platform may havepopulated the GCD memory space / IO space maps before, such that therecould be a (partial or complete) overlap with the aperture being added.Therefore the internal AddIoSpace() and AddMemoryMappedIoSpace()functions are idempotent. They contrast every existent GCD spacedescriptor with the aperture being added (including gaps, that is,"nonexistent" type descriptors). For the case when both ranges are fullydistinct, nothing is done. If there is a partial or full overlap, andthe descriptor is "nonexistent", then the intersection is added withgDS->AddIoSpace() / gDS->AddMemorySpace(). If there is a partial or fulloverlap, and the descriptor type is *not* "nonexistent", then theintersection's *compatibility* is checked, against the requested typeand capabilities of the aperture.The above procedure ensures that, for any given resource aperture, theGCD IO or memory space map covers the aperture, with nonzero (that is,possibly more than one!) adjacent descriptor entries, such that eachdescriptor intersecting with the aperture has compatible type andcapabilities with the aperture.In turn, the error message seen above reports a platform misconfiguration.It reports that the GCD memory space map already has an entry (adescriptor) at [E0000000, F0000000), with type 1 (that is,"EfiGcdMemoryTypeReserved" -- see "MdePkg/Include/Pi/PiDxeCis.h"). Thecapabilities of this range are 0x8700_0000_0002_600FAt the same time, the platform's PciHostBridgeLib instance reported aroot bridge with an MMIO aperture at [D4000000, FE100000), withcapabilities 1.This is a conflict. The capabilities don't even matter (we don't evencheck whether the existent GCD descriptor's capabilities are a supersetof the aperture's), because the aperture requires GCD memory typeEfiGcdMemoryTypeMemoryMappedIo, but the GCD descriptor has typeEfiGcdMemoryTypeReserved.In brief, the failure is due to the platform reporting a PCI root bridgeaperture such that it overlaps an area that is already listed as"reserved" in the GCD memory space map. So this is a platform bug;either in the "PciHostBridgeLib" instance, or in the module thatpopulates the GCD memory space map.
On Jul 2, 2020, at 3:54 PM, King Sumo <kingsumos@...> wrote:
When booting UefiPayloadPkg in my system (x86 Denverton SoC, coreboot) an assert error is generated in the PciHostBridgeDxe driver.
In the InitializePciHostBridge() function if all ASSERT's are ignored (by commenting out the code) the boot can move further on until it reaches the UEFI Shell.
Loading driver at 0x0007EE61000 EntryPoint=0x0007EE6CF52 PciHostBridgeDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7EF1F698
ProtectUefiImageCommon - 0x7EF1F140
- 0x000000007EE61000 - 0x0000000000013000
SetUefiImageMemoryAttributes - 0x000000007EE61000 - 0x0000000000001000 (0x0000000000004008)
SetUefiImageMemoryAttributes - 0x000000007EE62000 - 0x0000000000010000 (0x0000000000020008)
SetUefiImageMemoryAttributes - 0x000000007EE72000 - 0x0000000000002000 (0x0000000000004008)
PROGRESS CODE: V03040002 I0
InitRootBridge: populated root bus 0, with room for 7 subordinate bus(es)
Support/Attr: 10003 / 10003
AllocAttr: 0 ()
Bus: 0 - 7 Translation=0
Io: 0 - 4FFF Translation=0
Mem: D4000000 - FE0FFFFF Translation=0
MemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0
PMem: FFFFFFFFFFFFFFFF - 0 Translation=0
PMemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0
PciHostBridgeDxe: IntersectMemoryDescriptor: desc [E0000000, F0000000) type 1 cap 870000000002600F conflicts with aperture [D4000000, FE100000) cap 1
It looks like the above request for "D4000000 - FE0FFFFF” overlaps with an existing mapping (E0000000, F0000000). The edk2 has something called GCD (Global Coherency Domain) that is kind of like malloc for MMIO space, and what part of the CPU address has DRAM. So it looks like 2 device think they own (E0000000, F0000000), and there can be only one. You may be getting lucky that your hardware works, but something seems miss configured.
Thanks for the detailed response.
In your platforms DSC file you can or in 0x00100000 by hand into gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel to turn on DEBUG_GCD and get more DEBUG prints about GCD configuration. That may help you track down what is happening.
ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [PciHostBridgeDxe] /home/lxuser/occ/edk2/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(488): !EFI_ERROR (Status)