summaryrefslogtreecommitdiff
path: root/src/soc/amd/common
AgeCommit message (Collapse)Author
2023-05-22soc/amd/common/psp_verstage: Map/unmap boot device on need basisKarthikeyan Ramasubramanian
Currently the SPI ROM is mapped completely when the boot device is initialized. That mapping remains active throughout the execution time of PSP verstage. Every 1 MiB of mapped SPI ROM region consumes 1 TLB Slot in PSP for use during memory mapped or DMA access. With 16 MiB of mapped SPI ROM + FCH devices + 4 reserved TLB slots, 31 out of 32 total TLB slots is consumed. This leaves almost no scope for future expansion. With upcoming programs possibly using 32 MiB SPI ROM, PSP will run out of TLB slots to support 32 MiB. Hence instead of mapping the entire SPI ROM upfront, get the SPI ROM SMN address during the boot device initialization. Update the boot device region operations to map and unmap the SPI flash with the desired offset and size using the SVC call. Then anytime a memory mapped SPI ROM access is performed: map the required area, read the data and immediately unmap the area. There is no update required when using CCP DMA, since the concerned SVC call performs mapping and unmapping of the required SPI flash area implicitly. With these changes, maximum of 8 slots(size of RO section) might get used at any point in time during the PSP verstage execution. BUG=b:240664755 TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and suspend/resume cycles for 50 iterations each. Ensured that there is no impact to boot time. Change-Id: Icd44ea7b2a366e9269debcab4186d1fc71651db2 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74606 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-22soc/amd/common/psp_verstage: Always build unsigned PSP verstageKarthikeyan Ramasubramanian
Currently unsigned PSP verstage binary is copied from ELF file only when required in amdfw*.rom. If a signed PSP verstage binary is supplied while building amdfw*.rom, then it is dropped. Copy the unsigned PSP verstage binary always so that it can be used for signing directly from the CI build infrastructure instead of a locally built binary. BUG=None TEST=Build Skyrim BIOS image and ensure that the unsigned PSP verstage is part of the build artifacts. Change-Id: If797dcfd20aa2991f3517904ef862406b9b9875c Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75334 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-16soc/amd/*/Kconfig: change ACPI_CPU_STRING to use hexadecimal CPU numbersFelix Held
Both the AMD AGESA reference code and the default coreboot ACPI_CPU_STRING use hexadecimal numbers in the ACPI CPU object names, so change the ACPI_CPU_STRING format string in the both the Stoneyridge Kconfig and the common non-CAR AMD SoC config Kconfig which covers all other AMD SoCs in soc/amd. All platforms where the P state and C state SSDT from binaryPI (Stoneyridge) or FSP (Picasso) was used in coreboot before it got replaced by native code, had at most 8 cores/threads, so the mismatch never became apparent. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9d6822c5df01786ee541ce90734b75ed1a761fca Reviewed-on: https://review.coreboot.org/c/coreboot/+/75250 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-13acpi/Kconfig: move \_SB scope out of ACPI_CPU_STRINGFelix Held
In ACPI 1.0 the processor objects were inside the \_PR scope, but since ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS compatibility, but apart from that the \_PR scope is deprecated. coreboot already uses the \_SB scope for the processor devices everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the format string inside the 3 snprintf statements that use the ACPI_CPU_STRING. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-05soc/amd/cmn/acpi/sleepstates.asl: Align with sb/amdAngel Pons
Adjust a few things so that the sleepstates.asl file is the same for sb/amd and soc/amd. These adjustments don't have a functional impact. Change-Id: I0cc9462b326cdc371ffdbf5759d8adc42456ce74 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74960 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-05{sb,soc}/amd/cmn/acpi/sleepstates.asl: Hook up configsAngel Pons
Commit cbc5d3f34b87db779829eabc90c32780a3865a56 ("soc/intel: Don't report _S1 state when unsupported") added the `ACPI_S1_NOT_SUPPORTED` option and commit 0eb5974def63a2fc0dce6dfdad62b0b4c6f4b865 ("acpigen: Add a runtime method to override exposed _Sx sleep states") added a mechanism to override the enabled sleep states at runtime. However, these were only hooked up to Intel sleepstates. so the options would not have any effect on AMD platforms. Apply the changes from these two commits to AMD sleepstates so that both options can be used on AMD platforms as well. Change-Id: I7d5ef2361e36659ac5c6f54b2c236d48713a07c9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74959 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-04soc/amd/common/block/lpc/lpc: simplify index handling in read resourcesFelix Held
Now that we don't need to find a specific resource in the set resources function any more, there's no need to use hard-coded indices for the fixed resources. Instead use an index variable that gets incremented after each fixed resource got added. The index now starts at 0 instead of at 1, but now the only requirement is that those indices are unique. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ida5f1f001c622da2e31474b62832782f5f303a32 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74849 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-05-03soc/amd/common/block/lpc/lpc: drop custom lpc_set_resourcesFelix Held
Drop the custom lpc_set_resources implementation that does some register access that has no effect and then calls pci_dev_set_resources and use pci_dev_set_resources for set_resources in amd_lpc_ops instead. The SPI controller's base address got configured early in boot in the lpc_set_spibase call and the enable bits got set early in boot in the lpc_enable_spi_rom call. TEST=The contents of the SPI_BASE_ADDRESS_REGISTER at the beginning and at the end of the call stay the same, so it's simply a no-op. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7a5e3e00b2e38eeb3e9dae6d6c83d11ef925ce22 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74848 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-03soc/amd/common/block/lpc/lpc: report HPET MMIOFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77471d464dddffc63bb2f005fef3a33c84ff5f5e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74847 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-03soc/amd/common/block/lpc/lpc: use mmio_range to report FCH IOAPIC MMIOFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I813a27e392a842188dc474018f82e10309783260 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74846 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-03soc/amd/common/block/lpc/lpc: report eSPI MMIOFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I63fb70da3e9ded6c05354f94ee69bc6dd04e58f0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-03soc/amd/common/block/lpc/lpc: increase size of SPI BAR to 4kByteFelix Held
The memory map granularity for those devices is 4kByte. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8806128bdce8988f5cd7c8fa8a342fdb01eb7f42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74844 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-03soc/amd/common/block/lpc/lpc: report mapped SPI flash as MMIO rangeFelix Held
Since the 16MByte of memory-mapped SPI flash region right below the 4GB boundary is both a fixed region and isn't decoded on a device below the LPC device, but assumed to be decoded by the LPC device itself, it shouldn't be reported as a subtractive resource, but as an MMIO resource instead. TEST=On mandolin the 16MByte MMIO-mapped SPI flash now show up as a reserved region in the e820 memory map which wasn't the case before: 13. 00000000ff000000-00000000ffffffff: RESERVED The Linux kernel doesn't show any new or possibly related errors. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: Ib52df2b2d79a1e6213c3499984a5a1e0e25c058a Reviewed-on: https://review.coreboot.org/c/coreboot/+/74839 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-27soc/amd: Drop acpi_fill_madt_irqoverride()Kyösti Mälkki
It is unused. The use of field irq is problematic as it should appear relative to IOAPIC GSI bases in the devicetree. Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-26soc/amd/common/block/gfx: Re-add signature check for vbios cacheMatt DeVillier
Commit c7b8809f155a ("soc/amd/common/block/gfx: Use TPM-stored hash for vbios cache validation") replaced checking the vbios signature (first two bytes) with checking against a TPM-stored hash, but there exists an edge case where the empty cache can be hashed and therefore never updated with the correct vbios data. To mitigate this, re-add the signature check to ensure that an empty cache will never be hashed to TPM. BUG=b:255812886 BRANCH=skyrim TEST=build/boot skyrim w/selective GOP enabled, flash full firmware image, ensure GOP driver is run until cache updated with valid data and hashed to TPM. Change-Id: Id06a8cfaa44d346fb2eece53dcf74ee46f4a5352 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74525 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-26soc/amd: Use ACPI_COMMON_MADT_IOAPICKyösti Mälkki
Change IRQ #0 to GSI #2 override to positive edge trigger from the bus ISA default (positive edge). Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-26arch/x86/ioapic: Promote ioapic_get_sci_pin()Kyösti Mälkki
Platform needs to implement this to provide information about SCI IRQ pin and polarity, to be used for filling in ACPI FADT and MADT entries. Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-23include/cpu/amd/mtrr: fix typo in get_top_of_mem_above_4gbFelix Held
Add the missing 'b' to the 4gb so that get_top_of_mem_above_4gb is in line with get_top_of_mem_below_4gb. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic9170372d8b0c27d7de3bd04d822c95e2015cb10 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-21soc/amd/common/cpu/noncar/early_cache: use get_top_of_mem_below_4gbFelix Held
Use get_top_of_mem_below_4gb instead of open-coding the functionality. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icc9e5ad8954c6203fc4762aa976bba7e8ea16159 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74615 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2023-04-21soc/amd/common/block/acpi/tables: use get_top_of_mem_[below,above]_4gbFelix Held
Use get_top_of_mem_below_4gb and get_top_of_mem_above_4g instead of open-coding the functionality. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I35895340f6e747e2f5e1669d40f40b201d8c1845 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74612 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-19soc/amd/common/block/lpc/spi_dma: Leverage CBFS_CACHE when using SPI DMAKarthikeyan Ramasubramanian
CBFS library performs memory mapped access of the files during loading, verification and de-compression. Even with MTRRs configured correctly, first few file access through memory map are taking longer times to load. Update the SPI DMA driver to load the files into CBFS cache, so that they can be verified and de-compressed with less overhead. This saves ~60 ms in boot time. BUG=None TEST=Build Skyrim BIOS image and boot to OS. Observe ~60 ms improvement with the boot time. Performing additional test to confirm there are no regressions. Before: ======= 970:loading FSP-M 15:starting LZMA decompress (ignore for x86) 760,906 (60,035) 16:finished LZMA decompress (ignore for x86) 798,787 (37,881) 8:starting to load ramstage 17:starting LZ4 decompress (ignore for x86) 1,050,093 (13,790) 18:finished LZ4 decompress (ignore for x86) 1,054,086 (3,993) 971:loading FSP-S 17:starting LZ4 decompress (ignore for x86) 1,067,778 (3,313) 18:finished LZ4 decompress (ignore for x86) 1,068,022 (244) 90:starting to load payload 17:starting LZ4 decompress (ignore for x86) 1,302,155 (11,285) 18:finished LZ4 decompress (ignore for x86) 1,303,938 (1,783) After: ====== 970:loading FSP-M 15:starting LZMA decompress (ignore for x86) 709,542 (12,178) 16:finished LZMA decompress (ignore for x86) 739,379 (29,837) 8:starting to load ramstage 17:starting LZ4 decompress (ignore for x86) 1,001,316 (12,368) 18:finished LZ4 decompress (ignore for x86) 1,001,971 (655) 971:loading FSP-S 17:starting LZ4 decompress (ignore for x86) 1,016,514 (3,031) 18:finished LZ4 decompress (ignore for x86) 1,016,722 (207) 90:starting to load payload 17:starting LZ4 decompress (ignore for x86) 1,244,602 (10,313) 18:finished LZ4 decompress (ignore for x86) 1,244,831 (228) Change-Id: Ie30b6324f9977261c60e55ed509e979ef290f1f1 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74334 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-04-15sb,soc/amd,intel: Add and use ACPI_COMMON_MADT_LAPICKyösti Mälkki
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have special handling for the time being. Change of aopen/dxplplusu is coupled with sb/intel/i82801dx. Change of emulation/qemu-i440fx is coupled with intel/i82371eb. For asus/p2b, this adds MADT LAPIC entries, even though platform has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates the MADT, including an entry for LAPIC address. Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-14soc/amd: Clarify ACPI _PRT entry generationKyösti Mälkki
The reference to a constant FCH IOAPIC interrupt count used with GNB IOAPIC was a bit obscure. Change-Id: I2d862e37424f9fea7f269cd09e9e90056531b643 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74314 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-10soc/amd/common/blk/pcie: Program LTR max latenciesMatt DeVillier
PCIe bridges need to provide the LTR (latency tolerance reporting) maximum snoop/non-snoop values so that they are inherited by downstream PCIe devices which support and enable LTR. Without this, downstream devices cannot have LTR enabled, which is a requirement for supporting PCIe L1 substates. Enabling L1ss without LTR has unpredictable behavior, including some devices refusing to enter L1 low power modes at all. Program the max snoop/non-snoop latency values for all PCIe bridges using the same value used by AGESA/FSP, 1.049ms. BUG=b:265890321 TEST=build/boot google/skyrim (multiple variants, NVMe drives), ensure LTR is enabled, latency values are correctly set, and that device power draw at idle is in the expected range (<25 mW). Change-Id: Icf188e69cf5676be870873c56d175423d16704b4 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74288 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-04soc/amd/*/Makefile: use all_x86 targetFelix Held
Use the newly introduced 'all_x86' make target to add the compilation unit to all stages that run on the x86 cores, but not to verstage on PSP. TEST=Timeless builds for Mandolin without verstage on PSP and Guybrush with verstage on PSP result in identical images with and without this patch applied. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I94de6de5a4c7723065a4eb1b7149f9933ef134a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74151 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-03-31soc/amd/common/block/cpu/tsc/Makefile: order targets by stageFelix Held
Now that only one build target per stage is included in the build depending on CONFIG_SOC_AMD_COMMON_BLOCK_TSC being set, don't use a separate ifeq block for this. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id9e551b37707081eb2ea1d682013f57c7ca8aabd Reviewed-on: https://review.coreboot.org/c/coreboot/+/74017 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-31soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for SOC_AMD_COMMON_BLOCK_TSCFelix Held
All AMD SoCs with Zen-based CPU cores are already using timestamps based on the TSC counter, so use the existing common infrastructure instead of reimplementing it in a similar way. The behavior of the code changes slightly, but results in identical timestamps. The timestamp_get implementation in soc/amd/common/block/cpu divided the result of rdtscll() in timestamp_get by the result of tsc_freq_mhz() and didn't override the weak timestamp_tick_freq_mhz implementation that returns 1. The non AMD specific code returns the result of rdtscll() in timestamp_get, but returns tsc_freq_mhz() instead of 1 in timestamp_tick_freq_mhz, so we still get the correct timestamps. TEST=The raw timestamps printed on the serial console are now multiplied by the expected factor of the TSC frequency in MHz. TEST=Normalized timestamps printed on the serial console by the x86 code don't change significantly on Mandolin when comparing before and after this patch. A slight variation in the timestamps is expected. An example would be: Before: CPU_CLUSTER: 0 init finished in 630 msecs After: CPU_CLUSTER: 0 init finished in 629 msecs TEST=The calculations of the time spent in verstage on PSP before entering the bootblock on Guybrush result in similar times when multiplying the value before the patch with the TSC frequency in the case with the patch applied. The raw values printed on the serial console by the verstage on PSP use the 1us time base, but the timestamp logs that end up in CBMEM will be fixed up to use the same time base as the x86 part of coreboot. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I57b732e5c78222d278d3328b26bb8decb8f4783e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74016 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-03-30drivers/intel/fsp2_0/hand_off_block: use cb_err in fsp_find_range_hobFelix Held
Use enum cb_err as return value of fsp_find_range_hob instead of using the raw -1 and 0 values. Also update the call sites accordingly. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id6c9f69a886f53868f1ef543c8fa04be95381f53 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74082 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-30soc/amd/common/block/cpu/noncar/memmap: simplify return value checkFelix Held
Since the return value of the fsp_find_range_hob call is only used in one location, move the call and return value check into the if condition block to not need the status variable. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4b9e9251368b86382dc4e050cf176db79dbfb230 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74081 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-29soc/amd/common/acpi/cpu_power_state: introduce & use get_pstate_latencyFelix Held
On the Zen-based CPUs, the transition and bus master latency are always written as 0, but on but on Stoneyridge hardware-dependent values are used. Introduce get_pstate_latency that returns 0 for all non-CAR AMD CPUs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I81086fa64909c7350b3b171ea6ea9b46f1708f67 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74024 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/acpi/cpu_power_state: introduce and use get_pstate_0_regFelix Held
On the Zen-based CPUs, P state 0 corresponds to the first P state MSR, but on Stoneyridge this isn't the case. Introduce get_pstate_0_reg that returns 0 for all non-CAR AMD CPUs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icc11e5b6099d37edb934e66fe329d8013d25f68d Reviewed-on: https://review.coreboot.org/c/coreboot/+/74021 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/acpi/cpu_power_state: factor out get_visible_pstate_countFelix Held
Factor out the MSR access into a function with a more descriptive name. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I331c3205390edcbd8749b2d52b7cc7ac3a8ced5a Reviewed-on: https://review.coreboot.org/c/coreboot/+/74020 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/block/cpu/Kconfig: drop FAM17H_19H suffix from TSC optionFelix Held
The SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option is valid for all SoCs with Zen-based CPU cores including the family 1Ah, so remove the suffix. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I58d29e69a44b7b97fa5cfeb0e461531b926f7480 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74015 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/block/cpu/tsc_freq: move static variable inside functionFelix Held
Move the static mhz variable inside the only function that is accessing it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ief98c0a1c35fe1bbc4ff38dd175f12e0b3ddc515 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74014 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/block/cpu/tsc/tsc_freq: use get_pstate_core_freqFelix Held
Use get_pstate_core_freq instead of open-coding the calculations in tsc_freq_mhz. In the case of the CPU frequency divider being 0, get_pstate_core_freq will return 0; in this case that shouldn't happen, TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC frequency it's better to err on the end of the expected frequency being too high which will cause longer than expected delays instead of too short delays. Now that the code is using get_pstate_core_freq, this code is valid for Glinda too, so also remove the comment on the SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda Kconfig. This Kconfig option will be renamed in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/cpu/tsc: add get_pstate_core_freq for family 15h and 16hFelix Held
This function will be used in follow-up patches for both the TSC rate calculation and the still to be implemented P state ACPI table generation in coreboot. The was checked against BKDG 52740 Rev 3.05, BKDG #55072 Rev 3.04, and BKDG #50742 Rev 3.08. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9afaa044da994d330c3e546b774eb1f82e4f30e4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74011 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/cpu/tsc: factor out family-specific get_pstate_core_freqFelix Held
Factor out the get_pstate_core_freq function from the SoC's acpi.c files to both avoid duplication and to also be able to use the same function in the TSC frequency calculation in a follow-up patch. The family 17h and 19h SoCs use the same frequency encoding in the P state MSRs while the family 1Ah SoCs use a different encoding. The family 15h and 16h SoCs use another encoding, but since this isn't implemented in Stoneyridge's acpi.c, this will be added in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-27soc/amd/common/block/cpu/Makefile: group build targets by stageFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idb6087dc44e76ab63bc6b462c3328c23d83ae018 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74009 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd/common/block/cpu/svi2: drop unneeded core_vid checkFelix Held
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core VID is only 8 bit long. In order for making it more difficult to use this function in a wrong way that results in a very wrong voltage being returned, also return 0 for those invalid core VID values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: factor out common get_pstate_core_power implementationFelix Held
Now that all get_pstate_core_power implementations in each SoC's acpi.c file is identical, factor it out into a common implementation. This implementation will also work for Stoneyridge which isn't using the common P state code yet. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_pstate_core_uvolts for SVI2 and SVI3Felix Held
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage ID version specific function is needed to get the raw core VID value. This will allow making get_pstate_core_power common for all AMD CPUs in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_uvolts_from_vid for SVI2 and SVI3Felix Held
Instead of implementing the conversion from the raw serial voltage ID value to the voltage in microvolts in every SoC, introduce the SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the correct version, implement get_uvolts_from_vid for both cases and only include the selected implementation in the build. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I344641217e6e4654fd281d434b88e346e0482f57 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-25soc/amd/common/include/cppc: remove cppc_config forward declarationFelix Held
The included acpi/acpigen.h provides the cppc_config struct and nothing in this header file is using the cppc_config struct. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia91fd4105e6872d812f595447783d02a0dd1568b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73993 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-25soc/amd/common/include/cppc: rename include guardFelix Held
When the code was made common in commit 8f7f4bf87a23 ("soc/amd/cezanne, common: factor out CPPC code to common AMD SoC code"), the include guard wasn't renamed accordingly, so do that now. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9eefe2065fae31e97aa4e6710008a6f9712bed40 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73992 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-24soc/amd: pass pstate_msr union to get_pstate_core_[freq,power]Felix Held
Since we already have and use the pstate_msr union in get_pstate_info, also pass it directly to the get_pstate_core_freq and get_pstate_core_power function calls avoids having to sort-of convert the msr_t type parameter in the implementations of those two functions. In amdblocks/cpu.h a forward declaration of the pstate_msr union is used since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include amdblocks/cpu.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-23soc/amd/common/block/acpi/cpu_power_state: use pstate_msr unionFelix Held
Use the pstate_msr union in get_pstate_info to check if the P state enable bit is set. Also drop the now unused PSTATE_DEF_HI_ENABLE_SHIFT and PSTATE_DEF_HI_ENABLE_MASK definitions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I79119e09af79a4bb680a18e93b4a61a049f0080e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73925 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-03-15soc/amd: Print amdfwtool debug info if V=1Martin Roth
When doing coreboot builds, we can set V=1 to see all of the make info printed as the compile is happening. Use this flag to set the debug flag for amdfwtool so it doesn't have to be enabled separately. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-03-15soc/amd/common: Ignore * in PSP dependency generationMartin Roth
The regex getting rid of lines containing a '*' didn't match anything in any configs, so get rid of it. There's nothing in the amdfwtool dataparse.c file that would match it either. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I05aaf46cfb479cebab9234a47574073335984a5f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73669 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-15soc/amd/common: Update PSP dependency generationMartin Roth
After adding the ability to add paths into the amdfw.cfg file for the amdfwtool, the dependency generation needs to be updated to not add the firmware location in front of those values. This also allows us to filter out the MP2 binaries as dependencies based on whether or not the Kconfig value is set. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I3a9b9c8246808dc60020a32a7d9d926bc5e57ccd Reviewed-on: https://review.coreboot.org/c/coreboot/+/73657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-13soc/amd/common/block/cpu/update_microcode: use raw MSR dataFelix Held
Since mst_t is a union of the struct containing the lower and higher 32 bits and the raw 64 bit value, the address of the microcode update can be directly written to the raw value instead of needing to split it into the lower and higher 32 bits and assigning those separately. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I51c84164e81477040a4b7810552d3d65c0e3656b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73636 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-13soc/amd/common/block/cpu/noncar/write_resume_eip: use raw MSR dataFelix Held
Since mst_t is a union of the struct containing the lower and higher 32 bits and the raw 64 bit value, the address of the bootblock_resume_entry can be directly written to the raw value instead of needing to split it into the lower and higher 32 bits and assigning those separately. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I7ebab1784ec592e18c29001b1cf3ee7790615bf8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73635 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-10soc/amd/common/psp: Put spl_fuse in separate compilation unitMartin Roth
This separates the SPL fusing function into a separate C file which can be excluded if it is not needed. This allows the psp_set_spl_fuse() function to be made static again as the state of the function will always match the boot_state entry. Move the required #defines to the common header file so they can be used by both psp_gen2.c & spl_fuse.c. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ifbc774a370dd35a5c1e82f271816e8a036745ad5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73655 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-10soc/amd/common/cpu/smm/smm_relocate: don't assume TSEG is below 4GBFelix Held
Even though right now TSEG will always be located below 4GB, better not make assumptions in the SMM relocation code. Instead of clearing the higher 32 bits and just assigning the TSEG base and per-core SMM base to the lower 32 bits of the MSR, assign those two base addresses to the raw 64 bit MSR value to not truncate the base addresses. Since TSEG will realistically never be larger than 4GB and it needs to be aligned to its power-of-two size, the TSEG mask still only needs to affect the lower half of the corresponding MSR value. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1004b5e05a7dba83b76b93b3e7152aef7db58f4d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-03-10soc/amd/common/block/psp/psp_smm: use raw MSR dataFelix Held
Since mst_t is a union of the struct containing the lower and higher 32 bits and the raw 64 bit value, there's no need to convert the lower and higher 32 bits into a 64 bit value and we can just use the 64 bit raw value. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5923df84f0eb3a28ba6eda4a06c7421f4459e560 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73638 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-03-09soc/amd/common/cpu: move get_threads_per_core from noncar to common codeFelix Held
The get_threads_per_core function isn't specific to the non-CAR CPUs and also applies for Stoneyridge and even for family 16h model 30h outside of soc/amd, so move it from the non-CAR-specific cpu.c file to the common AMD SoC cpu.c file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I05946f163112ff93f33139f6c43fed5820fd0a3c Reviewed-on: https://review.coreboot.org/c/coreboot/+/73615 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-09soc/amd/common/cpu/Kconfig: use Cxxx as CPU string for all non-CAR SoCsFelix Held
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it being what the AGESA reference code uses. We initially relied on the AGESA/FSP generated SSDT for the P- and C-state support before we had a native implementation for this in coreboot. The Cxxx naming scheme can also be used for the other AMD SoCs except Stoneyridge which is pre-Zen and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of using Cxxx instead of CPxx is that the Cxxx scheme supports systems with more than 256 CPU threads. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-09soc/amd/common/xhci: Add support for logging XHCI wake eventsRobert Zieba
AMD SoCs currently only log the GPE# when an XHCI controller wakes the system. Add code to log XHCI wake events to the elog. BRANCH=guybrush BUG=b:186792595 TEST=builds Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58 Signed-off-by: Robert Zieba <robertzieba@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-03-08soc/amd/common/psp: Check more error bits before SPL fusingMartin Roth
This adds checks for three more error bits before requesting that the SPL fuses are updated. - While I'm here, I'm adding the include of types.h which was previously done through other include files, but should be done independently. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-03-08soc/amd/common/psp: Only set SPL fuses if an SPL file is presentMartin Roth
Use the presence of an SPL (Software Patch Level) file to trigger the function that reads and writes the SPL fuses. The current Kconfig option will be used to decide to write the fuses. This allows us to see the state of the SPL update bit which determines whether or not SPL fusing is allowed and needed before enabling the fusing. - Refactor a bit to prepare for following changes. - Update phrasing Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-03-08soc/amd: factor out ACPI_SSDT_PSD_INDEPENDENT to common AMD ACPI KconfigFelix Held
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the Kconfig symbol to the Kconfig file in this directory. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/common/block/acpi/cpu_power_state: introduce get_cstate_io_baseFelix Held
Introduce the get_cstate_io_base helper function that write_cstate_entry can call directly to get the C state control IO base address instead of having get_cstate_info pass this Io address to each write_cstate_entry call. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: I4cc80ded0a2fbc2dee9ca819e86284d9ffd58685 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73533 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-08soc/amd/include/msr: factor out P state MSR enable bit to cpu/amd/msr.hFelix Held
The bit position of the P state enable bit in the 8 P state MSRs is identical for all AMD chips including the family 16h model 30h APU that lives outside of soc/amd. The other bits in those 8 MSRs are more or less family- and model-specific. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-08soc/amd/*/acpi: factor out common get_pstate_info implementationFelix Held
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. The SoC-specific get_pstate_core_freq and get_pstate_core_power functions remain in the SoC-specific code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/*/acpi: factor out common generate_cpu_entries implementationFelix Held
With the exception of the generate_cppc_entries call, the implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. Since all SoCs that support CPPC already select the SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only call generate_cppc_entries for platforms where it is available. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/common/block/acpi/cpu_power_state: use definition for bit_offsetFelix Held
Instead of using a magic constant in the bit_offset field of the C state resource for the C1 state that's entered via the MWAIT instruction, use the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by acpi_processor_ffh_cstate_probe in the Linux kernel. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/common/block/acpi/cpu_power_state: add get_cstate_info helperFelix Held
Introduce the get_cstate_info helper function that populates the caller- provided cstate_values array with the data returned by the SoC-specific get_cstate_config_data function. From the array get_cstate_config_data returns, only the ctype, latency and power fields are used, so the rest can be left uninitialized. Those 3 fields are compile-time constants. For each entry, write_cstate_entry will generate the corresponding resource information from the given data. In the C1 case where ctype is 1, the state is entered via a MWAIT instruction, while the higher C states are entered by doing an IO read from a specific IO address. This IO address is x - 1 bytes into the IO region starting at MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by reading from the C state IO base address + 1. This resource information is generated during runtime, since the contents of MSR_CSTATE_ADDRESS aren't necessarily known at compile-time. MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass a buffer with space for the maximum number of C state entries. This maximum number corresponds to the number of IO addresses the CPU traps beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more than 3 or maybe 4 C states will be available though. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-07soc/amd/stoneyridge: request binaryPI to use \_SB_ scope in PSTATE SSDTFelix Held
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the scope for the CPU objects and patching this SSDT in coreboot to use the \_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the \_SB_ scope instead by setting the late platform configuration option ProcessorScopeInSb to true. TEST=Careena still boots and Linux doesn't show any ACPI errors with this patch applied. With only patch_ssdt_processor_scope removed, but the ProcessorScopeInSb option not set, Linux will complain that it can't resolve the \PR.P00x symbols. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-06soc/amd: rename ACPI_CPU_CONTROL to ACPI_CSTATE_CONTROL for non-CAR CPUsFelix Held
The legacy ACPI CPU control registers in IO space where the first 4 IO locations control the CPU throttling value don't exist any more on the Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS in set_cstate_io_addr which will cause accesses from the 8 IO addresses beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads from those IO addresses will cause the CPU to enter low C states. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-02soc/amd/mendocino: Add new 'STT_ALPHA_APU' parameter for DPTC supportChris Wang
Add a new parameter STT_ALPHA_APU' for each DPTC mode. BUG=b:257149501 BRANCH=None TEST=Check if the STT value matches the expected setting. Change-Id: Ib27572712d57585f66030d9e927896a8249e97a7 Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73123 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com> Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
2023-02-28soc/amd: introduce and use PSTATE_MSR macroFelix Held
Instead of adding the P-state number to the PSTATE_0_MSR number to get the P-state MSR number for the rdmsr call, provide a macro that directly calculates the MSR number for a given power state. Also drop the unused PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs available in the hardware. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-02-28soc/amd/common/block/apob/apob_cache: use enum cb_errFelix Held
Use enum cb_err to return an error/success state instead of an int in get_nv_rdev and get_nv_rdev_rw. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I73706a93bc1dbc8556e11885faf7f486c468bea9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73317 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/common/block/apob/apob_cache: include types.hFelix Held
The bool type is used although stdbool.h isn't included. Include types.h which will include both stdint.h and stdbool.h Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5213ddae3ceb36e0b2e09f8ef3f7f414ebdf187f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73316 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-27soc/amd/common/block/apob_cache: Add support for RECOVERY_MRC_CACHEKarthikeyan Ramasubramanian
If a mainboard has RECOVERY_MRC_CACHE and the recovery mode is enabled, then use APOB data from that section and make any updates to that section. Otherwise continue to use DEFAULT_MRC_CACHE section. BUG=b:270569389 TEST=Build and boot to OS in Skyrim. When in normal mode, DEFAULT_MRC_CACHE is used. Normal Mode Boot1: ------------------ [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [INFO ] APOB RAM hash differs from flash [SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x0/0x1e000 [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] SF: Successfully erased 122880 bytes @ 0x0 [INFO ] Updated APOB in flash Normal Mode Boot2: ----------------- [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] APOB hash matches flash When the device is in recovery mode, RECOVERY_MRC_CACHE is used. Recovery Mode Boot1: -------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [INFO ] APOB RAM hash differs from flash [SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x650000/0x1e000 [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] SF: Successfully erased 122880 bytes @ 0x650000 [INFO ] Updated APOB in flash Recovery Mode Boot2: -------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] APOB hash matches flash Switch from Recovery Mode to Normal Mode: ----------------------------------------- [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] APOB hash matches flash Switch from Normal Mode to Recovery Mode: ----------------------------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] APOB hash matches flash Change-Id: I93f357e407c98b6e5fca495f4f779fad54a3430f Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73168 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/fsp/dmi.c: Fill in mem manufacturer from CBIMartin Roth
Because the ChromeOS boards don't fill a manufacturer in for the memory SPDs, that information isn't available from the FSP. We can get the Manufacturer ID based on the memory name from CBI instead. Use this information to fill in an ID so that the manufacturer name is available in the SMBIOS information. BUG=None TEST=Look at dmidecode output Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I810c3191180dd3b566d7ea64006f29b625b10526 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73255 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/fsp/dmi.c: Add dmi_type16 ECC to memory structMartin Roth
The DMI error correction type was not being filled in, so was reporting as "Error Correction Type: <OUT OF SPEC>". This patch fixes that. Since it's now filling in information for both Type 16 & 17, rename the function to reflect that. BUG=None TEST=dmidecode now reports the type correctly. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I6b51612d808c63de1acd2be952cb6c152f8a1be5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73253 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/block/simnow: Add SimNow Kconfig optionsFred Reitberger
Add option for mainboards to target builds for SimNow. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Id765437b69f1bc3a9f9d7858edcd27e687d5a7f3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73164 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-23soc/amd/commmon/gfx: Generalize check for selective GOP initMatt DeVillier
Rather than explicitly checking for Recovery or Developer mode via vboot, use display_init_required() so that vboot is not required, and other instances where the display is needed pre-OS (such as when applying a critical system update) are covered as well. With this change, SoCs implementing selective GOP init will need to select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required() to not assert on compilation. BUG=b:255812886 TEST=build/boot skyrim Change-Id: Iac7e06863764a9f21c8a50fc19050cb5a6627df2 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73046 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-20soc/amd/common/include/psp_efs: rename new PSP directory EFS entryFelix Held
The EFS entry at offset 0x14 can point to either the first level PSP directory table or to the PSP combo directory structure that was used before the introduction of the AMD A/B recovery scheme. This scheme is not to be confused with the VBOOT scheme. The PSP verstage code checks if the header this entry points to begins with the PSP_COOKIE, which indicates the entry is a first level PSP directory table. Due to that, the EFS entry at offset 0x14 is always expected to point to a PSP directory table, so rename combo_psp_directory to new_psp_directory to match the actual usage. This EFS entry that points to the PSP directory table is called new_psp_directory, since the entry at EFS offset 0x10 was used on some early AMD chips to point to the older PSP directory table and that one is already called psp_directory. amdfwtool uses the same naming scheme for those two PSP directory table pointers. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I10f19ee63f8d422433dba64402d84fd6bb9e0f9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73083 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-16soc/amd/common: Add die_no_apcbFred Reitberger
Add target to die when no APCB is found. This is not always a fatal case, so mainboards can select between this and warn_no_apcb. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I5bbc8dd3200c4781677411e67a4b5f1fe8b20286 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73005 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-15soc/amd/common: Move missing APCB warning to common areaFred Reitberger
Move missing APCB warning from birman to amd/common so that other mainboards can utilize the same warnings if the APCB is missing. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I7ae689726ae4f7ccdf6959e47cbb5aee15cdb690 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-15soc/amd/common/Makefile.inc: Extend if case coverageFred Reitberger
Extend the coverage of the 'ifeq ($(CONFIG_SOC_AMD_COMMON),y)' case to the entire file. This matches the coverage of the related Kconfig. Add comments to endif to show which if they are ending. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I369e23e7ee9463ca1ae487d1e2181c760ae1bab2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70208 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-13soc/amd/common/block/gfx: Use TPM-stored hash for vbios cache validationMatt DeVillier
Write the SHA256 hash of the cached VBIOS data when saving to FMAP, and use it to validate the data read from FMAP on subsequent boots. Add TPM2 as a dependency to the selection of VBIOS_CACHE_IN_FMAP. BUG=b:255812886 TEST=tested with rest of patch train Change-Id: I9c8f23b000b90a1072aeb7a57d3b7b2b2bc626dc Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72402 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-13soc/amd/common/Makefile: Only run amdfwread onceFred Reitberger
By saving the results of amdfwread into a file, it only needs to be run once instead of every time amdfwread-offset-size-cmd is called. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I1afaf65b9b2f9fb856aefc3ff37fb3a3442f6369 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72924 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-13soc/amd/common/block/acpi.ivrs: use SMBUS_DEVFN for FCH IOAPIC device IDFelix Held
Instead of using PCI_DEVFN(SMBUS_DEV, SMBUS_FUNC), use the equivalent SMBUS_DEVFN define. Even though the FCH IOAPIC is in the LPC part of the FCH, it needs the IVRS IOAPIC table's source_dev_id field set to SMBUS_DEVFN which is the function 0 of the FCH PCI device. LPC is function 3 of the FCH device. When assigning LPC_DEVFN to source_dev_id, the kernel from Ubuntu 2022.04 LTS complains about the IOAPIC part of the IVRS table being wrong: AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found AMD-Vi: Disabling interrupt remapping With SMBUS_DEVFN being used as source_dev_id, no such error is reported. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: I8470d67b2513031e75fb422d4c1c181e017ace0a Reviewed-on: https://review.coreboot.org/c/coreboot/+/70503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-02-11soc/amd/*: Add SOC_NAME in fw.cfg(s)Zheng Bao
2/5 of split changes of https://review.coreboot.org/c/coreboot/+/58552/28 Change-Id: I18f73462a3995038fe93750320dfc053fec969ba Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-10soc/amd/common/gfx: add support for VBIOS caching, selective GOP initMatt DeVillier
One of the main functions performed by the FSP GOP driver is to modify the ATOMBIOS tables (part of the VBIOS) in memory based on the display output configuration. This device-specific modified VBIOS can be cached in a FMAP region specific for that purpose, then loaded into memory instead of the "generic" VBIOS, saving the ~130ms execution time of the GOP driver. As this approach only works when no pre-OS display output is needed, limit its use to ChromeOS builds, with the GOP driver enabled, and not booting in either recovery or developer modes. SoCs supporting this feature will need to selectively run the FSP GOP driver as needed, using the same criteria used here to determine whether to load the VBIOS from CBFS or from the FMAP cache. Boards utilizing this feature will need to add a dedicated FMAP region with the appropriate name/size, and select the required Kconfig options. BUG=b:255812886 TEST=tested with rest of patch train Change-Id: Ib9cfd192500d411655a3c8fa436098897428109e Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com>
2023-02-09console: Add SimNow console loggingFred Reitberger
The AMD SimNow tool supports fast logging through an IO port. Add a new console to support SimNow logging through port 80. TEST=observe significant speed improvements on SimNow console log Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I42a431f48ea14ba4adacbd4a32e15abe7c5e4951 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72751 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-08soc/amd/common/data_fabric: print decoded control register contentsFelix Held
Since all SoCs define the df_mmio_control union for the bits used in the code, data_fabric_print_mmio_conf can take advantage of that and also print a decoded version of those bits. Output on Mandolin before the patch: === Data Fabric MMIO configuration registers === idx control base limit 0 93 fc000000 febfffff 1 93 10000000000 ffffffffffff 2 93 d0000000 f7ffffff 3 1093 fed00000 fedfffff 4 90 0 ffff 5 90 0 ffff 6 90 0 ffff 7 90 0 ffff Output on Mandolin with the patch: === Data Fabric MMIO configuration registers === idx base limit control R W NP F-ID 0 fc000000 febfffff 93 x x 9 1 10000000000 ffffffffffff 93 x x 9 2 d0000000 f7ffffff 93 x x 9 3 fed00000 fedfffff 1093 x x x 9 4 0 ffff 90 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I06e1d3a3e9abd664f59f2bb852394e7f723f2b30 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/*/data_fabric: introduce and use DF_MMIO_REG_SET_SIZEFelix Held
To be able to handle a special case, add a per-SoC define for DF_MMIO_REG_SET_SIZE instead of having this hard-coded as 4 in the DF_MMIO_* macros. To avoid some duplication, also introduce the DF_MMIO_REG_OFFSET macro. TEST=Output from data_fabric_print_mmio_conf doesn't change on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I67420a2973c8ef9a7f0ce19ddc0013de69731689 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72878 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/common/data_fabric: replace NB with DF prefix for DF registersFelix Held
Since the MMIO decode range registers in the data fabric are part of the data fabric and not of the northbridge, replace the NB prefix with a DF prefix to make this a bit clearer. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ife5e4581752825e9224b50252955d485a067af74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72877 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/*/data_fabric: rename define for MMIO decode register set countFelix Held
This should make it a bit clearer that those registers are in the data fabric configuration registers. Also move those defines right after the register definition those are related to. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic107bd217f4af0a9ddfbe41aafd3c882aa968e22 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72876 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-07soc/amd/common/data_fabric_helper: normalize addresses in debug printFelix Held
Instead of just printing the register contents, normalize the contents of the base and limit registers to actual MMIO addresses and then print those. This will hopefully avoid some confusion caused by the shifted addresses. Output on Mandolin before the patch: === Data Fabric MMIO configuration registers === Addresses are shifted to the right by 16 bits. idx control base limit 0 93 fc00 febf 1 93 1000000 ffffffff 2 93 d000 f7ff 3 1093 fed0 fedf 4 90 0 0 5 90 0 0 6 90 0 0 7 90 0 0 Output on Mandolin after the patch: === Data Fabric MMIO configuration registers === idx control base limit 0 93 fc000000 febfffff 1 93 10000000000 ffffffffffff 2 93 d0000000 f7ffffff 3 1093 fed00000 fedfffff 4 90 0 ffff 5 90 0 ffff 6 90 0 ffff 7 90 0 ffff Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I62eeb88ddac6a7a421fccc8e433523459117976a Reviewed-on: https://review.coreboot.org/c/coreboot/+/72739 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-04soc/amd: Create AMD common reset codeMartin Roth
This allows us to use the same file for PCO, CZN, MDN, PHX, & Glinda. PCO supports the warm reset, and future chips can support it by setting the SOC_AMD_SUPPORTS_WARM_RESET option. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ib6459e7ab82aacbe57b4c2fc5bbb3759dc5266f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72658 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-01treewide: Remove duplicated include <device/pci.h>Elyes Haouas
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>. Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-31soc/amd/common/block/include/acpi: drop MMIO_ACPI_CPU_CONTROL defineFelix Held
This register isn't used in coreboot and isn't defined in the Picasso PPR #55570 Rev 3.18. To enter a lower C-state, a read request to a special IO port is done. The base address of this group of IO ports is configured in set_cstate_io_addr via the MSR_CSTATE_ADDRESS and that read won't leave the CPU. IIRC trying to put the MMIO mapping for entering the lower C-states into the _CST package didn't work as expected when it was tried on I think Cezanne. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib189993879feaa0a22f6810c4bd5c1a0bc8c5a27 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-01-22soc/amd/*: Enable override of MAINBOARD_BLOBS_DIRFred Reitberger
MAINBOARD_BLOBS_DIR is defined the same way by picasso/cezanne/mendocino/phoenix/glinda and unused by stoneyridge, so move it to a common area. This makefile variable is currently only used to locate APCB blobs for the different mainboards. Add a Kconfig option to point to the APCB blobs directory. This allows simple overriding to locations such as site-local. TEST=Timeless builds Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I0702fdb97fbc2c73d97994ab4d5161ff0f467518 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69410 Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-18soc/amd/common/block/acpi/cppc: drop outdated commentFelix Held
Since commit d5ab24cd4800 ("soc/amd/common/acpi/cppc: add nominal and minimum frequencies") the fields that got added in CPPC version 3 get populated, so remove the now outdated comment about the fields added in version 3 always being set to CPPC_UNSUPPORTED. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4c975b42fc4f67329170801b871d6bbdf9637d04 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72046 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-01-18soc/amd: Include <gpio.h> instead of <soc/gpio.h>Elyes Haouas
<gpio.h> chain-include <soc/gpio.h>. Change-Id: I112e41ad4c7ee638954dfe3f1ddfeb10c138459a Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71807 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-17soc/amd: introduce and use common amd_cpu_bus_ops structFelix Held
The device operations for the CPU bus are identical for all AMD SoCs, so introduce a common device operations struct for this and use it in all AMD SoC's chipset devicetrees as ops for the CPU cluster. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id32f89b8a33db8dbb747b917eeac3009fbae6631 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71998 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-15soc/amd/mendocino: PSP_INCLUDES_HSPKarthikeyan Ramasubramanian
Select HSP config to indicate that the SoC includes Hardware Security Processor. This will allow PSP verstage to get and report the HSP state. BUG=None TEST=Build Skyrim BIOS image and boot to ChromeOS on Skyrim. Verify that HSP is reported during the boot sequence. Change-Id: I22446c2bd6202529367da040c09449e6b26f9d7a Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71209 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>