summaryrefslogtreecommitdiff
path: root/src/soc/amd/common/fsp
diff options
context:
space:
mode:
authorFelix Held <felix-coreboot@felixheld.de>2023-09-12 15:01:02 +0200
committerFelix Held <felix-coreboot@felixheld.de>2023-10-02 14:02:58 +0000
commit89ca4788439ddcdbf60311cae6939211cf463a8c (patch)
tree77d767fd9668a1f896b901719e4db5fe227036f2 /src/soc/amd/common/fsp
parent699b1c4a66084049531bc59a392052b4251da1e0 (diff)
soc/amd/common: use common physical address bit reservation code
Instead of having the get_usable_physical_address_bits function that only got used in the data fabric domain resource reporting code, drop this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the common AMD non-CAR CPU and rename get_sme_reserved_address_bits to get_reserved_phys_addr_bits so that the common cpu_phys_address_size function will return the correct number of usable physical address bits which now can be used everywhere. The common AMD CAR CPU support is only selected by Stoneyridge which doesn't support secure memory encryption, so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the SOC_AMD_COMMON_BLOCK_CAR Kconfig option. Before only the MMIO region reporting took the reserved physical address bits into account, but now also the MTRR calculation will take those reserved bits into account. See the AMD64 Programmers Manual volume 2 (document number 24593) for details. Chapter 7.10.5 from revision 3.41 of this document was used as a reference. The MTRR handling code in older Linux kernels complains when the upper reserved bits in the MTRR mask weren't set, but sets them after complaining and then continues to boot. This issue is no longer present in version 6.5 of the Linux kernel. The calculation of the TSEG mask however still needs to take all physical bits into account, including the ones reserved for the memory encryption. When not setting the reserved bits in the TSEG mask, the Mandolin board with a Picasso APU won't boot to the OS any more due to not returning from SeaBIOS calling into the VBIOS. Haven't root-caused what exactly causes this breakage, but I think previously when something else was wrong with the SMM initialization, also something went wrong when calling into the VBIOS. TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2 and Windows 10 boots on it via EDK2. TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following warning, but it still continues the boot process as described above: mtrr: your BIOS has configured an incorrect mask, fixing it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Diffstat (limited to 'src/soc/amd/common/fsp')
0 files changed, 0 insertions, 0 deletions