summaryrefslogtreecommitdiff
path: root/util/intelmetool
diff options
context:
space:
mode:
authorFelix Held <felix-coreboot@felixheld.de>2023-03-03 16:08:57 +0100
committerFelix Held <felix-coreboot@felixheld.de>2023-03-08 13:00:29 +0000
commit4892d737e3050a645083b946b5f7e884479c1a8f (patch)
tree206f4818c334e721e939e39c1b0326356099f404 /util/intelmetool
parent84fb9eac96dc15016820eec6fc6de91f4a243205 (diff)
soc/amd/stoneyridge/romstage: pass C state control IO base address
Instead of hoping that the default the C state control IO address in binaryPI won't interfere with any other IO space usage in coreboot, assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform config structure element to make sure that binaryPI will use a known address for the IO port based C state control. binaryPI will write this address to the MSR_CSTATE_ADDRESS and will then also use these IO ports in the _CST packages in the PSTATE SSDT, so changing this won't cause a mismatch between those two. The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on Careena is 0x1770, so this didn't collide with any other IO space registers, but it's still much better to tell binaryPI which exact IO addresses to use. TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in the _CST package entry for the second C state which are both the expected values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Diffstat (limited to 'util/intelmetool')
0 files changed, 0 insertions, 0 deletions