summaryrefslogtreecommitdiff
path: root/src/soc/amd/phoenix
AgeCommit message (Collapse)Author
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-11-16 04:44:58 +0000