summaryrefslogtreecommitdiff
path: root/src/soc/amd/common/block
AgeCommit message (Collapse)Author
2023-07-31soc/amd/common/cpu: Add Kconfig to program the PSP_ADDR MSRMatt DeVillier
The PSP_ADDR_MSR is programmed into the BSP by FSP, but not always propagated to the other cores/APs. Add a hook to run a function which will read the MSR value from the BSP, and program it into the APs, guarded by a Kconfig. SoCs which wish to utilize this feature can select the Kconfig. BUG=b:293571109 BRANCH=skyrim TEST=tested with rest of patch train Change-Id: I14af1a092965254979df404d8d7d9a28a15b44b8 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76808 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-07-30soc/amd/common/data_fabric/domain: skip reserved resources for ACPIFelix Held
The non-PCI resources added to the domain device are resource consumers, so they mustn't be reported as resource producers. To make sure that this is the case, skip all resources that have the IORESOURCE_RESERVE flag set in amd_pci_domain_fill_ssdt. Commit 7a5dd781d147 ("soc/amd/common/data_fabric/domain: provide amd_pci_domain_fill_ssdt") that introduced amd_pci_domain_fill_ssdt already contained the bug, but since no MMIO range consumers were added back then, the bug only became visible when commit 32169720bb67 ("soc/amd/common/data_fabric/domain: report non-PCI MMIO resources") added the reserved non-PCI MMIO resources to the domain device's resources resulting in MMIO producer objects being generated for MMIO consumers. Those producers that should have been consumers then overlapped with the actual MMIO resource producers which caused Windows to BSOD with an ACPI_BIOS_ERROR. TEST=The non-PCI MMIO resources are no longer added as resource producers and Windows boots again on google/frostflow. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: Matt DeVillier <matt.devillier@gmail.com> Change-Id: Ib099675bc5bea93bf7c2a80f741bef067fd37a58 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76818 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-30soc/amd/common/data_fabric/domain: continue after unassigned resourceFelix Held
When iterating over the resource list in amd_pci_domain_fill_ssdt, don't return when a resource is unassigned, but just continue to the next loop iteration so the resulting SSDT will be complete and not broken due to a missing resource template footer and the scope not being closed. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I39fe516f27a6d971fb9c57a1e64ead79d23aff08 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76817 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-28soc/amd/commonn/block/include/psp_efs.h: Remove unused functionFred Reitberger
Commit 49d8aa7043ea ("soc/amd/common/block/psp: Unmap EFS region after use") removed the 'efs_is_valid' function but left the function signature in the header file. TEST=stoney/picasso/cezanne/mendocino/phoenix builds Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ib596946679b50be63868af57e3428b4d65845419 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76750 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-27soc/amd/noncar/memlayout_x86.ld: Conditionally add fspm regionFelix Held
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1e75f29a52179b72b25092f0ffdfd91a182d6648 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76471 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-27soc/amd/noncar/memlayout_x86.ld: Move ramstage link addressArthur Heymans
This address is more certain to not collide with other symbols. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I02eddf43a00c443a1193d6db77d6fad3715216f3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76494 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-27soc/amd/noncar/memmap.c: Support non-FSP use casesFelix Held
Without FSP we assume TSEG is right above CBMEM. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8700803617c3fe4890e497c6d7b94f1d36e21cb4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76472 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-27soc/amd/noncar/memmap.c: factor out FSP-specific SMM region codeFelix Held
Factor out the common FSP-specific code to get the location and size of the SMM region from the HOB that FSP has put into memory. This moves FSP-specific code out of the common AMD SoC code into the FSP-specific common AMD SoC code folder. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie137bb0f4e7438a1694810ae71592a34f9d8c86e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76760 Reviewed-by: Martin L Roth <gaumless@gmail.com> 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-07-27soc/amd/common/fsp: factor out read_fsp_resources from root_complex.cFelix Held
Factor out the common FSP-specific code to report the usable and reserved memory resources read from the HOBs that FSP has put into memory. This both reduces code duplication and also moves FSP-specific code out of the SoC code into the FSP-specific common AMD SoC code folder. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib373c52030209235559c9cd383f48ee1b3f8f79b Reviewed-on: https://review.coreboot.org/c/coreboot/+/76759 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-27soc/amd/cpu.c: Conditionally define .acpi_fill_ssdtFelix Held
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I0e81c08191f3c5f768bd3cad0e4915d4476c739f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76493 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/*/root_complex: introduce and use SMN_IOHC_MISC_BASE_13B1Felix Held
On the mobile SoCs, SMN_IOHC_MISC_BASE_13B1 is the only IOHC misc base address, but on for example Genoa it's the address of the IOHC misc base of the second IOHC. Due to it not being the first one on Genoa, use 13B1 as part of the name instead of using an index of 0 which would look odd in the Genoa case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1db28ec03a3ba1c2040d8a1500ae17aa9705f6e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76756 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> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/common/acpi/ivrs: probe IOAPIC device on domain deviceFelix Held
This reverts commit e33d253793f6 ("soc/amd/common/block/acpi/ivrs: fix missing IOAPIC[1] error"). Now that the per PCI root domain IOAPIC MMIO resource is reported on the domain device, we can again probe the resource on the domain device instead of the northbridge PCI device in that domain. This will make the IVRS code compatible again with the work in progress Genoa SoC support. TEST=Linux doesn't complain about the IOAPIC[1] missing in the IVRS on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib861b19d798fc8ee6603e8803d8d1939be08d275 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76659 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/common/data_fabric/domain: report non-PCI MMIO resourcesFelix Held
Call read_non_pci_resources from amd_pci_domain_read_resources to tell the resource allocator about the non-PCI MMIO regions within the data fabric MMIO regions so that the allocator won't place any PCI MMIO in the same areas. TEST=On Mandolin 3 new non-PCI resources get reported to the allocator: avoid_fixed_resources: DOMAIN: 0000 04 base fd100000 limit fd1fffff mem (fixed) avoid_fixed_resources: DOMAIN: 0000 05 base fd000000 limit fd0fffff mem (fixed) avoid_fixed_resources: DOMAIN: 0000 20000120 base fec01000 limit fec01fff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7f69b86e376e3368d4f156ccf93791cc00886489 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76599 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> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-25soc/amd/common/root_complex: add function to report non-PCI resourcesFelix Held
Introduce the common read_non_pci_resources function to read the base address of the non-PCI resources within the MMIO regions configured in the data fabric registers and pass that info to the resource allocator. Each SoC will need to provide implementations for get_iohc_misc_smn_base and get_iohc_non_pci_mmio_regs in order for read_non_pci_resources to know the SoC-specific base addresses, register offsets and MMIO region sizes. In case of SoCs with only one PCI root domain, the domain parameter of get_iohc_misc_smn_base will be unused, but in the case of SoCs with more than one PCI root domains, this parameter will be used by the SoC-specific code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9aca67fa0f5a0d504371367aaae5908bcb17dd9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76553 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-07-24soc/amd/common/block/apob: Add Kconfig option to disable APOB NVFred Reitberger
Add Kconfig option to disable the non-volatile APOB cache for a mainboard using an SOC that supports APOB. BUG=b:290763369 TEST=verify APOB cache is disabled when selected Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I0170355bbf29ea6386fa69a318e61f057b9a9a3f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76566 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-20soc/amd/common/smn/Kconfig: expand SMN acronymFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icce4092f1e09d492e0faf4b5e85525871614d73d Reviewed-on: https://review.coreboot.org/c/coreboot/+/76607 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-07-20soc/amd/common/block/smn: add smn_read64Felix Held
Add smn_read64 which calls smn_read32 twice to read two adjacent 32 bit SMN registers and merges the results into a 64 bit value which it then returns. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib2d58ec9818559cbefd7b819ae311ad02fafa18f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76552 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-07-17soc/amd/common/acpimmio: factor out IO port access to PM registersFelix Held
Factor out all functions that use the indirect IO port based access to the PM registers into a new compilation unit and only select it on platforms that support this interface. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9c059e450e2137f7e05441ab89c1f0e7077be9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/76458 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>
2023-07-17soc/amd/common/pm/pmlib: use PM register mapping in ACPIMMIO regionFelix Held
In all SoC pm_set_power_failure_state gets called either after a call to enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled after reset on the SoC. This allows to use pm_read8 and pm_write8 that use the ACPIMMIO mapping of the PM registers instead of pm_io_read8 and pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports used on older generations to access to the PM registers not being implemented any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0d0523d2c4920da41b3fb73cf62f22a60f1643a Reviewed-on: https://review.coreboot.org/c/coreboot/+/76463 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-17soc/amd/common/lpc/lpc_util: use PM register mapping in ACPIMMIO regionFelix Held
In all SoC lpc_early_init gets called either after a call to enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled after reset on the SoC. This allows to use pm_read8 and pm_write8 that use the ACPIMMIO mapping of the PM registers to set the PM_LPC_ENABLE bit in the PM_LPC_GATING register instead of pm_io_read8 and pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports used on older generations to access to the PM registers not being implemented any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8b31ec4e03a06796502c89e3c2cfaac2d41b0ed9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76461 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-17soc/amd/common/acpimmio/mmio_util: drop enable_acpimmio_decode_pm24Felix Held
None of the platforms that used enable_acpimmio_decode_pm24 is in the tree any more, so drop this function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iea345a825c4581bf2acb932692ebcad2a7a5b4ed Reviewed-on: https://review.coreboot.org/c/coreboot/+/76457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-07-14soc/amd/common: Add warning if microcode CBFS filename is in useMartin Roth
Because of the way that the CBFS filename is generated from the contents of the microcode patch, if a duplicate microcode patch is included in the build, the makefile would create a second copy of the name, which doesn't work. This led to "odd" results where the other attributes of the first copy were erased, causing cbfstool to fail. The cause of the failure is not immediately obvious, and is a little difficult to track down. This patch causes an immediate failure and gives a reason as to the cause of the issue. When a failure is seen, this is the result: File1: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHXn4_A0.bin File2: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHX4_A0.bin src/soc/amd/common/block/cpu/Makefile.inc:25: *** Error: The cbfs filename "cpu_microcode_a740.bin" is used for both above files. Check your microcode patches for duplicates.. Stop. TEST=Now checked for both positive and negative failures. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I3d34dc5585182545bdcbfa6370ebc34aa767cae2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76423 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-14soc/amd/phoenix: Disable APOB CacheKarthikeyan Ramasubramanian
There is a data abort in ABL when the memory training data is used from APOB Cache. Disable APOB Cache until the cause is identified. The downside of this change is that the memory training happens in every boot cycle. BUG=b:290763369 TEST=Build BIOS image and boot to OS in Myst. Trigger a reboot from AP console and ensure that the system boots to OS. Change-Id: I20f4f40cdaac68bca6e121e3a238d13fe80d0d3c Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76422 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-14mb/google: AMD: move tpm_tis to AMD common codeGrzegorz Bernacki
It moves cr50_plat_irq_status() to common code and adds Kconfig option to specify GPIO used for interrupt. BUG=b:277787305 TEST=Build all affected platform and confirm using right GPIO number. Tested on Skyrim. Change-Id: I775c4e24cffee99b6ac3e05b58a75425029a86c8 Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75621 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-12soc/amd/common: Use newer function for resource declarationsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iad8b7c705d5053700850065f90314444904b5b54 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76289 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-04soc/amd/common/block/acpi/ivrs: use IOMMU PCI register definitionsFelix Held
Use IOMMU_CAP_BASE_[LO,HI] instead of magic values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7032d9f032a22649951ef1535f39b918eb8bd539 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76223 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-07-04soc/amd/common/block/iommu: factor out PCI register definitionsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie155cab1f659e9f7b64cd87ba8a77260056656d8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76222 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-04soc/amd/common/block/uart: remove DRIVERS_UART_8250MEMEric Lai
Select DRIVERS_UART_8250MEM_32 will select DRIVERS_UART_8250MEM too. Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: I87a47e2d76ab7a0717edf725bf94d87f9f2357f1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76184 Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-06-28soc/amd/common/block/acpi/ivrs: fix missing IOAPIC[1] errorFelix Held
When probing the resource with the IOMMU_IOAPIC_IDX index, we need to use the PCI device 0 function 0 on the first bus in the domain for probing and not the domain device, since the resource isn't on the domain device, but on the northbridge device which is B0F0D0 in the case of the APUs. TEST=This fixes the following error on Mandolin with Picasso: AMD-Vi: [Firmware Bug]: : IOAPIC[1] not in IVRS table AMD-Vi: Disabling interrupt remapping Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id88f17d68ba5accef6561837478828bd3d24baa5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76117 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-27soc/amd/block/ivrs: Add NULL check for IVRSNaresh Solanki
Add NULL check for ivrs pointer before use. Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Change-Id: Ibeb0ea3bcaa3512a93500588ad4f11046edee61f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-06-26soc/amd/common/iommu.c: Make sure iommu is enabledArthur Heymans
Don't rely on vendorcode to set enable bit on IOMMU. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Change-Id: I1805a20656b7fb3915f8cc93c618ee074461840f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75829 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-06-26soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_[range,entry]Felix Held
Zero-initialize the ivhd_range and ivhd_entry structs to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iccacc89bfc497449ad0716a3436949505b65f748 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76079 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-26soc/amd/common/block/acpi/ivrs: use size of instance instead of typeFelix Held
To determine the length parameter of memset, use sizeof with the instance as argument instead of the type. The behavior is the same, but it clarifies parameters in the memset call a bit. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I63674fbed7097a583cd77fa6e700652d6dcc5565 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76078 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-26soc/amd/common/block/acpi/ivrs: use memset on ivhd_[11,40]Felix Held
Assign the current address casted to acpi_ivrs_ivhd[11,40]_t pointer to *ivhd_[11,40] at the beginning of acpi_fill_ivrs[11,40] and then use memset on *ivhd_[11,40] to zero-initialize the structs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I70b12fee99d6c71318189ac35e615589a4c8c629 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76077 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-23soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_hpet structFelix Held
Zero-initialize the ivhd_hpet struct right at the beginning of the ivhd_describe_hpet function to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If4d3563c485eed4a7cb0526a62f7b6c80f763bfd Reviewed-on: https://review.coreboot.org/c/coreboot/+/76074 Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-06-23soc/amd/common/acpi/ivrs: add HID argument to ivhd_describe_f0_deviceFelix Held
Allow the caller to specify the HID that gets written to the ivrs_ivhd_f0_entry_t struct. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I830f1fbbd535b100c88997ece10142a5d553950f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76073 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2023-06-23soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_f0 structFelix Held
Zero-initialize the ivhd_f0 struct right at the beginning of the ivhd_describe_f0_device function to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia6750b58dacb9b9192ed21128eb6e3a4495b96d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76072 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2023-06-23soc/amd/common/block/acpi/ivrs: conditionally generate eMMC entryFelix Held
The eMMC entry in the IVRS table should only be generated if an eMMC controller is present in the SoC. Where the PCI_DEVFN(0x13, 1) is from is currently unclear to me. There is no PCI device 0x13 on bus 0 and the eMMC controller is also an MMIO device and not a PCI device, but this is what the reference code does. My guess would be that it mainly needs to be a unique PCI device that won't collide with any existing PCI device in the SoC. Add a comment about this too. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I00865cb7caf82547e89eb5e77817e3d8ca5d35dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/75933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-23Makefile.inc: don't add fmap_config.h dependency twiceFelix Held
Commit d054bbd4f1ba ("Makefile.inc: fix multiple jobs build issue") added a dependency on $(obj)/fmap_config.h to all .c source files in all stages, so it's not needed any more to add it as a dependency to files that include fmap_config.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b62917f32ae9f51f079b243a606e5db07ca9099 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76002 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-20soc/amd/common/iommu: Use preprocessor values for IOMMU baseArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I85f58565bf1f955f704e223d538d0b374bc6fbda Reviewed-on: https://review.coreboot.org/c/coreboot/+/75915 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-06-19soc/amd/common/block/include/amdblocks/data_fabric: fix typo in 'IOAPIC'Felix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie17fd14bed9ec91c5f11aee00bf5d2d2e253ec08 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75897 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-15soc/amd/*/root_complex: reserve IOMMU MMIO areaFelix Held
This makes sure that the resource allocator won't use this address range for anything else. In the systems I looked at, this was between the end of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO region, but better reserve it here so nothing else will get allocated there if this expectation isn't met. TEST=Reserved region is printed in the console logs: update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-14acpi/acpi.h: Remove global acpi_fill_ivrs_ioapic()Arthur Heymans
In soc/amd this function is unused so drop it and rename _acpi_fill_ivrs_ioapic(). Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ic403fd84cb9cd5805fbc6f0c5a64cefbf4b0cd81 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75711 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
2023-06-14soc/amd/acpi/ivrs: Use specific IOMMU resource index on all SOCArthur Heymans
By adding all DXIO IOAPIC with the same resource index, the IVRS code can always pick that resource which simplifies the code. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I10345e2337dcb709c2c1a8e57a1b7dd9c04adb9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
2023-06-13soc/amd/common/cpu/noncar/cpu: rename get_smee_reserved_address_bitsFelix Held
Rename get_smee_reserved_address_bits to get_sme_reserved_address_bits since the feature is called secure memory encryption and the last 'e' in SMEE bit in the SYSCFG MSR just stands for enable. The function will return a valid number of reserved address bits no matter if this is enabled or not, so drop the second 'e'. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3795f7a861e39cb6c8209fee10191f233cbcd308 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75766 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-12soc/amd/smm: Sanity check the SMM TSEG sizeZheng Bao
As per AMD64 Architecture Programmer's Manual, section 10.2.5 SMRAM Protected Areas: The TSEG range must be aligned to a 128 Kbyte boundary and the minimum TSEG size is 128 Kbytes. The SMM TSEG size should be less than SMM reserved size. AMD TSEG mask works like an MTRR. It needs to be aligned to it's size and it's size needs to be a power of 2. Change-Id: Ic4f557c7b77db6fc5ab2783ca4e2ebe7a4476e85 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75405 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-06-12soc/amd/block/ivrs: Generalize IVRS table generationNaresh Solanki
This commit introduces a refactored version of the IVRS (I/O Virtualization Reporting Structure) table generation. The main objective of this refactoring is to generalize the process of generating the IVRS table based on the IOMMU (Input/Output Memory Management Unit) domains and their corresponding resources. Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Change-Id: Ic471f05d6000c21081d70495b7dbd4350e68b774 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75451 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/common/acpi: move acpi_fill_root_complex_tom to StoneyridgeFelix Held
Now that Stoneyridge is the only AMD SoC that still needs the part of the SSDT that contains the TOM1 and TOM2, move it from the common code to the Stoneyridge northbridge code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9091360d6a82183092ef75417ad652523babe075 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75564 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-06-07soc/amd/common/data_fabric/domain: write _BBN method in SSDTFelix Held
Instead of having PCI0's _BBN method in the DSDT that always returns 0, use acpigen_write_BBN to generate the _BBN method that returns the first PCI bus number in the PCI domain/host bridge. TEST=On mandolin the _BBN method in the _SB/PCI0 scope is now in the SSDT instead of the DSDT, but still returns 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8badeb0064b498d3f18217ea24bff73676913b02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74992 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/common/data_fabric/domain: provide amd_pci_domain_fill_ssdtFelix Held
Generate the PCI0 _CRS ACPI resource template to tell the OS which PCI bus numbers and IO and MMIO regions can be used for PCI devices below _SB/PCI0. This data corresponds to what amd_pci_domain_scan_bus and amd_pci_domain_read_resources provided to the resource allocator. This makes sure that the PCI0 _CRS ACPI resource template matches the constraints the resource allocator used when allocating resources. TEST=With also the rest of the current patch train applied, the generated _CRS resource template contains the expected PCI bus numbers and IO and MMIO resources and both Linux and Windows boot on Mandolin. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iaf6d38a8ef5bb0163c4d1c021bf892c323d9a448 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74843 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-06-07soc/amd/common/data_fabric/domain: provide scan_bus and read_resourcesFelix Held
Provide amd_pci_domain_scan_bus to enumerate the PCI buses in the one PCI root domain and amd_pci_domain_read_resources to read the MMIO regions that the resource allocator can use to allocate the PCI MMIO BARs in the one PCI root domain from the corresponding data fabric MMIO decode registers. This makes sure that the allocator will only put PCI MMIO resources in areas that are decoded to the PCIe root complex. The current code only covers the case of a system with one PCI root where all PCI bus numbers belong to the only PCI root, all IO ports get decoded to the only PCI root and the MMIO regions from the data fabric MMIO decode registers get decoded to the only PCI root. In future patches, this will be extended to also support the multi PCI root case. TEST=With also the rest of the current patch train applied, the resource allocator uses the constraints on the MMIO regions and both Linux and Windows boot on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4aada7c8a2a43145ad08d11d0a38d9cdc182b98e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74717 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/common/block/cpu/noncar: add get_usable_physical_address_bits()Felix Held
In case the secure memory encryption is enabled, some of the upper usable address bits of the host can't be used any more. Bits 11..6 in CPUID_EBX_MEM_ENCRYPT indicate how many of the address bits are taken away from the usable address bits in the case the secure memory encryption is enabled. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia810b0984972216095da2ad8f9c19e37684f2a2e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75623 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/common/block/cpu/noncar/cpu: add missing types.h includeFelix Held
types.h provides uint32_t via a chain include. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I875e3bb096b56bbea862c9ad0e3e14e025e3298b Reviewed-on: https://review.coreboot.org/c/coreboot/+/75622 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-02soc/amd/common/block/graphics: Add missing pci_rom_free()Grzegorz Bernacki
pci_rom_probe() can allocate memory when mapping a CBFS file, so pci_rom_free() should be called before leaving the function. BUG=b:278264488 TEST=Build and run with additional debug prints added to confirm that data are correctly unmapped Change-Id: Ie6fbbfd36f0974551befef4d08423a8148e151e7 Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74779 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
2023-06-02soc/amd/common/block/cpu: Refactor ucode allocationGrzegorz Bernacki
Move microcode load/unload to pre_mp_init and post_mp_init callbacks. It allows to make sure that ucode is freed only if all APs updated microcode. BUG=b:278264488 TEST=Build and run with additional debug prints added to confirm that data are correctly unmapped Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-05-27soc/amd/common/block/psp: Unmap EFS region after useKarthikeyan Ramasubramanian
EFS header is mapped during PSP verstage and bootblock to read some SPI configuration. After use it is left unmapped. Unmap the EFS region after use. BUG=b:240664755 TEST=Build and boot to OS in Skyrim with unsigned PSP verstage. Change-Id: I865f45a3d25bc639eb8435b54aa80895ec4afd27 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75455 Reviewed-by: Raul Rangel <rrangel@chromium.org> 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-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-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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-15 08:50:41 +0000