From: mjg59@srcf.ucam.org
To: devel@edk2.groups.io
Subject: UefiPayloadPkg and over-eager PCI resource allocation?
Date: Sun, 27 Dec 2020 20:40:35 +0000 [thread overview]
Message-ID: <20201227204035.GA16211@codon.org.uk> (raw)
I'm trying to run UefiPayloadPkg on a Coreboot-based system. Based on
debug logs, my GCD looks like this:
GCDMemType Range Capabilities Attributes
========== ================================= ================ ================
Reserved 0000000000000000-0000000000000FFF 870000000000000F 0000000000000000
SystemMem 0000000000001000-000000000009FFFF 800000000000000F 0000000000000000*
Reserved 00000000000A0000-00000000000FFFFF 870000000000000F 0000000000000000
SystemMem 0000000000100000-0000000099A5DFFF 800000000000000F 0000000000000000*
Reserved 0000000099A5E000-000000009F7FFFFF 870000000000000F 0000000000000000
NonExist 000000009F800000-00000000DFFFFFFF 0000000000000000 0000000000000000
Reserved 00000000E0000000-00000000EFFFFFFF 870000000000000F 0000000000000000
NonExist 00000000F0000000-00000000FBFFFFFF 0000000000000000 0000000000000000
Reserved 00000000FC000000-00000000FC000FFF 870000000000000F 0000000000000000
NonExist 00000000FC001000-00000000FDFFFFFF 0000000000000000 0000000000000000
Reserved 00000000FE000000-00000000FE00FFFF 870000000000000F 0000000000000000
NonExist 00000000FE010000-00000000FEC7FFFF 0000000000000000 0000000000000000
MMIO 00000000FEC80000-00000000FECFFFFF C700000000000001 0000000000000000*
NonExist 00000000FED00000-00000000FED0FFFF 0000000000000000 0000000000000000
Reserved 00000000FED10000-00000000FED17FFF 870000000000000F 0000000000000000
NonExist 00000000FED18000-00000000FED7FFFF 0000000000000000 0000000000000000
Reserved 00000000FED80000-00000000FED83FFF 870000000000000F 0000000000000000
NonExist 00000000FED84000-00000000FED8FFFF 0000000000000000 0000000000000000
Reserved 00000000FED90000-00000000FED91FFF 870000000000000F 0000000000000000
NonExist 00000000FED92000-00000000FED9FFFF 0000000000000000 0000000000000000
Reserved 00000000FEDA0000-00000000FEDA1FFF 870000000000000F 0000000000000000
NonExist 00000000FEDA2000-00000000FFFFFFFF 0000000000000000 0000000000000000
Reserved 0000000100000000-000000085F7FFFFF 830000000000000F 0000000000000000
NonExist 000000085F800000-0000007FFFFFFFFF 0000000000000000 0000000000000000
At boot I hit an assertion:
PciHostBridgeDxe: IntersectMemoryDescriptor: desc [E0000000, F0000000) type 1 cap 870000000002600F conflicts with aperture [9F800000,FE100000) cap 1
which is, at face value, legitimate. However, e0000000 is the MMCONF
window, and this is where I'd expect it to be. 9f800000 is the base of
the PCIe host bridge aperture, which is also where I'd expect it to be.
Coreboot seems to think that this should all work:
DOMAIN: 0000: Resource ranges:
* Base: 9f800000, Size: 40800000, Tag: 200
* Base: f0000000, Size: c000000, Tag: 200
* Base: fc001000, Size: 1fff000, Tag: 200
* Base: fe010000, Size: d00000, Tag: 200
* Base: fed18000, Size: 68000, Tag: 200
* Base: fed84000, Size: c000, Tag: 200
* Base: fed92000, Size: e000, Tag: 200
* Base: feda2000, Size: 125e000, Tag: 200
* Base: 85f800000, Size: 77a0800000, Tag: 100200
9f800000+40800000 is e0000000, so that seems fine. There's also some
other windows, but nothing that collides with the MMCONF region. But
when we get to Tiano:
PciRoot(0x0)
Support/Attr: 7001F / 7001F
DmaAbove4G: No
NoExtConfSpace: No
AllocAttr: 0 ()
Bus: 0 - 3 Translation=0
Io: 1000 - EFFF Translation=0
Mem: 9F800000 - FE0FFFFF Translation=0
Which obviously collides with MMCONF, along with a couple of other
allocations. Is it trying to merge the entire range of MMIO regions into
a single aperture? Does this seem like a Coreboot or a UefiPayloadPkg
issue?
next reply other threads:[~2020-12-27 20:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-27 20:40 mjg59 [this message]
2021-01-04 3:17 ` [edk2-devel] UefiPayloadPkg and over-eager PCI resource allocation? Guo Dong
2021-01-04 6:34 ` Benjamin You
2021-01-06 13:56 ` Patrick Rudolph
2021-01-06 22:20 ` Guo Dong
2021-01-06 22:34 ` Matthew Garrett
2021-01-06 23:04 ` Guo Dong
2021-01-07 4:09 ` Benjamin You
2021-01-07 13:14 ` Laszlo Ersek
2021-01-07 22:04 ` Matthew Garrett
2021-01-07 22:28 ` Laszlo Ersek
2021-01-07 22:39 ` Matthew Garrett
2021-01-08 2:18 ` Guo Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201227204035.GA16211@codon.org.uk \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox