summaryrefslogtreecommitdiff
path: root/src/soc/amd
AgeCommit message (Collapse)Author
2023-03-08soc/amd/common/block/acpi/cpu_power_state: use definition for bit_offsetFelix Held
Instead of using a magic constant in the bit_offset field of the C state resource for the C1 state that's entered via the MWAIT instruction, use the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by acpi_processor_ffh_cstate_probe in the Linux kernel. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/common/block/acpi/cpu_power_state: add get_cstate_info helperFelix Held
Introduce the get_cstate_info helper function that populates the caller- provided cstate_values array with the data returned by the SoC-specific get_cstate_config_data function. From the array get_cstate_config_data returns, only the ctype, latency and power fields are used, so the rest can be left uninitialized. Those 3 fields are compile-time constants. For each entry, write_cstate_entry will generate the corresponding resource information from the given data. In the C1 case where ctype is 1, the state is entered via a MWAIT instruction, while the higher C states are entered by doing an IO read from a specific IO address. This IO address is x - 1 bytes into the IO region starting at MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by reading from the C state IO base address + 1. This resource information is generated during runtime, since the contents of MSR_CSTATE_ADDRESS aren't necessarily known at compile-time. MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass a buffer with space for the maximum number of C state entries. This maximum number corresponds to the number of IO addresses the CPU traps beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more than 3 or maybe 4 C states will be available though. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-07soc/amd/stoneyridge: request binaryPI to use \_SB_ scope in PSTATE SSDTFelix Held
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the scope for the CPU objects and patching this SSDT in coreboot to use the \_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the \_SB_ scope instead by setting the late platform configuration option ProcessorScopeInSb to true. TEST=Careena still boots and Linux doesn't show any ACPI errors with this patch applied. With only patch_ssdt_processor_scope removed, but the ProcessorScopeInSb option not set, Linux will complain that it can't resolve the \PR.P00x symbols. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-06soc/amd: rename ACPI_CPU_CONTROL to ACPI_CSTATE_CONTROL for non-CAR CPUsFelix Held
The legacy ACPI CPU control registers in IO space where the first 4 IO locations control the CPU throttling value don't exist any more on the Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS in set_cstate_io_addr which will cause accesses from the 8 IO addresses beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads from those IO addresses will cause the CPU to enter low C states. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/include/iomap: add comment about ACPI IO assignmentFelix Held
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO addresses from ACPI_CPU_CONTROL on for C state control. This is set up in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into MSR_CSTATE_ADDRESS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/include/southbridge: drop PM_CPU_CTRL defineFelix Held
Picasso and newer don't implement the P_CNT register to control the CPU duty cycle and also trap the C state control IO addresses directly in the CPU, so those won't reach the FCH. This register is unused in the Picasso code and not even defined any more in the Cezanne PPR. The Picasso PPR does define this register, but since it's useless and might even just be a leftover form a pre-Zen CPU generation, drop the define. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/*/acpi: drop unnecessary duty_offset/duty_width field writesFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the duty_offset and duty_width FADT field in acpi_fill_fadt for all SoC except Stoneyridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/picasso/acpi: don't announce unimplemented duty cycle controlFelix Held
Picasso neither has the corresponding P_CNT register implemented nor writes a _PTC ACPI object that would specify the P_CNT register. The Picasso UEFI reference code also sets the duty_width FADT entry to 0. This also aligns the Picasso code with the Cezanne code in this regard. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/*/acpi: drop unneeded pstate_cnt FADT assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the pstate_cnt FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If3ddb466de1d437361d811e45e328a1dbff02fcc Reviewed-on: https://review.coreboot.org/c/coreboot/+/73419 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-06soc/amd/*/acpi: drop unneeded mon_alrm FADT assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the mon_alrm FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iabb5fc7367f1e4e7acea1a58abdb643fc46ca776 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73418 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> 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>
2023-03-04soc/amd/mendocino: Add STT support for dptc tablet modeChris Wang
Add stt settings for dptc tablet mode. BUG=b:257149501 BRANCH=None TEST=Check if the STT value matches the clamshell/tablet mode. Run the WebGL aquarium with 5000 fish and verify that there is no power drop peak. Change-Id: Ib4aad3af8761b20084717b15a462edf4704b83cc Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73205 Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
2023-03-04soc/amd/mendocino: Remove the SPL DPTC parameterChris Wang
The SPL parameter for DPTC settings is not available for STT-enabled platforms. It needs to be removed to avoid confusing STT calculations. BUG=b:265267957 BRANCH=none TEST=Run the WebGL aquarium with 5000 fish and verify that there are no power drop peaks. Change-Id: I8e6dad7d24883f8aadce83ebac401ecd4137d61a Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73124 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com>
2023-03-03soc/amd/cezanne/graphics: simplify map_oprom_vendev implementationFelix Held
Phoenix' implementation of map_oprom_vendev uses this simplified implementation, so port this back to Cezanne too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0aa3a0fed37c6cba15a668ada639f5fd0c212d2f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73387 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-02amdfwtool: Change .rom.efs to .rom and .rom to .rom.bodyZheng Bao
To support 32M flash, the non-vboot also need to split amdfw. The amdfw.rom is the default filename added to CBFS. Keep the default filename and then we don't have to change all the CBFS definition. This is one of series of patches to support 32/64M flash. BUG=b:255374782 Change-Id: Id77b11422d4549cf57a1cd8980c7a9cf3597d1bc Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72702 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-02soc/amd/mendocino: Add new 'STT_ALPHA_APU' parameter for DPTC supportChris Wang
Add a new parameter STT_ALPHA_APU' for each DPTC mode. BUG=b:257149501 BRANCH=None TEST=Check if the STT value matches the expected setting. Change-Id: Ib27572712d57585f66030d9e927896a8249e97a7 Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73123 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com> Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
2023-02-28soc/amd: introduce and use PSTATE_MSR macroFelix Held
Instead of adding the P-state number to the PSTATE_0_MSR number to get the P-state MSR number for the rdmsr call, provide a macro that directly calculates the MSR number for a given power state. Also drop the unused PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs available in the hardware. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-02-28soc/amd/*/acpi: add comment about p_lvl[2,3]_lat FADT field usageFelix Held
The latency values in the _CST package override the values in the p_lvl2_lat and p_lvl3_lat FADT fields. In Picasso, Cezanne, Mendocino, Phoenix and Glinda generate_cpu_entries generates the _CST packages for each CPU device. The coreboot code for Stoneyridge doesn't generate _CST packages for the CPU objects, but those are provided via the PSTATE SSDT binaryPI generates and agesa_write_acpi_tables gets and adds to the ACPI tables. The AGESA reference code also sets those two FADT entries to the equivalents of ACPI_FADT_C2_NOT_SUPPORTED and ACPI_FADT_C3_NOT_SUPPORTED so this also matches the AGESA behavior. From the ACPI 6.4 spec: "Values provided by the _CST object override P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT." Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1116a3013576b18b6f521604d6b0a9d75b971e0b Reviewed-on: https://review.coreboot.org/c/coreboot/+/73231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-28soc/amd/stoneyridge/acpi: introduce and use ACPI_SCI_IRQ definitionFelix Held
IRQ9 is used as ACPI SCI IRQ, so add a define for that and use it in the code like it is also done in the other SoCs in soc/amd. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iddb51d70c15ab1d7088f62b61e22510bd1b30b1e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73320 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/picasso/acpi: use ACPI_SCI_IRQ definitionFelix Held
Since there's a define for the ACPI_SCI_IRQ 9, use the define instead of a magic number in the code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I23c8f62929f3f66192698e10826d10329ef3d8cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/73319 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/picasso,stoneyridge/acpi: drop unneeded res2 FADT assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the res2 FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifa69ae61bea82acf66e7210c4103ef48e36dbdd2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73318 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/common/block/apob/apob_cache: use enum cb_errFelix Held
Use enum cb_err to return an error/success state instead of an int in get_nv_rdev and get_nv_rdev_rw. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I73706a93bc1dbc8556e11885faf7f486c468bea9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73317 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-28soc/amd/common/block/apob/apob_cache: include types.hFelix Held
The bool type is used although stdbool.h isn't included. Include types.h which will include both stdint.h and stdbool.h Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5213ddae3ceb36e0b2e09f8ef3f7f414ebdf187f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73316 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-27soc/amd/stoneyridge/acpi: use available number of CPUs for CPU entriesFelix Held
It's sufficient to generate CPU devices for all available CPU cores/ threads instead of for the maximum number of possible CPU cores/threads. TEST=google/careena with 2 cores still boots and Linux doesn't complain about ACPI errors due to referenced but not present CPU objects. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6850edfa305304060092cb5480f4296f4f5ddacc Reviewed-on: https://review.coreboot.org/c/coreboot/+/73070 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/mendocino: Populate type 0x63 entry with right MRC CacheKarthikeyan Ramasubramanian
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 TEST=Build and boot to OS in Skyrim. Ensure that the Type 0x63 BIOS directory entry is populated with the base and size of appropriate MRC cache. Change-Id: I49ec4f64e33c4d5780a7fe6a5540eab42b6cec9f Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73169 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/block/apob_cache: Add support for RECOVERY_MRC_CACHEKarthikeyan Ramasubramanian
If a mainboard has RECOVERY_MRC_CACHE and the recovery mode is enabled, then use APOB data from that section and make any updates to that section. Otherwise continue to use DEFAULT_MRC_CACHE section. BUG=b:270569389 TEST=Build and boot to OS in Skyrim. When in normal mode, DEFAULT_MRC_CACHE is used. Normal Mode Boot1: ------------------ [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [INFO ] APOB RAM hash differs from flash [SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x0/0x1e000 [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] SF: Successfully erased 122880 bytes @ 0x0 [INFO ] Updated APOB in flash Normal Mode Boot2: ----------------- [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] APOB hash matches flash When the device is in recovery mode, RECOVERY_MRC_CACHE is used. Recovery Mode Boot1: -------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [INFO ] APOB RAM hash differs from flash [SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x650000/0x1e000 [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] SF: Successfully erased 122880 bytes @ 0x650000 [INFO ] Updated APOB in flash Recovery Mode Boot2: -------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] APOB hash matches flash Switch from Recovery Mode to Normal Mode: ----------------------------------------- [DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes) [DEBUG] APOB hash matches flash Switch from Normal Mode to Recovery Mode: ----------------------------------------- [DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes) [DEBUG] APOB hash matches flash Change-Id: I93f357e407c98b6e5fca495f4f779fad54a3430f Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73168 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/fsp/dmi.c: Fill in mem manufacturer from CBIMartin Roth
Because the ChromeOS boards don't fill a manufacturer in for the memory SPDs, that information isn't available from the FSP. We can get the Manufacturer ID based on the memory name from CBI instead. Use this information to fill in an ID so that the manufacturer name is available in the SMBIOS information. BUG=None TEST=Look at dmidecode output Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I810c3191180dd3b566d7ea64006f29b625b10526 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73255 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/fsp/dmi.c: Add dmi_type16 ECC to memory structMartin Roth
The DMI error correction type was not being filled in, so was reporting as "Error Correction Type: <OUT OF SPEC>". This patch fixes that. Since it's now filling in information for both Type 16 & 17, rename the function to reflect that. BUG=None TEST=dmidecode now reports the type correctly. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I6b51612d808c63de1acd2be952cb6c152f8a1be5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73253 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-27soc/amd/common/block/simnow: Add SimNow Kconfig optionsFred Reitberger
Add option for mainboards to target builds for SimNow. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Id765437b69f1bc3a9f9d7858edcd27e687d5a7f3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73164 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-23soc/amd/commmon/gfx: Generalize check for selective GOP initMatt DeVillier
Rather than explicitly checking for Recovery or Developer mode via vboot, use display_init_required() so that vboot is not required, and other instances where the display is needed pre-OS (such as when applying a critical system update) are covered as well. With this change, SoCs implementing selective GOP init will need to select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required() to not assert on compilation. BUG=b:255812886 TEST=build/boot skyrim Change-Id: Iac7e06863764a9f21c8a50fc19050cb5a6627df2 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73046 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-23soc/amd/mendocino: Generalize check for selective GOP initMatt DeVillier
Rather than explicitly checking for Recovery or Developer mode via vboot, use display_init_required() so that vboot is not required, and other instances where the display is needed pre-OS (such as when applying a critical system update) are covered as well. Select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required() to function properly (and not assert on compilation). BUG=b:255812886 TEST=build/boot skyrim Change-Id: If2fee71bcc11468fd2db0abaafe4ea35e2953993 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73047 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-02-22soc/amd/picasso,stoneyridge/acpi: drop x_firmware_ctl_[l,h] assignmentFelix Held
The coreboot-common acpi_create_fadt writes a pointer to the FACS table into both firmware_ctrl and x_firmware_ctl_l FADT fields and sets x_firmware_ctl_h to zero. When x_firmware_ctl_[l,h] is non-zero, the pointer in firmware_ctrl will be ignored, but that's what is already done on Cezanne and newer. TEST=Linux doesn't complain about any new ACPI problem on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib9eab4dcf828f28a60c6312ec96872aac4cfb266 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73190 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-22soc/amd/picasso,stoneyridge/acpi: drop unneeded ARM_boot_arch assignmentFelix Held
The FADT data structure is zero-initialized in acpi_create_fadt which then calls the SoC-specific acpi_fill_fadt function, therefore it's not needed to assign 0 to the ARM_boot_arch FADT field in acpi_fill_fadt. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ica968db1228a2d63e83f2b6c4ea57c5f02bf1504 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73187 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-21soc/amd/phoenix: add VBIOS ID remapping for phoenixRitul Guru
Phoenix2 VBIOS PCI DID is 15c8 though the VBIOS image uses a different PCI ID i.e. 0x1205, so we need to implement map_oprom_vendev for the SoC. Change-Id: I7eef5eb41b781f02abb9dd4098e92a8652a431f5 Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73122 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-20soc/amd/common/include/psp_efs: rename new PSP directory EFS entryFelix Held
The EFS entry at offset 0x14 can point to either the first level PSP directory table or to the PSP combo directory structure that was used before the introduction of the AMD A/B recovery scheme. This scheme is not to be confused with the VBOOT scheme. The PSP verstage code checks if the header this entry points to begins with the PSP_COOKIE, which indicates the entry is a first level PSP directory table. Due to that, the EFS entry at offset 0x14 is always expected to point to a PSP directory table, so rename combo_psp_directory to new_psp_directory to match the actual usage. This EFS entry that points to the PSP directory table is called new_psp_directory, since the entry at EFS offset 0x10 was used on some early AMD chips to point to the older PSP directory table and that one is already called psp_directory. amdfwtool uses the same naming scheme for those two PSP directory table pointers. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I10f19ee63f8d422433dba64402d84fd6bb9e0f9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73083 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-16soc/amd/mendocino/Kconfig: add VGA BIOS ID and file defaultsFelix Held
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in Mendocino's Kconfig instead of relying on the board's .config files providing the correct settings. Those settings are per-SoC and not per-board, so this is valid for all boards using the Mendocino APU. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I09c537d3801123e7ffc01608171918b0396b7a5f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73051 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-16soc/amd/cezanne/Kconfig: add VGA BIOS ID and file defaultsFelix Held
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in Cezanne's Kconfig instead of relying on the board's .config files providing the correct settings. Those settings are per-SoC and not per-board, so this is valid for all boards using the Cezanne APU. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I67101d518c6b873ad89932ae39c2deb2ed6a4c29 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73050 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-16soc/amd/picasso/Kconfig: update VGA_BIOS_ID's help textFelix Held
map_oprom_vendev_rev is implemented in graphics.c in the SoC directory. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0123cb8ff662445fd0a613711d9e1981272b1235 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73052 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-16soc/amd/mendocino: Remove non-functional APCB checkFred Reitberger
The way the PSP_APCB_FILES list is created will always insert at least a space into it. When tested by the if, this space will prevent the else clause from ever running and never generate a build error. Remove the non-functional check. Instead, mainboards should select warn_no_apcb or die_no_apcb to generate a warning message or build error if the APCB is missing. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ic96846d74df2dc279e13b22f2a83b6f893954fe8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73009 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-16soc/amd/glinda: Remove non-functional APCB checkFred Reitberger
The way the PSP_APCB_FILES list is created will always insert at least a space into it. When tested by the if, this space will prevent the else clause from ever running and never generate a build error. Remove the non-functional check. Instead, mainboards should select warn_no_apcb or die_no_apcb to generate a warning message or build error if the APCB is missing. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I26b96966495dc35a8b4a0cb7d5a841f3812f2a70 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73007 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-16soc/amd/phoenix: Remove non-functional APCB checkFred Reitberger
The way the PSP_APCB_FILES list is created will always insert at least a space into it. When tested by the if, this space will prevent the else clause from ever running and never generate a build error. Remove the non-functional check. Instead, mainboards should select warn_no_apcb or die_no_apcb to generate a warning message or build error if the APCB is missing. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ib9fe0f05739fb19da2494629dc1d5aaa0ca6431f Reviewed-on: https://review.coreboot.org/c/coreboot/+/73006 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-16soc/amd/common: Add die_no_apcbFred Reitberger
Add target to die when no APCB is found. This is not always a fatal case, so mainboards can select between this and warn_no_apcb. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I5bbc8dd3200c4781677411e67a4b5f1fe8b20286 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73005 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-15soc/amd/common: Move missing APCB warning to common areaFred Reitberger
Move missing APCB warning from birman to amd/common so that other mainboards can utilize the same warnings if the APCB is missing. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I7ae689726ae4f7ccdf6959e47cbb5aee15cdb690 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-15soc/amd/common/Makefile.inc: Extend if case coverageFred Reitberger
Extend the coverage of the 'ifeq ($(CONFIG_SOC_AMD_COMMON),y)' case to the entire file. This matches the coverage of the related Kconfig. Add comments to endif to show which if they are ending. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I369e23e7ee9463ca1ae487d1e2181c760ae1bab2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70208 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-14amdfwtool: use SoC ID info instead of misleading comboable flagZheng Bao
Since it actually depends on the SoC type whether the old PSP directory table pointer or the new comboable PSP directory table pointer is used in EFS, get this information from the SoC ID instead of passing the comboable flag for the SoCs that need to use the new comboable PSP directory table pointer. TEST=Binary identical on amd/majolica, pcengines/apu2, amd/gardenia Change-Id: I0c3f21065939d1b13c2607aba16cbef74dd8d389 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73020 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-13soc/amd/mendocino: Add support for selective GOP driver initMatt DeVillier
Add support for the selective GOP init feature by only running the FSP GOP driver when necessary: if the FMAP cache is invalid, or if the board is booted in either recovery or developer mode. BUG=b:255812886 TEST=tested with rest of patch train Change-Id: I7ddadc254e05aca0fdd7a9567160a9329cb0e15c Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-02-13soc/amd/common/block/gfx: Use TPM-stored hash for vbios cache validationMatt DeVillier
Write the SHA256 hash of the cached VBIOS data when saving to FMAP, and use it to validate the data read from FMAP on subsequent boots. Add TPM2 as a dependency to the selection of VBIOS_CACHE_IN_FMAP. BUG=b:255812886 TEST=tested with rest of patch train Change-Id: I9c8f23b000b90a1072aeb7a57d3b7b2b2bc626dc Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72402 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-13soc/amd/common/Makefile: Only run amdfwread onceFred Reitberger
By saving the results of amdfwread into a file, it only needs to be run once instead of every time amdfwread-offset-size-cmd is called. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I1afaf65b9b2f9fb856aefc3ff37fb3a3442f6369 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72924 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-13soc/amd/mendocino: Add svc_write_postcode call instead of stubMartin Roth
To assist in debugging, add a way for PSP_verstage to send postcodes to the system. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I22e45e26f599a0b4f0b781e9b97fccb68e2e5cc1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71852 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-13soc/amd/common/block/acpi.ivrs: use SMBUS_DEVFN for FCH IOAPIC device IDFelix Held
Instead of using PCI_DEVFN(SMBUS_DEV, SMBUS_FUNC), use the equivalent SMBUS_DEVFN define. Even though the FCH IOAPIC is in the LPC part of the FCH, it needs the IVRS IOAPIC table's source_dev_id field set to SMBUS_DEVFN which is the function 0 of the FCH PCI device. LPC is function 3 of the FCH device. When assigning LPC_DEVFN to source_dev_id, the kernel from Ubuntu 2022.04 LTS complains about the IOAPIC part of the IVRS table being wrong: AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found AMD-Vi: Disabling interrupt remapping With SMBUS_DEVFN being used as source_dev_id, no such error is reported. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: I8470d67b2513031e75fb422d4c1c181e017ace0a Reviewed-on: https://review.coreboot.org/c/coreboot/+/70503 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-02-13soc/amd/phoenix: Expand APOB to 256KFred Reitberger
APOB on Phoenix is larger, so expand the reserved DRAM and MRC_CACHE regions to fit. This requires moving memory addresses around to prevent overlapping memory linker errors. TEST='./util/scripts/testsoc -K PHOENIX -K GLINDA' successfully builds all boards Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I42af7230ca5f09ba66b2b3c4f99ac3feac7feeea Reviewed-on: https://review.coreboot.org/c/coreboot/+/72905 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-02-11soc/amd/*/Makefile.inc: remove command line soc-nameZheng Bao
The function has already moved to fw.cfg. 4/5 of split changes of https://review.coreboot.org/c/coreboot/+/58552/28 Change-Id: Idf9e491ed46ae574ccd17f24925e3e5c595039fa Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72467 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-11soc/amd/*: Add SOC_NAME in fw.cfg(s)Zheng Bao
2/5 of split changes of https://review.coreboot.org/c/coreboot/+/58552/28 Change-Id: I18f73462a3995038fe93750320dfc053fec969ba Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-10soc/amd(MDN/PHX/Glinda): Update DISABLE_KEYBOARD_RESET_PIN helpMartin Roth
For MDN, PHX, & Glinda platforms, the Keyboard Reset functionality has been moved from GPIO 129 to GPIO 21. Additionally, the issue where the system would reset when the KBDRST_L pin went low even when not configured for Keyboard reset seems to have been fixed, so remove that text. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Iefe7e00d63777577b59ee98cb974b07afea1fd12 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72912 Reviewed-by: Jon Murphy <jpmurphy@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-02-10soc/amd/common/gfx: add support for VBIOS caching, selective GOP initMatt DeVillier
One of the main functions performed by the FSP GOP driver is to modify the ATOMBIOS tables (part of the VBIOS) in memory based on the display output configuration. This device-specific modified VBIOS can be cached in a FMAP region specific for that purpose, then loaded into memory instead of the "generic" VBIOS, saving the ~130ms execution time of the GOP driver. As this approach only works when no pre-OS display output is needed, limit its use to ChromeOS builds, with the GOP driver enabled, and not booting in either recovery or developer modes. SoCs supporting this feature will need to selectively run the FSP GOP driver as needed, using the same criteria used here to determine whether to load the VBIOS from CBFS or from the FMAP cache. Boards utilizing this feature will need to add a dedicated FMAP region with the appropriate name/size, and select the required Kconfig options. BUG=b:255812886 TEST=tested with rest of patch train Change-Id: Ib9cfd192500d411655a3c8fa436098897428109e Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com>
2023-02-09arch/x86/include/cpu: introduce CPU_TABLE_END CPU table terminatorFelix Held
Instead of having a magic entry in the CPU device ID table list to tell find_cpu_driver that it has reached the end of the list, introduce and use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID instead of the 0 in the CPU_TABLE_END definition. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-09amdfwtool: Add SOC family definition for CarrizoZheng Bao
For Carrizo, the soc name was set as UNKNOWN. The change is supposed to be binary unmodified, except the SPI settings. According to the spec, the Stoneyridge and Carrizo have the same definition of SPI setting in EFS. Change-Id: I9704a44773b2f541f650451ed883a51e2939e12a Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66823 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-09soc/amd/picasso/soc_util.c: Remove unneeded "break"Elyes Haouas
"break" is useless after "return". Change-Id: I84bc506a3d50e937797f42659299bf90ce392e09 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72895 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> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2023-02-09console: Add SimNow console loggingFred Reitberger
The AMD SimNow tool supports fast logging through an IO port. Add a new console to support SimNow logging through port 80. TEST=observe significant speed improvements on SimNow console log Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I42a431f48ea14ba4adacbd4a32e15abe7c5e4951 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72751 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-02-08soc/amd: use CPUID_FROM_FMS macro instead of magic numbersFelix Held
Port over the remaining AMD SoCs to use CPUID_FROM_FMS. The Glinda CPUID still needs to be updated to the actual CPUID, but for now just change it to use CPUID_FROM_FMS. TEST=Resulting image of timeless build for Gardenia (Stoneyridge), Majolica (Cezanne), Chausie (Mendocino), Mayan (Phoenix) and Birman (Glinda) don't change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia508f857d06f3c15e3ac9f813302471348ce3d89 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72862 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/phoenix/soc_util: add get_soc_typeFelix Held
Implement a get_soc_type function to determine if the silicon the code is running on is Phoenix or Phoenix 2. This will for example be needed to provide the correct DXIO descriptor table for the SoC. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5f2b668b83432426b04e7f1354b694ddd6c300d6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72861 Reviewed-by: ritul guru <ritul.bits@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/picasso/soc_util: use cpuid_matchFelix Held
Now that there is a cpuid_match function, we can use it instead of doing basically the same thing manually. In the functions is_fam17_1x and is_fam17_2x both the stepping number and the lower nibble of the model number are masked out. To avoid having magic constants in the code, introduce the CPUID_ALL_STEPPINGS_AND_BASE_MODELS_MASK definition. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I758f9564c08c62c747cc4f93a8d6b540a1834a62 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72860 Reviewed-by: Fred Reitberger <reitbergerfred@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-02-08soc/amd/picasso: use CPUID_FROM_FMS macro instead of magic numbersFelix Held
TEST=Resulting image of timeless build for Mandolin doesn't change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I44cb7759206e9e1ce79fd57f62b9a844e52f7394 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72857 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/stoneyridge/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all family 15h model 60h and 70h steppings. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id05f849d59c04efa9f38dd66892f3cb99d94e3ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/72855 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/phoenix/include/cpu: add Phoenix CPUIDFelix Held
There are multiple Phoenix steppings, but that is now covered by using CPUID_ALL_STEPPINGS_MASK. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id4eb3502dec5ebdfdbba263b15b34621952d0554 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72853 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/glinda/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Glinda steppings once GLINDA_A0_CPUID is updated. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic9b8cbb2dc925a8258db6a4eb0d1b00b2745637f Reviewed-on: https://review.coreboot.org/c/coreboot/+/72852 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/phoenix/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Phoenix 2 steppings that might be available in the future. Right now it shouldn't change any behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9878b4687360250cac4cfe1409d5dbad7147cf3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72851 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/mendocino/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Mendocino steppings that might be available in the future. Right now it shouldn't change any behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77ea8c6162667e0a318176e62078b1f57726c10c Reviewed-on: https://review.coreboot.org/c/coreboot/+/72850 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/cezanne: use CPUID_ALL_STEPPINGS_MASK to support all steppingsFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Cezanne steppings. This adds support for Cezanne stepping A1 and possible future steppings. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idb020052685d9369109f391797fdd8f8790a91d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72849 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08soc/amd/picasso/cpu: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry per family & model combination and not one per stepping. TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81) still finished mpinit and boots successfully even though now only PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as device match mask. When commenting out the line with PICASSO_B0_CPUID as a negative test, mpinit fails as expected. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2023-02-08arch/x86/cpu: introduce and use device_match_maskFelix Held
Instead of always doing exact matches between the CPUID read in identify_cpu and the device entries of the CPU device ID table, offer the possibility to use a bit mask in the CPUID matching. This allows covering all steppings of a CPU family/model with one entry and avoids that case of a missing new stepping causing the CPUs not being properly initialized. Some of the CPU device ID tables can now be deduplicated using the CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0540b514ca42591c0d3468307a82b5612585f614 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2023-02-08soc/amd/common/data_fabric: print decoded control register contentsFelix Held
Since all SoCs define the df_mmio_control union for the bits used in the code, data_fabric_print_mmio_conf can take advantage of that and also print a decoded version of those bits. Output on Mandolin before the patch: === Data Fabric MMIO configuration registers === idx control base limit 0 93 fc000000 febfffff 1 93 10000000000 ffffffffffff 2 93 d0000000 f7ffffff 3 1093 fed00000 fedfffff 4 90 0 ffff 5 90 0 ffff 6 90 0 ffff 7 90 0 ffff Output on Mandolin with the patch: === Data Fabric MMIO configuration registers === idx base limit control R W NP F-ID 0 fc000000 febfffff 93 x x 9 1 10000000000 ffffffffffff 93 x x 9 2 d0000000 f7ffffff 93 x x 9 3 fed00000 fedfffff 1093 x x x 9 4 0 ffff 90 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I06e1d3a3e9abd664f59f2bb852394e7f723f2b30 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/mendocino/data_fabric: add Rembrandt DF_MMIO_REG_SET_SIZEFelix Held
In contrast to Mendocino and all other AMD SoCs in the coreboot tree, Rembrandt, on which Mendocino is based on, has a DF_MMIO_REG_SET_SIZE of 3 instead of 4, so the next data fabric MMIO register is 3 DWORDs after the last one instead of the 4 DWORDs on the other SoCs. This was checked against PPR #56558 Rev 3.04. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I454ad5d182f0040db93c9b3a83941333392c6061 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72879 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/*/data_fabric: introduce and use DF_MMIO_REG_SET_SIZEFelix Held
To be able to handle a special case, add a per-SoC define for DF_MMIO_REG_SET_SIZE instead of having this hard-coded as 4 in the DF_MMIO_* macros. To avoid some duplication, also introduce the DF_MMIO_REG_OFFSET macro. TEST=Output from data_fabric_print_mmio_conf doesn't change on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I67420a2973c8ef9a7f0ce19ddc0013de69731689 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72878 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/common/data_fabric: replace NB with DF prefix for DF registersFelix Held
Since the MMIO decode range registers in the data fabric are part of the data fabric and not of the northbridge, replace the NB prefix with a DF prefix to make this a bit clearer. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ife5e4581752825e9224b50252955d485a067af74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72877 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/*/data_fabric: rename define for MMIO decode register set countFelix Held
This should make it a bit clearer that those registers are in the data fabric configuration registers. Also move those defines right after the register definition those are related to. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic107bd217f4af0a9ddfbe41aafd3c882aa968e22 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72876 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/phoenix/include/cpu: rename CPUID define to match CPU modelFelix Held
CPUID 0x00a70f80 is Phoenix 2 and not Phoenix, so update the define name to match. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie7500130d5470fdd824980b81746f3a0f6d277d4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72843 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: ritul guru <ritul.bits@gmail.com> 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-02-07soc/amd/stoneyridge/acpi: use acpigen_write_processor_deviceFelix Held
Since things are done a bit differently on Stoneyridge, it's probably safer to run a test instead of assuming that the test on Picasso was sufficient to be reasonably sure that this will also work as expected on Stoneyridge. TEST=No change of ACPI-related messages in dmesg with this patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I432752fae8be08d3cbd7d30215b350c4528c7206 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72495 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-02-07soc/amd/common/data_fabric_helper: normalize addresses in debug printFelix Held
Instead of just printing the register contents, normalize the contents of the base and limit registers to actual MMIO addresses and then print those. This will hopefully avoid some confusion caused by the shifted addresses. Output on Mandolin before the patch: === Data Fabric MMIO configuration registers === Addresses are shifted to the right by 16 bits. idx control base limit 0 93 fc00 febf 1 93 1000000 ffffffff 2 93 d000 f7ff 3 1093 fed0 fedf 4 90 0 0 5 90 0 0 6 90 0 0 7 90 0 0 Output on Mandolin after the patch: === Data Fabric MMIO configuration registers === idx control base limit 0 93 fc000000 febfffff 1 93 10000000000 ffffffffffff 2 93 d0000000 f7ffffff 3 1093 fed00000 fedfffff 4 90 0 ffff 5 90 0 ffff 6 90 0 ffff 7 90 0 ffff Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I62eeb88ddac6a7a421fccc8e433523459117976a Reviewed-on: https://review.coreboot.org/c/coreboot/+/72739 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-06soc/amd/glinda: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Glinda SoC, remove it form the global NVS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I627d05c09d9637caf15e17285dd2c8e0389747c5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72187 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-02-06soc/amd/phoenix: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Phoenix SoC, remove it form the global NVS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I24ad0a2fbc5a973c0cb40ed10942b5efc31191aa Reviewed-on: https://review.coreboot.org/c/coreboot/+/72186 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-02-06soc/amd/mendocino: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Mendocino SoC, remove it form the global NVS and add an ACPI object for this in the DSDT of the mainboards that use it in their ACPI code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1ed0407826f579eb14169246b7b14ba677c20e8d Reviewed-on: https://review.coreboot.org/c/coreboot/+/72185 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-02-06soc/amd/cezanne: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Cezanne SoC, remove it form the global NVS and add an ACPI object for this in the DSDT of the mainboards that use it in their ACPI code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6953da5e0f1966aa3022364d9a9c72ebafc698cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/72184 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-02-06soc/amd/picasso: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Picasso SoC, remove it form the global NVS and add an ACPI object for this in the DSDT of the mainboards that use it in their ACPI code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia265f3eebf5e48c185d2e4bf4ef74f8eab7c9606 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72183 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-02-06soc/amd/stoneyridge: remove LIDS field from global NVSFelix Held
Since the LIDS field is only used in the ACPI code and not in the C code of any mainboard using the Stoneyridge SoC, remove it form the global NVS and add an ACPI object for this in the DSDT of the mainboards that use it in their ACPI code. Eventually the LIDS object should probably be moved to the EC's ACPI code, but that's out of scope for this patch. TEST=google/liara doesn't show ACPI errors in Linux' dmesg Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I778c4189607035b4765c6cb8b2e74030dcf9069f Reviewed-on: https://review.coreboot.org/c/coreboot/+/72182 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-02-04soc/amd/phoenix/chipset.cb: update USB portsFelix Held
Not exactly sure about the usb4_xhci controllers, but for now I assume those will behave like any other XHCI controller. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I22384f58e245a1486793831d29d22e9c618f646c Reviewed-on: https://review.coreboot.org/c/coreboot/+/72773 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-04soc/amd/phoenix/chipset.cb: add remaining PCI devicesFelix Held
The PCI Device ID Assignments table from PPRs #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference. Some devices will need to have ops added in future patches. Since the xhci_2 device isn't there any more, also drop it from the mainboard devicetrees. The actual USB port configuration on xhci_0 and xhci_1 is updated in the next patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I49721bc44fa1e2a0118a8c3ac79a36aee64be687 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72771 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-02-04soc/amd/phoenix/chipset.cb: rename GPP bridges on device 2Felix Held
Now that the PCIe ports on device 1 are added, rename the aliases for the PCIe ports on device 2 to have a common naming scheme. For phoenix the device alias names are based on the device and function number the bridge is connected to. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5f5698408019bb9222b599dd78540ca1b187b56d Reviewed-on: https://review.coreboot.org/c/coreboot/+/72737 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-04soc/amd/phoenix/chipset.cb: add missing GPP bridges on device 1Felix Held
Only the PCIe ports on the functions of device 2 were present in the devicetree and had the amd_external_pcie_gpp_ops ops assigned. Add the missing PCIe ports on the functions of device 1 and assign the amd_external_pcie_gpp_ops ops to them. This SoC uses a slightly different naming scheme for its PCIe GPP ports. Previously the PCIe GPP bridge number from the PCI Device ID Assignments table from the PPR was used. Those bridge numbers are one less than the function numbers of the device. This is due to function 0 being a dummy bridge to avoid having to shuffle around the function numbers when the first bridge is unused, since the PCIe specification mandates the function 0 to be implemented if any other function on the same device is implemented. In order for the device aliases to be consistent with the PCIe device and function numbers which is way more commonly used and also what lspci shows and what goes into the DXIO descriptors, change the naming scheme of the aliases. This was checked with PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib5c62c1df585877d9b6986a462a3636d4f2eb4c7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72736 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-04soc/amd/cezanne/chipset.cb: add missing ops for GPP GFX bridgesFelix Held
Commit b171f768127d ("soc/amd/*: Hook up GPP bridges ops to devicetree") missed adding the amd_external_pcie_gpp_ops ops to the gpp_gfx_bridge PCIe ports, so add them. Those devices were previously covered by the PCI_DID_AMD_FAM17H_MODEL60H_PCIE_GPP_D1 PCI device ID in the list that got removed in the referenced commit. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I55434bf486569b32901b3840193a09cc5955abb2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72735 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-04soc/amd: Use common reset code for PCO SoCMartin Roth
This switches the Picasso SoC to use the common reset code. Picasso supports warm resets, so set the SOC_AMD_SUPPORTS_WARM_RESET flag. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I52515b20ef6c70b137f176d95480757b16bd8735 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72755 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-04soc/amd: Use common reset code for PHX & Glinda SoCsMartin Roth
This switches the Phoenix & Glinda SoCs to use the common reset code. Cezanne and newer do not support warm reset, so use cold resets in all cases (including the OS). Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I4593fa9766ac9e988722a02e355c971e147b8fae Reviewed-on: https://review.coreboot.org/c/coreboot/+/72754 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-04soc/amd: Use common reset code for CZN & MDN SoCsMartin Roth
This switches the Cezanne & Mendocino SoCs to use the common reset code. This patch does not change any behavior on those chips. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ie05c790573e4e68f3ec91bacffcc7d7efb986d79 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72659 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-04soc/amd: Create AMD common reset codeMartin Roth
This allows us to use the same file for PCO, CZN, MDN, PHX, & Glinda. PCO supports the warm reset, and future chips can support it by setting the SOC_AMD_SUPPORTS_WARM_RESET option. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ib6459e7ab82aacbe57b4c2fc5bbb3759dc5266f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72658 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-01soc/amd/mendocino: Force resets to be coldMartin Roth
Like Cezanne, Mendocino does not support warm resets. Change all resets (including resets in the OS) to cold resets (like Cezanne). BUG=b:248221908 TEST=Run suspend_stress_test, then reboot Change-Id: I1fbb4cc6eb6e6de9616d00d0191ccf3c0ac55278 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72486 Reviewed-by: Jon Murphy <jpmurphy@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com>
2023-02-01treewide: Remove duplicated include <device/pci.h>Elyes Haouas
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>. Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-31soc/amd/glinda/acpi: use acpigen_write_processor_deviceFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iec9cf7c195fa5cb5c8d992aeab400d05cbe801c2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72494 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-01-31soc/amd/phoenix/acpi: use acpigen_write_processor_deviceFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I103cdce8c23ff4adbf1057fa26bd67275f2ab0e5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72493 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-01-31soc/amd/mendocino/acpi: use acpigen_write_processor_deviceFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I036dcddf89e8d865d0dc3ef0bd9e48842d8bf6c3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72492 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-01-31soc/amd/cezanne/acpi: use acpigen_write_processor_deviceFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77a91c0a6d937772bf25fa936cec8a710b9acf72 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72491 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-01-31soc/amd/picasso/acpi: use acpigen_write_processor_deviceFelix Held
In CB:71614 Kyösti pointed out that ACPI_GPE0_BLK is the wrong address to assign to proc_blk_addr; the correct one would be ACPI_CPU_CONTROL. When looking a bit closer into this, it turned out that acpigen_write_processor is generating deprecated AML opcodes, so replace the acpigen_write_processor call with a call to the newly added acpigen_write_processor_device function that also doesn't have the proc_blk_addr and proc_blk_len parameters. The information about the IO port for entering C-states is already written into an SSDT by acpigen_write_CST_package which is likely also the reason why the wrong proc_blk_addr value wasn't noticed for a very long time. TEST=Mandolin still boots Ubuntu 22.04 LTS and Windows 10 and no possibly related errors show up. Linux gets the expected C-state information from the _CST package inside the processor device scope. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie67416e19e431029dd12da66ad44ddfa8586df03 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72490 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 19:16:49 +0000