summaryrefslogtreecommitdiff
path: root/src/soc/amd/phoenix
AgeCommit message (Collapse)Author
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-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/cpu/tsc: factor out family-specific get_pstate_core_freqFelix Held
Factor out the get_pstate_core_freq function from the SoC's acpi.c files to both avoid duplication and to also be able to use the same function in the TSC frequency calculation in a follow-up patch. The family 17h and 19h SoCs use the same frequency encoding in the P state MSRs while the family 1Ah SoCs use a different encoding. The family 15h and 16h SoCs use another encoding, but since this isn't implemented in Stoneyridge's acpi.c, this will be added in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-27soc/amd: factor out common get_pstate_core_power implementationFelix Held
Now that all get_pstate_core_power implementations in each SoC's acpi.c file is identical, factor it out into a common implementation. This implementation will also work for Stoneyridge which isn't using the common P state code yet. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_pstate_core_uvolts for SVI2 and SVI3Felix Held
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage ID version specific function is needed to get the raw core VID value. This will allow making get_pstate_core_power common for all AMD CPUs in a follow-up patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-27soc/amd: introduce and use get_uvolts_from_vid for SVI2 and SVI3Felix Held
Instead of implementing the conversion from the raw serial voltage ID value to the voltage in microvolts in every SoC, introduce the SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the correct version, implement get_uvolts_from_vid for both cases and only include the selected implementation in the build. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I344641217e6e4654fd281d434b88e346e0482f57 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-24soc/amd/*/include/msr: add version number to SERIAL_VID_* define namesFelix Held
Picasso and Cezanne use the serial voltage ID 2 standard to communicate the CPU voltage to the voltage regulator module on the mainboard, while Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for this. Both standards encode the voltage in a different way, so add the serial VID version number to the defines to clarify for which version the define is. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-03-24soc/amd/*/include/msr: drop _LO part from PSTATE definition namesFelix Held
The _LO part in the definition names is a leftover from before moving to the pstate_msr union access to the bitfield elements where it still mattered if a bit was in the lower of higher half of the MSR. With the mask-and-shift access to the two parts of the MSR being gone, the _LO part in the name isn't useful any more and possibly a bit misleading, so drop that part. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib43c71e946388c944ecf40659d4c12ca02a27a5d Reviewed-on: https://review.coreboot.org/c/coreboot/+/73927 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-24soc/amd: pass pstate_msr union to get_pstate_core_[freq,power]Felix Held
Since we already have and use the pstate_msr union in get_pstate_info, also pass it directly to the get_pstate_core_freq and get_pstate_core_power function calls avoids having to sort-of convert the msr_t type parameter in the implementations of those two functions. In amdblocks/cpu.h a forward declaration of the pstate_msr union is used since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include amdblocks/cpu.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-23soc/amd/phoenix: introduce and use pstate_msr bitfield structFelix Held
Add the pstate_msr union of a bitfield struct and a raw uint64_t to allow easier access of the bitfields of the P state MSRs and use this bitfield struct in get_pstate_core_freq and get_pstate_core_power. The signature of those two function will be changed in a follow-up commit. PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference as well as the reference code. This patch also adds and uses the cpu_vid_8 bit which is the 9th bit of the voltage ID specified in the SVI3 spec. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia024d32ae75cf2ffbc2a2e86a8b3af3dc6cbad61 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73923 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> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-03-22soc/amd/*/acpi: assign proper boolean values in get_pstate_core_freqFelix Held
Assign true/false instead of 1/0 to the valid_freq_divisor bool variable in get_pstate_core_freq. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I92d0eb029c55f80a2027ff6d404c63ed84282750 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73880 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-15soc/amd: Print amdfwtool debug info if V=1Martin Roth
When doing coreboot builds, we can set V=1 to see all of the make info printed as the compile is happening. Use this flag to set the debug flag for amdfwtool so it doesn't have to be enabled separately. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-03-13soc/amd/phoenix/mca.c: Remove excess MCA bank namesFred Reitberger
Documentation and hardware differ in the number of MCA bank names, so remove the excess ones to prevent a "CPU has an unexpected number of MCA banks!" warning message. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I75a2348561833f3f19181b4f30a6971ecb317899 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73650 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-03-10amdfwtool: Add HW IPCFG file whose subprog is 1Zheng Bao
And rename PSP_HW_IPCFG_FILE to PSP_HW_IPCFG_FILE_SUB0 Change-Id: Ia1ab8482074105de367905be2b4b0418066823d2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73531 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-10src/soc/amd/phoenix/include/soc/: Update the Data Fabric ID for PhoenixAnand Vaikar
Change-Id: I078b57825377f97f9f5f2b607fa134e3a67e9685 Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73557 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: ritul guru <ritul.bits@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd: factor out ACPI_SSDT_PSD_INDEPENDENT to common AMD ACPI KconfigFelix Held
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the Kconfig symbol to the Kconfig file in this directory. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/include/msr: factor out P state MSR enable bit to cpu/amd/msr.hFelix Held
The bit position of the P state enable bit in the 8 P state MSRs is identical for all AMD chips including the family 16h model 30h APU that lives outside of soc/amd. The other bits in those 8 MSRs are more or less family- and model-specific. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-08soc/amd/*/acpi: factor out common get_pstate_info implementationFelix Held
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. The SoC-specific get_pstate_core_freq and get_pstate_core_power functions remain in the SoC-specific code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/*/acpi: factor out common generate_cpu_entries implementationFelix Held
With the exception of the generate_cppc_entries call, the implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino, Phoenix and Glinda are identical, so factor it out and move it to the common AMD SoC code. Since all SoCs that support CPPC already select the SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only call generate_cppc_entries for platforms where it is available. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/phoenix: Allow the amdfw.rom to be split into two partsZheng Bao
Split the big PSP FW data into two parts, head and body. The head needs to be located at original specific location. The body address is more flexible. So the big body will not cover other needed FWs like EC. Give the body a specific named AMDFWBODY, which should be defined in flashmap. This is one of series of patches to support 32/64M flash. BUG=b:255374782 Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-08soc/amd/phoenix/acpi: rework C state info table handlingFelix Held
Rework the way the C state info is generated before it gets passed to acpigen_write_CST_package in generate_cpu_entries by separating the data from the code. For this, the newly introduced common get_cstate_info function is used. Separating the data from the code will eventually allow moving generate_cpu_entries to the common AMD code. The actual values in cstate_cfg_table haven't been checked against the reference code yet. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502 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-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/*/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/*/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-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-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-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-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/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-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-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/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/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-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/*/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/*/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-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-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: 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-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-22soc/amd/*: Enable override of MAINBOARD_BLOBS_DIRFred Reitberger
MAINBOARD_BLOBS_DIR is defined the same way by picasso/cezanne/mendocino/phoenix/glinda and unused by stoneyridge, so move it to a common area. This makefile variable is currently only used to locate APCB blobs for the different mainboards. Add a Kconfig option to point to the APCB blobs directory. This allows simple overriding to locations such as site-local. TEST=Timeless builds Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I0702fdb97fbc2c73d97994ab4d5161ff0f467518 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69410 Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-20soc/amd/glinda,mendocino,phoenix/espi_util: add comment about registerFelix Held
Even though the register name begins with ESPI, it resides in the SPI registers and not in the eSPI registers, so add a comment to point this out to hopefully avoid some confusion. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9f8d15ceb98f51aad0816021f98ec5c78953e7f3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72122 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-01-20soc/amd/phoenix/espi_util: remove TODO after checkingFelix Held
Checked against both documents #57019 revision 1.59 and #57396 revision 1.50 that the definitions and the code still apply to Phoenix. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id65301ec730793f41044696f2e99356f2e899137 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72120 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-01-20soc/amd/phoenix: clean up global NVSFelix Held
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C and ACPI code, so they can be removed. Also remove the unused fields that were previously used for PCNT and PWRS. The LIDS field is only used in the ACPI code, but keep if for now, since it would require a bigger rework to remove it from the global NVS. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5a9b0a24f57a81b98c7553517fe5f25ff63c5316 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72095 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-18soc/amd/*/agesa_acpi: add TODO for adding CRAT tableFelix Held
The Picasso SoC code generates a CRAT ACPI table which is not done for Cezanne and newer. A significant part of the Picasso CRAT generation code can likely be moved to the common AMD SoC code and then used in all SoCs, but this still needs to be checked. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8f1ebe74f0376c60396dbd80e64676d1374ed811 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72027 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-18soc/amd/phoenix/agesa_acpi: use acpi_align_current to align IVRS & ALIBFelix Held
This changes the alignment of the IVRS table from 8 bytes to 16 bytes and aligns the ALIB table to a 16 byte boundary. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I766260aefcac6876609d6b45202b41a3e9e44385 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72025 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-18soc/amd: Include <gpio.h> instead of <soc/gpio.h>Elyes Haouas
<gpio.h> chain-include <soc/gpio.h>. Change-Id: I112e41ad4c7ee638954dfe3f1ddfeb10c138459a Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71807 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-17soc/amd: introduce and use common amd_cpu_bus_ops structFelix Held
The device operations for the CPU bus are identical for all AMD SoCs, so introduce a common device operations struct for this and use it in all AMD SoC's chipset devicetrees as ops for the CPU cluster. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id32f89b8a33db8dbb747b917eeac3009fbae6631 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71998 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-17soc/amd: Use fixed EFS location for Phoenix & GlindaMartin Roth
The AMD SoCs no longer have a variable position for EFS - it's now fixed at 0xff020000 - 128KiB into the 16MiB ROM decode region. It's a little more complex than that because the chip can be larger than 16MiB, and the entire ROM can be decoded if mapped above the 4GiB boundary, but we don't currently support doing that in coreboot, so this is enough for now. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I343a875ba9aa8294a090f2eff7b5dfb5e86334f8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71769 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-17treewide: Fix old-style declarationsElyes Haouas
Replace old style declaration "const static" with "static const". This to enable "Wold-style-declaration" command option. Change-Id: I757632befed1854f422daaf4dfea58281b16e2f5 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71841 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-01-13soc/amd/phoenix: update mmconf base address and sizeRitul Guru
0xF8000000 was taken from old platform during phoenix porting, updating it to 0xE0000000 to make room for 256 pci busses which is required for usb4 and hotplug support. mmconf size gets set to 0x10000000 when 256 busses are used. Change-Id: Ic143171f5650aff5db48c8f477d7aca3e7f5c1e7 Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71870 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-13soc/amd/phoenix: use common SMU S3/4/5 entry message codeFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie7ded68f4732ec12a1c7e59445d572763a03c3b9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71879 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-01-13soc/amd/phoenix: Use common fsp-s preloaderFred Reitberger
Use the common preloader for fsp-s Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Iea7011d37667f3f04ce842038346741fba66b1dc Reviewed-on: https://review.coreboot.org/c/coreboot/+/71847 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-123rdparty/amd_blobs:Advance submodule pointerJason Glenesk
This picks up the following changes: acf73954 phoenix: rename morgana to phoenix a2c15297 mendocino: Upgrade SMU to 90.35.166 28983855 Update Picasso FSP binaries This also updates the phoenix fw.cfg file that points to the submodule. Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I1d04d6232307dc913645a3d60ac3711018e2bdfb Reviewed-on: https://review.coreboot.org/c/coreboot/+/71803 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-12soc/amd: Change Morgana codename to PhoenixMartin Roth
Now that the next generation of APUs is officially announced, we can unmask morgana. The chip formerly known as Morgana is actually Phoenix. Surprise! This patch just changes the name across the entire codebase. Note that the fw.cfg file will stay pointing to the 3rdparty/amd_blobs/morgana/psp directory until the amd_blobs_repo is updated. Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: Ie9492a30ae9ff9cd7e15e0f2d239c32190ad4956 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71731 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-16 00:00:52 +0000