Cbmem pci rb info#281
Merged
Merged
Conversation
Contributor
Author
|
We can wait until upstream patches are merged, because we certainly don't want to have any conflicts with cbmem IDs |
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
4 times, most recently
from
238dc72 to
1309219
Compare
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
from
76b2b66 to
00374b8
Compare
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
13 times, most recently
from
60e4901 to
d3e520c
Compare
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
9 times, most recently
from
82cfd6d to
358f988
Compare
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
from
358f988 to
af03924
Compare
Contributor
Author
|
@mkopec @SergiiDmytruk could you please review? The PR is waiting for some time already and it will be needed for all AMD platforms to work properly. I would like to get it merged to start with Gigabyte MZ33-AR1 release. |
SergiiDmytruk
requested changes
May 6, 2026
On AMD server systems there are multiple PCI root bridges. The root bridge scanning in UEFI Payload is not sufficient to detect the memory and I/O apertures properly. For example, on Turin system, the I/O aperture on the first root bridge containing the FCH may not have any I/O resources detected on the PCI devices. This results in the I/O decoding to be disabled on the root bridge, effectively breaking the I/O-based serial ports, e.g. on Super I/Os and BMCs. Populate the root bridge info from CB_TAG_RB_INFO which contains data compatible with the Universal Payload PCI Root Bridges Info HOB. Make the PciHostBridgeLib pick the HOB up, if available, and populate proper root bridge apertures for AMD systems. Otherwise, fall back to root bridge scanning. Relevant coreboot patches: https://review.coreboot.org/c/coreboot/+/89486 https://review.coreboot.org/c/coreboot/+/89487 TEST=Boot UEFI Payload and see the serial console no longer breaks after PCI enumeration in UEFI Payload on Gigabyte MZ33-AR1. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Mark the range 0x1000-0xa0000 as tested. It caused the payload to mark this range as reserved. As a result, Linux kernel could not allocate memory for real mode and panicked. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
miczyg1
force-pushed
the
cbmem_pci_rb_info
branch
4 times, most recently
from
c3a6101 to
af5ec52
Compare
There was a dirty hack for Intel platforms that read TOLUD register to determine the boundary between MMIO and DRAM. It caused problems on AMD platforms such as apu2, which does not have TOLUD register. As a result, regions which held reserved memory were incorrectly reported as RAM buffers or RAM itself and the OS allocated DMA there. It could be observed with many IO_PAGE_FAULTs occurring in the OS. See: Dasharo/dasharo-issues#1134 FWTS complains on ECAM MMCONF not being reserved in the memory map. So carve it out of the memory map and report it as reserved. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
FWTS complains on MMCONF not being reseved in memory map. So reserve it. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
…ve 4G RAM Do not clear testd attribute from above 4G RAM memory. It caused the payload to mark above 4G ranges as reserved. As a result, Linux kernel had only as much memory, as there is available memory below 4G reported by coreboot. It caused out of memory processes kills in Linux. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
…MMIO Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
coreboot always uses TSC for timestamps, force correct timer library so measurements are accurate. A mismatch of timers will result in incorrect tick and nanosecond calculations due to different timer frequency. Add a copy of BaseCpuTimerLib from UefiCpuPkg and replace TSC frequency calculation with the value obtained from coreboot timestamp table. On Intel systems where the UefiCpuPkg/CpuTimerLib is used, there is no mismatch. However, AMD systems do not have the required CPUID, so the default timer is HPET, not TSC. TEST=Boot Gigabyte MZ33-AR1 and use systemd-analyze. The firmware boot time is no longer 19 minutes, but indicates correct time spent in firmware. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
…ties The timer/counter start and end value were hardcoded instead of being read from the performance protocol. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Upstream-Status: Pending
…read Add an override from openSIL/amd-edk2-platforms repo for USB mass storage. On Gigabyte MZ33-AR1 there are lots of errors from virtual CD-ROM from BMC. These additional resets help a bit in USB enumeration during boot. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
AMD silicon has different definitions for SLP_Sx states written to the ACPI PM register than Intel. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
coreboot always uses TSC for timestamps, force correct timer library so measurements are accurate. A mismatch of timers will result in incorrect tick and nanosecond calculations due to different timer frequency. Add a copy of BaseCpuTimerLib from UefiCpuPkg and replace TSC frequency calculation with the value obtained from coreboot timestamp table. On Intel systems where the UefiCpuPkg/CpuTimerLib is used, there is no mismatch. However, AMD systems do not have the required CPUID, so the default timer is HPET, not TSC. TEST=Boot Gigabyte MZ33-AR1 and use systemd-analyze. The firmware boot time is no longer 19 minutes, but indicates correct time spent in firmware. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Modern AMD platforms cannot initialize graphics in 32bit mode (using PEI GOP or VBIOS), because of UMA memory allocation above 4G by default. One would have to force the recovery path so that UMA is allocated below 4G. To allow running AMD x64 GOP, some modifications are needed. Firstly, the GOP still needs VBIOS, so PCI IO must provide it from FFS. Then, the GOP driver must also be included in the FFS, so that DXE dispatcher picks it up and runs it. TEST=Successfully initialize integrated graphics on MSI PRO B850-P WIFI. Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
SergiiDmytruk
approved these changes
May 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some fixes for Gigabyte MZ33-AR1 server to work.