diff options
author | Patrick Rudolph <patrick.rudolph@9elements.com> | 2025-01-31 09:02:49 +0100 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2025-04-08 06:32:56 +0000 |
commit | c9ff19705972e50ff84c52ba726008e37f7ba699 (patch) | |
tree | 7462e382efc17f0fd9a7c2b54473eb8e35d5062c /BaseTools/Source/Python | |
parent | 1d5063763bedad4d87288a975fba0b3637fa3bd1 (diff) | |
download | edk2-c9ff19705972e50ff84c52ba726008e37f7ba699.zip edk2-c9ff19705972e50ff84c52ba726008e37f7ba699.tar.gz edk2-c9ff19705972e50ff84c52ba726008e37f7ba699.tar.bz2 |
UefiPayloadPkg: UefiPayloadEntry: Don't use reserved DRAM
Recent AMD platforms reserve parts of the lower DRAM where UefiPayload is
being loaded to and since UefiPayloadEntry doesn't care, it uses the reserved
memory for HOB and memory allocation.
The bootloader cannot prevent this, as it can only place the UEFI FV in
usable DRAM, but it has no control over EfiBootService memory allocations.
This issue prevents boot on those platforms without any specific error message.
It's not vendor specific and can happen on every platform.
Add the same logic as used on UniversalPayload and do the following:
- Walk bootloader provided memory information
- Skip everything that's not marked as usable DRAM
- Align entries to 1MiB boundary
- Don't use memory above 4GiB on x86_32
- Skip memory ranges too small
- Don't use memory currently occupied by the UEFI FV itself
Once a useable memory range is found pass it to HobConstructor().
TEST: Fixes boot on AMD/glinda, that reserved memory at 2000000h.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Diffstat (limited to 'BaseTools/Source/Python')
0 files changed, 0 insertions, 0 deletions