aboutsummaryrefslogtreecommitdiff
path: root/src/vendorcode/amd/pi/00670F00/binaryPI/AGESA.c
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2017-09-26 16:22:38 -0600
committerAaron Durbin <adurbin@chromium.org>2017-09-28 04:48:52 +0000
commit46300aa2ce91d3190602d88f16e553a040c842ef (patch)
treef3311bf455aa3f9f087097035c23cca83c18900e /src/vendorcode/amd/pi/00670F00/binaryPI/AGESA.c
parentf2a382248800ab288a6d1416df9cc534204344eb (diff)
util/cbmem: be explicit about memory map sizes
The cbmem utility has inherited some workarounds that originated from the default 1 MiB mapping always working. This 1 MiB mmap won't necessarily succeed if the 1 MiB encroaches on a subsequent memory range that has different cacheability. To fix this, map in only 4 KiB when the table size is not known which is the case for any forwarding entry or any low table entries on x86. That smaller mapping is then searched for a valid header. Once a valid header is found the full table is mapped and parsed allowing a forwarding entry to take precedence. Lastly, the lbtable is kept mapped in such that other operations can just operate on mapping that was previously parsed. In order to allow multiple in-flight mappings a struct mapping was added which caused the ripple within the code. However, there shouldn't be any more reasons for putting weird heuristics for when to fail. If the tables are bad then it's very much possible that mappings will fail. Retrying when the exact sizes are already known won't fix those issues. BUG=b:66681446 Change-Id: Ica0737aada8dc07311eae867e87ef2fd24eae98d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/21718 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Diffstat (limited to 'src/vendorcode/amd/pi/00670F00/binaryPI/AGESA.c')
0 files changed, 0 insertions, 0 deletions