[edk2-devel] UefiPayloadPkg: assert error in PciHostBridgeDxe

Fri Jul 3 18:29:55 UTC 2020

> On Jul 3, 2020, at 11:06 AM, Laszlo Ersek <lersek at redhat.com> wrote:
> 
> On 07/03/20 01:03, Andrew Fish via groups.io <http://groups.io/> wrote:
>> 
>> 
>>> On Jul 2, 2020, at 3:54 PM, King Sumo <kingsumos at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> 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.
>>> Any clues?
>>> 
>>> 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)
>>> RootBridge: PciRoot(0x0)
>>>  Support/Attr: 10003 / 10003
>>>    DmaAbove4G: No
>>> NoExtConfSpace: No
>>>     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. 
> 
> PciHostBridgeDxe calls the PciHostBridgeGetRootBridges() function from
> the platform's "PciHostBridgeLib" instance. The function outputs an
> array of PCI_ROOT_BRIDGE structures that describe the PCI root bridges
> on the system, including the various resource apertures for each bridge
> (expressed as device address ranges).
> 
> Then PciHostBridgeDxe tries to allocate the described apertures from the
> according resource type GCD spaces (after translating the address ranges
> in 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 compatible
> descriptor(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 have
> populated the GCD memory space / IO space maps before, such that there
> could 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 space
> descriptor with the aperture being added (including gaps, that is,
> "nonexistent" type descriptors). For the case when both ranges are fully
> distinct, nothing is done. If there is a partial or full overlap, and
> the descriptor is "nonexistent", then the intersection is added with
> gDS->AddIoSpace() / gDS->AddMemorySpace(). If there is a partial or full
> overlap, and the descriptor type is *not* "nonexistent", then the
> intersection's *compatibility* is checked, against the requested type
> and capabilities of the aperture.
> 
> The above procedure ensures that, for any given resource aperture, the
> GCD IO or memory space map covers the aperture, with nonzero (that is,
> possibly more than one!) adjacent descriptor entries, such that each
> descriptor intersecting with the aperture has compatible type and
> capabilities 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 (a
> descriptor) at [E0000000, F0000000), with type 1 (that is,
> "EfiGcdMemoryTypeReserved" -- see "MdePkg/Include/Pi/PiDxeCis.h"). The
> capabilities of this range are 0x8700_0000_0002_600F
> 
> At the same time, the platform's PciHostBridgeLib instance reported a
> root bridge with an MMIO aperture at [D4000000, FE100000), with
> capabilities 1.
> 
> This is a conflict. The capabilities don't even matter (we don't even
> check whether the existent GCD descriptor's capabilities are a superset
> of the aperture's), because the aperture requires GCD memory type
> EfiGcdMemoryTypeMemoryMappedIo, but the GCD descriptor has type
> EfiGcdMemoryTypeReserved.
> 
> In brief, the failure is due to the platform reporting a PCI root bridge
> aperture 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 that
> populates the GCD memory space map.
> 

Laszlo,

Thanks for the detailed response. 

Sumo,

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. 

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>>> ASSERT [PciHostBridgeDxe] /home/lxuser/occ/edk2/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c(488): !EFI_ERROR (Status)
>>> 
>>> Thanks,
>>> Sumo
>>> 
>>> 
>> 
>> 
>> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62054): https://edk2.groups.io/g/devel/message/62054
Mute This Topic: https://groups.io/mt/75269502/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200703/f6af392c/attachment.htm>