summaryrefslogtreecommitdiff
path: root/BaseTools/Source/Python
diff options
context:
space:
mode:
authorPatrick Rudolph <patrick.rudolph@9elements.com>2025-01-31 09:02:49 +0100
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2025-04-08 06:32:56 +0000
commitc9ff19705972e50ff84c52ba726008e37f7ba699 (patch)
tree7462e382efc17f0fd9a7c2b54473eb8e35d5062c /BaseTools/Source/Python
parent1d5063763bedad4d87288a975fba0b3637fa3bd1 (diff)
downloadedk2-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