coreboot

For EDK2 upstream the RESOURCE_ALLOCATION_TOP_DOWN option is not default on.
I for example (on a recent AMD platform) have a problem in this function: https://github.com/tianocore/edk2/blob/80eaa563ec1cd2272334134d5fd35d856843fe65/UefiPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c#L208
It seems to assume all PCIe resources are continuous. And in my case they are not, because from top to down the allocations are continuous with a single exception: there is a single device that has an allocation further down. And apparently the ScanForRootBridges() function just takes the lowest and highest resource and defines that as reserved MMIO space. I got kind of lucky because it asserts, since the ECAM address is directly between that and EDK2 notices it can't reserve memory for it.

Maybe you hit a similar issue, but its more obfuscated in your case? In any case we should update the UEFIPayloadPkg function (hoping nothing else in EDK2 depends on it) to not assume a continuous MMIO space. It may also work to use ALWAYS_ALLOW_ABOVE_4G_ALLOCATION=y but I didn't try that yet.

Maybe you hit a similar issue, but its more obfuscated in your case? In any case we should update the UEFIPayloadPkg function (hoping nothing else in EDK2 depends on it) to not assume a continuous MMIO space.

I think you may be right. looking at the cbmem and dmesg logs from both the top-down and bottom-up allocations, coreboot allocates the same memory windows:

[INFO ]   * Base: 80000000, Size: 70000000, Tag: 200
[INFO ]   * Base: f4000000, Size: a000000, Tag: 200
[INFO ]   * Base: 17f000000, Size: 7e81000000, Tag: 200

but for the 2nd window, the kernel isn't seeing the full size:

pci_bus 0000:00: root bus resource [mem 0x80000000-0xefffffff window]
pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff window]

I'm guessing edk2 is futzing with the memory map. In the top down scenario, the kernel sees the I2C controllers as being outside of the (incorrectly small) 2nd window, and remaps them inside the first. Windows likely see it and just says sorry, no I2C for you.

I'll grab some edk2 logs and see if there's anything insightful there

Related patch: CB:89464 device/Kconfig: Disable top-down resource allocation for pre-FSP 2.0

Is using the option CONFIG_EDK2_CBMEM_LOGGING the correct way to log EDK2 and is there a way to increase the CBMEM size or should I decrease coreboot its own logging from SPEW to EMERGENCY to keep more space available for EDK2 log?

Walter Sonius wrote in #note-3:

Related patch: CB:89464 device/Kconfig: Disable top-down resource allocation for pre-FSP 2.0

Is using the option CONFIG_EDK2_CBMEM_LOGGING the correct way to log EDK2 and is there a way to increase the CBMEM size or should I decrease coreboot its own logging from SPEW to EMERGENCY to keep more space available for EDK2 log?

I would use:

CONFIG_EDK2_CBMEM_LOGGING=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x80000

reducing coreboot's logging level will not free up a meaningful amount of space. edk2 uses 10x what coreboot does, the cbmem allocation must be increased.

I think I've found the issue actually: pre-Skylake Intel platforms all define their MMIO ranges statically in ASL, and have a single window defined. That works fine for bottom-up allocation, but not for top-down, where there are two Windows, and we start with the top one. So the proper fix is going to be migrating the older platforms to use the dynamically-generated MMIO windows that the Intel common SoC's all use. Will push patches once I have something working.