summaryrefslogtreecommitdiff
path: root/src/soc/amd
AgeCommit message (Collapse)Author
2023-06-06soc/amd/phoenix: Update USB device aliasEric Lai
Follow 57263_FP8_MBDG_rev_0_92 Table.57 to update the alias. We can match the schematic for now. BUG=b:285793461 TEST=USB still works. Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: Id1058279fe5b0e3131608a0b9bbd708dbbde7e87 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75615 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Jon Murphy <jpmurphy@google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-06-05soc/amd/mendocino: Print content of manifest fileGrzegorz Bernacki
This adds printing content of 'manifest' file at ramstage. It allows to learn about blobs version used to build the coreboot binary, which is useful when investigating bugs. Version data are stored in CBFS file, which was generated during coreboot build. If AMD FW blobs will be manually replaced in coreboot image, versions from CBFS file are no longer valid. Log: AMDFW blobs version: type: 0x01 ver:00.3c.01.18 type: 0x08 ver:00.5a.28.00 type: 0x30 ver:2b.25.b0.10 type: 0x73 ver:00.3c.01.18 BUG=b:224780134 TEST=Tested on Skyrim device Change-Id: I8df54b74cd987b4a3be635932d38ea178d0b0311 Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74269 Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.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-06-02soc/amd/phoenix/Kconfig: Prevent changes to AMD_FWM_POSITION_INDEXFred Reitberger
The phoenix SoC does not support multiple EFS locations. Set the default to the only valid value and prevent mainboard overrides by making the option non-user-configurable. TEST=build birman-phoenix Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I0f720dbadf2d28a3c39daa4bd653a407be4893d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74249 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-06-02soc/amd/mendocino: Add manifest generation to MakefileGrzegorz Bernacki
This adds manifest generated by amdfwtool to CBFS. BUG=b:224780134 TEST=Tested on Skyrim device Change-Id: I13c9d322735e0979484b120c665fb100cf187eab Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74267 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-06-01mb/google/guybrush: Move helper AOAC for console to AOAC headerKonrad Adamczyk
BUG=b:217968734 TEST=Build guybrush firmware Change-Id: I93dfa50cd1116e0f6652186acb37fd43d638cf84 Signed-off-by: Konrad Adamczyk <konrada@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75491 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-31soc/amd/picasso/acpi/sb_pci0_fch: replace Memory32Fixed with DWordMemoryFelix Held
This brings the ACPI code more in line with both what the new code for the AMD SoCs will do and also what the current Intel code does. This was mainly done to have a reduced delta to the new AMD domain resource handling functions to debug it, but it might still be useful to upstream this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-05-30soc/amd/phoenix/Kconfig: use lower case hex digits in VGA_BIOS_IDFelix Held
cbfs_boot_map_optionrom will generate lower case hex digits for the filename to look for in CBFS, so make sure that the file name will use lower case hex digits and no upper case hex digits. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1d4daa04120de0f2c853a44691b7e2c52eb2af20 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75483 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-27soc/amd/mendocino/psp_verstage: Fix pending mapsKarthikeyan Ramasubramanian
cbfs_unmap does not unmap the mapped region from the boot device. This leads to some resource leaks eg. TLB slots in PSP. Explicitly call rdev_munmap on the address mapped by cbfs_map. BUG=b:240664755 TEST=Build and boot to OS in Skyrim with unsigned PSP verstage. Change-Id: I51b9d066a40103f2ebdf2ef2fc3da13beb467921 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75454 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-05-27soc/amd/common/psp_verstage: Fix pending mapsKarthikeyan Ramasubramanian
cbfs_unmap does not unmap the mapped region from the boot device. This leads to some resource leaks eg. TLB slots in PSP. Explicitly call rdev_munmap on the address mapped by cbfs_map. BUG=b:240664755 TEST=Build and boot to OS in Skyrim with unsigned PSP verstage. Change-Id: If1d355972cc743b8d8c451e1b3f827abd15e98fe Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75453 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-05-27soc/amd/common/psp_verstage: Fix build for FMAP without RW slotsKarthikeyan Ramasubramanian
On FMAP without RW slots, PSP verstage fails to build because of reference to FMAP_SECTION_FW_MAIN_A_*. Instead extract the offset and size of relevant sections using fmap_locate_area(). BUG=b:240664755 TEST=Build and boot to OS in Skyrim with unsigned PSP verstage. Change-Id: I29997534c6843b47a36655431f79e5c70bd17f9b Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75452 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-05-22soc/amd/mendocino: Unmap hash table after usageKarthikeyan Ramasubramanian
Earlier the entire SPI ROM is mapped at the start of verstage and then unmapped at the end of verstage. With CB:74606, this behavior has changed. So unmap the hash table CBFS file after usage. 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: I5c605f8ba8bbd571b589b3cdf91e9cc71d711c1c Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75092 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-14soc/amd/phoenix/Kconfig: Update default soft fuse bitsFred Reitberger
Set the default soft fuse bits to the recommended values Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I2354aefe90a08eaef95a68926806d11a9118c3de Reviewed-on: https://review.coreboot.org/c/coreboot/+/75183 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-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-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide MISC deviceFelix Held
Don't set bit 2 of the return value of the _STA method in order for Windows not to show a warning about an unknown device in the device manager for this device. TEST=The unknown device with device instance path ACPI\AMD0040\3 disappeared from the device manager in Windows 10 build 19045 on a Mandolin board with a Picasso APU. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If005f06843956004c281fd70cf364171148cb9ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: change AAHB's _STA back to methodFelix Held
Commit 396fb3db74db ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB device") didn't only change the visibility of the device, but also changed the _STA method to a name. While this worked, the specification says that _STA is supposed to be a method, so change it back to being a method. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-08Revert "soc/amd/cezanne/romstage: Preload fspm.bin"Raul Rangel
This reverts commit d6e0a90aa0bd574b28b6c9b4b46289bf46a208db. Reason for revert: Not ready to land, blocked by ancestor CL Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: Ic14e17db4aed2f998878920c66cdc16362920dcb Reviewed-on: https://review.coreboot.org/c/coreboot/+/75050 Reviewed-by: Shelley Chen <shchen@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-08soc/amd/cezanne/romstage: Preload fspm.binRaul E Rangel
FSP-M is normally memmapped and then decompressed. The SPI DMA controller can actually read faster than mmap. So by reading the contents into a buffer and then decompressing we reduce boot time. It is interesting that FSP-M takes an additional 8ms to execute. I suspect since we call it 50ms earlier it's having to wait for one of its dependencies. BUG=b:179699789 TEST=Boot guybrush and see 30ms reduction in boot time | 970 - loading FSP-M | 0.316 | 0.997 Δ( 0.68, 0.05%) | | 17 - starting LZ4 decompress (ignore for x86) | 0.026 | 13.874 Δ( 13.85, 0.96%) | | 18 - finished LZ4 decompress (ignore for x86) | 64.361 | 0.337 Δ(-64.02, -4.43%) | | 2 - before RAM initialization | 0.534 | 0.529 Δ( -0.01, -0.00%) | | 950 - calling FspMemoryInit | 1.455 | 1.132 Δ( -0.32, -0.02%) | | 951 - returning from FspMemoryInit | 207.695 | 216.537 Δ( 8.84, 0.61%) | Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I850b1576501753a355e7b23745e04802a0560387 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58988 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-05-08soc/amd/phoenix/include/xhci: add USB4 XHCI device pointersFelix Held
Beware that there's no XHCI2 controller and the USB4 controller device pointers were added right after the xhci_0 and xhci_1 controller device pointers. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I14725d4b546ffcca42e21bbe7756babaaff8fea3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74658 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> 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-05-08soc/amd/*/acpi/northbridge,pci0: don't hide PCI0 root device from OSFelix Held
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates that the device should be shown in the user interface. This ports commit c259d7192806 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS") forward from Stoneyridge to the newer AMD SoCs. TEST=On Mandolin the PCI Express Root Complex now shows up in the device manager on Windows 10 and when switching the view to 'devices by connection', all PCI(e) devices are shown below it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-05-03soc/amd/phoenix: Add default vBIOS ID and locationMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Iadc32f4dbf8bd48d8666a213d7b5f3ba42175a90 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74905 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-05-01soc/amd/stoney/acpi: Unhide PCI0 root device from OSMatt DeVillier
In order for Windows to detect/load drivers for any child devices, the PCI0 root device status must be enabled and visible. TEST=build google/liara, boot Windows, verify PCI child devices visible in Device Manager. Change-Id: I3fb1ba11247f0811120a4cf8a4fd99342ae201de Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74855 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-29sb,soc/amd,intel: Drop include <cpu/x86/smm.h>Kyösti Mälkki
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT entries for SMI architectural"). Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-29ACPI: Make FADT entries for RTC/CMOS architecturalKyösti Mälkki
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY that points to same offset. Since the century field inside RTC falls within the NVRAM space, and could interfere with OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY. There were no reference for the use of offset 0x48 for century. Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-28soc/amd/phoenix: Populate type 0x63 entry with right MRC CacheFred Reitberger
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS directory entry in RO with that section. If the RECOVERY_MRC_CACHE section is not present, then fall back to RW_MRC_CACHE. BUG=b:270569389 Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ic5ac87685eaa5fec717e3efa4df7af511b4ce8aa Reviewed-on: https://review.coreboot.org/c/coreboot/+/73257 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-04-28soc/amd/stoneyridge/acpi/sb_pci0_fch: report correct PCI MMIO BAR windowFelix Held
This ports back commit d75ee46d3ce6 ("soc/amd/picasso/acpi: Change PCI0 BAR window") to Stoneyridge so that the correct end of the non-fixed MMIO region gets reported in PCI0's _CRS method. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I19153947cbb1b1b684291765eb1902caac65b9ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/74809 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-04-28soc/amd/stoneyridge/acpi/sb_pci0_fch: report correct number of PCI busesFelix Held
This ports commit 8c28e51a16e1 ("soc/amd/picasso: fix host bridge bus numbers") back to Stoneyridge so that the correct number of PCI buses gets reported from PCI0's _CRS method. The MCFG ACPI table already had the correct last bus number. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I40121ab0e0438281192b6a0bec8dbecdc1749379 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74804 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-04-27soc/amd/mendocino: update FSP parameters for eDP power sequence adjustmentChris Wang
Add UPD parameter for eDP power sequence adjustment. The edp_panel_t9_ms parameter is set for bloff to varybloff. BUG=b:271704149 BRANCH=Skyrim TEST=Build; Verify the UPD was pass to system integrated table. Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Change-Id: Id651c9cc4d6f4e27f6c78ca10ca12936d66ef43b Reviewed-on: https://review.coreboot.org/c/coreboot/+/74789 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Martin Roth <martin.roth@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-04-27soc/amd/mendocino: rename pwr_on_vary_bl_to_blon to edp_panel_t8_msChris Wang
Rename the UPD pwr_on_vary_bl_to_blon to edp_panel_t8_ms to match the eDP sequence timing in milliseconds. BUG=b:271704149 BRANCH=Skyrim Test=Build/Boot to ChromeOS Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Change-Id: Iecdfe47cd9142d8a1ddeee0ec988d37b2a11028e Reviewed-on: https://review.coreboot.org/c/coreboot/+/74787 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-04-27ACPI: Make FADT entries for SMI architecturalKyösti Mälkki
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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/phoenix/Kconfig: Update commentFred Reitberger
Fix copy-paste comment on closing endif Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I9671a9228c304988eb3903391f74a21d80d0a8bc Reviewed-on: https://review.coreboot.org/c/coreboot/+/74734 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Eric Lai <eric_lai@quanta.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-22soc/amd/glinda: drop code for non-existing eMMC controllerFelix Held
Glinda doesn't have an eMMC controller and also doesn't have GPIO pins that eMMC signals can be multiplexed on, so drop the eMMC related code from Glinda. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I49ead01075780ea97dae99a36632f7659fd00587 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74662 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-04-22soc/amd/phoenix: drop defines for non-existing eMMC controllerFelix Held
Phoenix doesn't have an eMMC controller, so remove the remaining eMMC- related defines. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I412c968479d23deb7f2e060b26b4a56ec9c764f2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74661 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-22soc/amd/mendocino: drop code for non-existing eMMC controllerFelix Held
Mendocino and Rembrandt don't have an eMMC controller and also don't have GPIO pins that eMMC signals can be multiplexed on, so drop the eMMC related code from Mendocino. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib8ec49a7084bdd62e480baee75a280fde8b13d01 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74660 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-22soc/amd/phoenix/xhci: add SCI sources for the two USB4 controllersFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I95916e409b3fbd4941a861054733a34100244da9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-22soc/amd/*/include/pci_devs: fix copy-paste error in PCIE_ABC_C_DEVFNFelix Held
Since it's an internal bus, it's PCIE_ABC_C_DEVFN and not PCIE_GPP_C_DEVFN. This also makes it consistent with the rest of the internal PCI buses. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ica8b666161c3cd3b0b4a29f8a4b0aff473b4d833 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74656 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-22soc/amd/phoenix/include/soc/smi: add missing SCI map defines 61-63Felix Held
In the PPRs #57019 Rev 3.03 and #57396 Rev 3.04, SMITYPE_XHC3_PME, SMITYPE_XHC4_PME and SMITYPE_CUR_TEMP_STATUS_5 are defined, so add those defines. When doing the initial update for Phoenix, at least XHC3 and XHC4 PME events were missing from the PPR. Those two are the PME events of the two USB4 controllers. SMITYPE_XHC2_PME doesn't exist on this SoC. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic6fff9175b73cc9d0fd324d4a568a5761b92d078 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74655 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-21soc/amd/phoenix: Mark PCIe GPP bridges as hidden instead of offMartin Roth
When one of the General-Purpose PCIe bridges is not used, it doesn't show up on the PCI bus at all, so coreboot notes it as an issue in the devicetree. This happens even if the device is marked as off. To solve this, we're marking the GPP bridge devices in devicetree as hidden, so they'll only show up in devicetree if they're actually used on a mainboard. BUG=b:277997811 TEST=Build Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I7b7577baa2dbb0ea7ebbcdb1a8ae81770e61d76f Reviewed-on: https://review.coreboot.org/c/coreboot/+/74527 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-04-21soc/amd/mendocino: Mark PCIe GPP bridges as hidden instead of offMartin Roth
When one of the General-Purpose PCIe bridges is not used, it doesn't show up on the PCI bus at all, so coreboot notes it as an issue in the devicetree. This happens even if the device is marked as off. To solve this, we're marking the GPP bridge devices in devicetree as hidden, so they'll only show up in devicetree if they're actually used on a mainboard. BUG=None TEST=Don't see the "PCI: Leftover static devices:" warning for these in the boot console. BRANCH=skyrim Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I517776e4dedc70e957a0c836ab3c2e5d49e156d2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74526 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.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/stoneyridge/memmap: 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: Ic673deb725a541c7535ae769f589cd82ea42a561 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74614 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-21soc/amd/stoneyridge/northbridge: 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: I04f2a3744aee9beedaa97b154a652ce6f0c705c0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74613 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.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-21Drop unused include <version.h>Kyösti Mälkki
Change-Id: I7d0718b5d2e0dd16eb90f63dd9d33329a2d808ba Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74448 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-21include/cpu/amd/mtrr: rename functions to get top of memory regionsFelix Held
Rename amd_topmem and amd_topmem2 to get_top_of_mem_below_4gb and get_top_of_mem_above_4g to make it clearer what those functions return. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic6e98d94c731af74aea0ce276a9a7e4867e3986f Reviewed-on: https://review.coreboot.org/c/coreboot/+/74589 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-21soc/amd/phoenix: Update XHCI eventsJon Murphy
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI to allow for XHCI events to be logged. BUG=b:277273428 TEST=builds Change-Id: I3ca4f84fb0f1fef8441ab6ef7b6f6348c52b2922 Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74280 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-21ACPI: Obsolete FADT p_lvl2_lat and p_lvl3_lat fieldsKyösti Mälkki
After the obsoletion of Processor() it is necessary to provide _CST package to define P_LVLx IO addresses for C2/C3 transitions. The latency values from _CST will always replace those in FADT. Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-21soc/amd/phoenix/xhci: Correct counting of xhci_sci_sourcesFred Reitberger
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Iabba97e003d1a5140c98e3fc5a3496f66f8795c2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74528 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-04-20soc/amd/phoenix/include/soc/pci_devs: update defines to match the PPRFelix Held
Parts of this file were still a copy of the file from the Mendocino SoC, so update the file to match the PPR #57019 Rev 3.03 and the chipset devicetree of the Phoenix SoC. Phoenix has 4 GFX/GPP PCIe bridges/ports, the numbering scheme of the GPP PCIe bridges/ports was changed so that the numbers match the device and function numbers, and there are new device functions for the IPU and the USB4 controller and router devices. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie9429c03839bb0199a04cd6cafe9a955ebdacc91 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74565 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-20soc/amd/phoenix/devicetree: drop i2s_ac97 deviceFelix Held
In both PPR #57019 Rev 3.03 and PPR #57396 Rev 3.04, the i2s_ac97 function on bus C isn't mentioned any more and the microarchitecture specification document for this SoC also doesn't mention it, so remove it from the devicetree. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibd115953bdd60e1dfcc79797b0c2158e5d861636 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74564 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-04-20soc/amd/stoneyridge/northbridge: fix indentation in set_mmio_addr_regFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5e067f6fb2bab66d9b2f6965636845dfd8b7cacd Reviewed-on: https://review.coreboot.org/c/coreboot/+/74567 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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-13soc/amd/stoneyridge/northbridge: use common acpi_fill_root_complex_tomFelix Held
Use the common acpi_fill_root_complex_tom function instead of the SoC- level northbridge_fill_ssdt_generator function that does basically the same. TEST=Resulting coreboot SSDT remains unchanged on Careena. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie0f100e0766ce0f826daceba7dbec1fb88492938 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74303 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-04-11soc/amd/mendocino: Lower log level for TDP value to DEBUGPaul Menzel
Printing the value of a variable is not informative for a normal user, so decrease the value from BIOS_INFO to BIOS_DEBUG. Fixes: b9caac74a320 ("soc/amd/mendocino: Reinterpret smu_power_and_thm_limit") Change-Id: I22f6293fd47633dfdbdae37b7257f47a5a4bb29c Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com>
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-06amd/mendocino/root_complex: Restrict DPTC to 15W boardsTim Van Patten
Restrict DPTC to 15W boards, since we only have 15W values defined in the devicetree. This will revert the 6W boards back to their default values, rather than (incorrectly) configuring them with 15W values. BUG=b:253301653 TEST=Verify DPTC values are set for 15W boards TEST=Verify DPTC values are set not set for 6W boards Change-Id: I94f3974fce6358e3cbb0c30c1af33eb7ecb29ad7 Signed-off-by: Tim Van Patten <timvp@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74127 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06soc/amd/mendocino: Reinterpret smu_power_and_thm_limitTim Van Patten
The FSP will return the TDP in the format 0xX0000, where 'X' is the value we're interested in. For example: 0xF0000 (15W), 0x60000 (6W). Re-interpret the value so the caller just sees the TDP directly, without needing to re-interpret things themselves. BUG=b:253301653 TEST=Manually verify value is correct Change-Id: I632e702d986a4ac85605040e09c1afab2bbdc59d Signed-off-by: Tim Van Patten <timvp@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74126 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-04-03soc/amd/cezanne,glinda,mendocino,phoenix,picasso/Kconfig: use all targetFelix Held
The i2c.c compilation unit is added to all stages in all cases, so use the all target instead of adding it to all stages separately. Also order the all targets alphabetically. TEST=Timeless build on Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-04-01soc/amd/stoneyridge: factor out P-state utils to link in all stagesFelix Held
tsc_freq.c gets built into all stages, but the tsc_freq_mhz function it implements calls the get_pstate_0_reg function which was only built into ramstage. Since tsc_freq_mhz was only called in ramstage, commit 2323acab6a7a ("soc/amd/stoneyridge: implement and use get_pstate_0_reg") didn't cause the build to fail, but better factor out the P-state- related utility functions into a separate compilation unit and include it in all stages that also include tsc_freq.c. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id3a3ee218f495be5e60a888944487704e7e8a1a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74145 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-01soc/amd/stoneyridge/Makefile: use all target for more compilation unitsFelix Held
monotonic_timer.c, tsc_freq.c and uart.c get added to all stage targets, so just add those to the all stage targets. They still need to be added to the smm stage target, since the all target doesn't add things to the smm stage. TEST=Timeless build results in identical image for Gardenia. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I16c02bc0ff54553f212b94d110abef6a7bdedbb4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74144 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-31soc/amd/picasso/graphics: use RAVEN2_VBIOS_REV with RAVEN2_VBIOS_VID_DIDFelix Held
In order for the code to find the correct VBIOS file in CBFS, remap the revision ID in the RAVEN2_VBIOS_VID_DID case to the one that matches the CBFS file name. This will make the code work as expected on devices with the PCI ID RAVEN2_VBIOS_VID_DID and a revision != RAVEN2_VBIOS_REV. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I94412dc2e778e7c4f74e475cd49114a00a81b2ce Reviewed-on: https://review.coreboot.org/c/coreboot/+/74045 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-30soc/amd/picasso/graphics: refactor map_oprom_vendev_revFelix Held
Refactor map_oprom_vendev_rev as a preparation to also remap the revision ID in the RAVEN2_VBIOS_VID_DID case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3b81a9464ed49672889fcb767920154fe6efdfcc Reviewed-on: https://review.coreboot.org/c/coreboot/+/74044 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
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/stoneyridge: use common AMD CPU power state ACPI generationFelix Held
Instead of using the PSTATE SSDT generated by binaryPI, use the common AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There are two differences to the binaryPI SSDT: Now coreboot includes the C1 state in the _CST package instead of just having the kernel add this due to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the PS_STS_REG P state status MSR is written to the corresponding field of the _PCT package instead of being 0. TEST=On Careena the new P and C state ACPI packages are nearly identical to the ones from the SSDT from binaryPI with the two functional differences mentioned above. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge/cpu: implement get_pstate_latencyFelix Held
Both the algorithm and the registers involved are described in the public version of BKDG #55072 Rev 3.09 in chapter 2.5.2.1.7.3.2 _PSS (Performance Supported States). Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9b2c177d9d80c5c205340f3f428186d6b8eb7e98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74025 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/picasso/Kconfig: update help text for 2nd VBIOS ID detectionFelix Held
The help text for VGA_BIOS_SECOND_ID was outdated and from a time before we found out that just looking at the CPUID doesn't reliably tell us on which type of silicon we're running and which VBIOS file to pick, so we had to use a different method. Update the help text to match what the code does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia568771ed7dfa0c7bb850b0efcd2959d7ddfd4a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73335 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.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/stoneyridge: implement and use get_pstate_0_regFelix Held
Introduce get_pstate_0_reg and use it in tsc_freq_mhz to get the P state register number corresponding to P state 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b92a858bf36b04a570d99c656e5ccfc84457724 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74022 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/stoneyridge/acpi: add C state config tableFelix Held
The C state ACPI packages binaryPI generates and passes to coreboot in the PSTATE SSDT only include the C2 state, but the kernel will add the C1 state to its usable C states in this case. The native C state code will generate both the C1 and C2 state packages to be more complete and also to be more in line with the other AMD SoCs. The code added in this commit isn't used yet, but will be used as soon as Stoneyridge will be using the common AMD generate_cpu_entries by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed helper functions are implemented for Stoneyridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001 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/stoneyridge/tsc_freq: use get_pstate_core_freqFelix Held
Use get_pstate_core_freq instead of open-coding the calculations in tsc_freq_mhz. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If5d526e6b365c62a6669241f4fcdd25eca3f15fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/74012 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-12-22 23:06:40 +0000