summaryrefslogtreecommitdiff
path: root/src/soc/amd/stoneyridge
AgeCommit message (Collapse)Author
2023-04-01soc/amd/stoneyridge: factor out P-state utils to link in all stagesFelix Held
tsc_freq.c gets built into all stages, but the tsc_freq_mhz function it implements calls the get_pstate_0_reg function which was only built into ramstage. Since tsc_freq_mhz was only called in ramstage, commit 2323acab6a7a ("soc/amd/stoneyridge: implement and use get_pstate_0_reg") didn't cause the build to fail, but better factor out the P-state- related utility functions into a separate compilation unit and include it in all stages that also include tsc_freq.c. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id3a3ee218f495be5e60a888944487704e7e8a1a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74145 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-01soc/amd/stoneyridge/Makefile: use all target for more compilation unitsFelix Held
monotonic_timer.c, tsc_freq.c and uart.c get added to all stage targets, so just add those to the all stage targets. They still need to be added to the smm stage target, since the all target doesn't add things to the smm stage. TEST=Timeless build results in identical image for Gardenia. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I16c02bc0ff54553f212b94d110abef6a7bdedbb4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74144 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-29soc/amd/stoneyridge: use common AMD CPU power state ACPI generationFelix Held
Instead of using the PSTATE SSDT generated by binaryPI, use the common AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There are two differences to the binaryPI SSDT: Now coreboot includes the C1 state in the _CST package instead of just having the kernel add this due to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the PS_STS_REG P state status MSR is written to the corresponding field of the _PCT package instead of being 0. TEST=On Careena the new P and C state ACPI packages are nearly identical to the ones from the SSDT from binaryPI with the two functional differences mentioned above. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge/cpu: implement get_pstate_latencyFelix Held
Both the algorithm and the registers involved are described in the public version of BKDG #55072 Rev 3.09 in chapter 2.5.2.1.7.3.2 _PSS (Performance Supported States). Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9b2c177d9d80c5c205340f3f428186d6b8eb7e98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74025 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge: implement and use get_pstate_0_regFelix Held
Introduce get_pstate_0_reg and use it in tsc_freq_mhz to get the P state register number corresponding to P state 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b92a858bf36b04a570d99c656e5ccfc84457724 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74022 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge/acpi: add C state config tableFelix Held
The C state ACPI packages binaryPI generates and passes to coreboot in the PSTATE SSDT only include the C2 state, but the kernel will add the C1 state to its usable C states in this case. The native C state code will generate both the C1 and C2 state packages to be more complete and also to be more in line with the other AMD SoCs. The code added in this commit isn't used yet, but will be used as soon as Stoneyridge will be using the common AMD generate_cpu_entries by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed helper functions are implemented for Stoneyridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge/tsc_freq: use get_pstate_core_freqFelix Held
Use get_pstate_core_freq instead of open-coding the calculations in tsc_freq_mhz. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If5d526e6b365c62a6669241f4fcdd25eca3f15fd Reviewed-on: https://review.coreboot.org/c/coreboot/+/74012 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/common/cpu/tsc: add get_pstate_core_freq for family 15h and 16hFelix Held
This function will be used in follow-up patches for both the TSC rate calculation and the still to be implemented P state ACPI table generation in coreboot. The was checked against BKDG 52740 Rev 3.05, BKDG #55072 Rev 3.04, and BKDG #50742 Rev 3.08. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9afaa044da994d330c3e546b774eb1f82e4f30e4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74011 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-29soc/amd/stoneyridge/monotonic_time: add comment that we can't use TSCFelix Held
Due to a non-constant TSC rate before the microcode update is applied, the Performance Time Stamp Counter is used instead. To clarify this, add a comment to the timestamp_get implementation. See commit 24079323d4d8 ("soc/amd/stoneyridge: provide alternate monotonic timer") and the description of the TscInvariant bit in CPUID Fn8000_0007_EDX Advanced Power Management Information in the public version of BKDG #55072 Rev 3.09 for more details. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I824b372c36fa6f3eb912469b235a9474f6a58ff5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74018 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-03-28soc/amd/stoneyridge/graphics: introduce defines for constantsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2021a106e0d3a603b1a05296411700ffea32fc8c Reviewed-on: https://review.coreboot.org/c/coreboot/+/74042 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-28soc/amd/stoneyridge: move map_oprom_vendev to graphics.cFelix Held
Move map_oprom_vendev to graphics.c to match the other AMD SoCs. Also change the comment style to be more in line with the rest of coreboot and drop the unneeded line break in the printk call. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icc1f3d73fba973413c5a22e2f5ae01bc58bc3e76 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74041 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-28soc/amd/stoneyridge/Kconfig: use correct VGA_BIOS_IDFelix Held
Fix the VGA_BIOS_ID IDs to match the PCI IDs in the VBIOS binaries and the PCI ID Stoneyidge's map_oprom_vendev returns. This fixes the problem that the display wasn't initialized due to not finding the VBIOS file in CBFS. This bug in the Stoneyridge Kconfig was unmasked by commit 42f0396a1028 ("device/pci_rom: rework PCI ID remapping in pci_rom_probe"). TEST=Display in Careena lights up again. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4d1e6a3a65d7d7b07f49df9ce90620b79d9a2d78 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74019 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-27soc/amd/stoneyridge/Kconfig: select SOC_AMD_COMMON_BLOCK_SVI2Felix Held
Stoneyridge uses the serial voltage ID 2 standard to tell the VRM on the board which voltage it wants, so select the SOC_AMD_COMMON_BLOCK_SVI2 Kconfig option to have the corresponding code to decode the raw SVI2 value into a voltage. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7d7031d9ad997a86c18d0e9e7af9a88ddf2d873c Reviewed-on: https://review.coreboot.org/c/coreboot/+/73999 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-03-27soc/amd/stoneyridge/include/msr: add 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 which will be used in future patches to generate the P state ACPI packages for the CPU objects. BKDG #55072 Rev 3.04 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I944c8598ba95a0333124655c61ef9eba8a7595c9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73998 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-10soc/amd/stoneyridge/monotonic_timer: use raw MSR dataFelix Held
Since mst_t is a union of the struct containing the lower and higher 32 bits and the raw 64 bit value, there's no need to convert the lower and higher 32 bits into a 64 bit value and we can just use the 64 bit raw value. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibc5d64c74eaabfc4b7834a34410b48f590f78a12 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73637 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-03-08soc/amd/stoneyridge/romstage: pass C state control IO base addressFelix Held
Instead of hoping that the default the C state control IO address in binaryPI won't interfere with any other IO space usage in coreboot, assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform config structure element to make sure that binaryPI will use a known address for the IO port based C state control. binaryPI will write this address to the MSR_CSTATE_ADDRESS and will then also use these IO ports in the _CST packages in the PSTATE SSDT, so changing this won't cause a mismatch between those two. The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on Careena is 0x1770, so this didn't collide with any other IO space registers, but it's still much better to tell binaryPI which exact IO addresses to use. TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in the _CST package entry for the second C state which are both the expected values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.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/*/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-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,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-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-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-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-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-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-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/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-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-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-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-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-22soc/amd/stoneyridge,sb/amd/pi/hudson: Remove unused AHCI_ROM_IDElyes Haouas
Change-Id: I0a3a3d8b3f898dc147eff54fe4ae2611139951ac Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72143 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-22soc/amd/stoneyridge: clean up global NVSFelix Held
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: I6b172214998818f841f5694f47815eddfaf9deaa Reviewed-on: https://review.coreboot.org/c/coreboot/+/72139 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-19soc/amd/stoneyridge/northbridge: use acpi_align_currentFelix Held
Use acpi_align_current to align the ACPI tables on a 16 byte boundary. This changes the alignment of the HEST, IVRS, SRAT and SLIT tables from 8 bytes to 16 bytes. The alignment of the ALIB and PSTATE SSDT tables was already 16 bytes before, so the alignment of those isn't changed. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8933e3731b67012bcae0773db2f7f8de7cd31b56 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72055 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-12treewide: Remove unused <cpu/amd/mtrr.h>Elyes Haouas
Change-Id: Ibff33c08a1d583b19b205a66d5a4267df65ced75 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64940 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-01-09treewide: Remove unused <cpu/amd/msr.h>Elyes Haouas
Change-Id: Id24a7c7db24f49672df9d5ceefec5b7596f23e09 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-01-09soc/amd: Remove dummy SOC_SPECIFIC_OPTIONSElyes Haouas
Change-Id: I080b7b579338c3cf342beabda54f43f525d8b65c Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71679 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-12-27tree/acpi: Replace constant "Zero" with actual numberFelix Singer
Change-Id: I5a3e3506415f424bf0fdd48fc449520a76622af5 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71525 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-27{acpi,arch,soc}/acpi: Replace constant "One" with actual numberFelix Singer
Change-Id: I3dfd7dd1de3bd27c35c195bd43c4a5b8c5a2dc53 Signed-off-by: Felix Singer <felixsinger@posteo.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71522 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-06sb,soc/amd: Remove unused southbridge_io_trap_handler()Kyösti Mälkki
At the moment IO trap is not implemented for AMD platforms. Change-Id: Ib62ac4e4e418a8bab80c30dfb5183ecd8beb998d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70360 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-25ACPI: Use common code for MADT LAPIC NMIsKyösti Mälkki
Use the broadcast ID to deliver LINT1 as NMI to all CPUs, instead of listing individual LAPIC IDs. Change-Id: Iaf714d8c2aabd16c59c3bcebc4a207406fc85ca9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69527 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-24soc/amd: Define post codesMartin Roth
For the most part, this doesn't change any post codes, simply making the existing post-codes into macros. picasso/romstage.c did get a couple of post codes removed to match the other files. The POST_ROMSTAGE and POST_BOOTBLOCK codes are intended to become global at some point, while the POST_AGESA and POST_PSP codes would stay AMD specific. Change-Id: I007a09b6a3ed3280bac674cd74e298ec5c408ab7 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69867 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-18cbmem_top_chipset: Change the return value to uintptr_tElyes Haouas
Get rid of a lot of casts. Change-Id: I93645ef5dd270905ce421e68e342aff4c331eae6 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69078 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
2022-11-17soc/amd: Use ioapic helper functionsKyösti Mälkki
Calling setup_ioapic() was only correct for the IOAPIC routing GSI 0..15 that mimic legacy PIC IRQs. Change-Id: Ifdacc61b72f461ec6bea334fa06651c09a9695d6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55571 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-04soc/amd: Specify memory types supported by each chipMartin Roth
This change disables support for memory types not used by each of the chips. This will in turn remove the files for those memory types from the platform builds. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I8c7f47b43d8d4a89630fbd645a725e61d74bc2a5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68994 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Sean Rhodes <sean@starlabs.systems> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-11-03soc/amd: Include <cpu/cpu.h> instead of <arch/cpu.h>Elyes Haouas
Also sort includes. Change-Id: Iea29938623fe1b2bcdd7f869b0accbc1f8758e7a Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69033 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-29soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB deviceFelix Held
Don't set bit 2 in _STA in order for Windows not to show a warning about an unknown device in the device manager for this device. Since the _STA object just returns a constant, a name definition can be used instead of a method definition. TEST=The unknown device with device instance path ACPI\AAHB0000\0 disappeared from the device manager in Windows 10 build 19045 on a Mandolin board with a Picasso APU. Just shutting down and then booting it again won't clear some internal state in Windows, so a reboot is needed instead for the change to become visible. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8cb1712756c3623cc3ea16210af69cde0fa18f62 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68961 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-22soc/amd/*/i2c.h: Make definition more accurateFred Reitberger
Make GPIO_I2C_MASK macro more accurate by using the GPIO_I2Cx_SCL definitions instead of BIT(x). Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I13fc376552068a64768fe1cf9f1c09cca1768aed Reviewed-on: https://review.coreboot.org/c/coreboot/+/68682 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-21soc/amd/*/smi.h: Use BIT() for clarityFred Reitberger
Use the BIT() macro for single-bit constants. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I490f0093d55813260fcdb7303a94accfa90e75e4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68548 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-10-21soc/amd/*/uart: cleanup includesFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I59ab9c2eaa65d974d418123e87e9afe65b1168cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/68633 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd/*/uart: commonize UART code and MMIO device driverFelix Held
Now that the SoC-specific UART controller data and the common code part are cleanly separated, move the code to the common AMD UART support block folder. The code is identical to the UART code in Cezanne, Mendocino, Morgana and Picasso while Stoneyridge doesn't use the parts related to the MMIO device driver. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id9429dac44bc02147a839db89d06e8eded7f1af2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd: move set_uart_config prototype to common UART headerFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I97860292fd3cd0330fec40edb31089cd6608906b Reviewed-on: https://review.coreboot.org/c/coreboot/+/68560 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd: move all AOAC function prototypes to amdblocks/aoac.hFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3deae150cd1e20fff6507a0f0ba6a375fca430e5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68559 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd/stoneyridge/uart: introduce and use soc_get_uart_ctrlr_infoFelix Held
Introduce and use soc_get_uart_ctrlr_info to access the uart_info array to further decouple uart_info from the code as preparation to factor out most of the code to a common implementation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I813483bc0421043dc67c523f0ea2016a16a29f60 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68538 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd/stoneyridge: initialize GPIOs for serial consoleFelix Held
Initialize the two GPIOs of the SoC UART if it's used for serial console to be sure that the I/O mux is configured correctly without having to rely on the bootblock_mainboard_early_init call to do this. This brings Stoneyridge more in line with the other AMD SoCs. Since this code will be factored out to the common AMD SoC code in a follow-up patch, the function prototype is added to southbridge.h instead of creating a new uart.h header file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id4aa6734e63dad204d22ce962b983cde6e3abd62 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68533 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-20soc/amd/stoneyridge/uart: add and use uart_info arrayFelix Held
Introduce and use an array of soc_uart_ctrlr_info to align Stoneyridge with the other AMD SoCs in order to allow commonization of the AMD SoC UART code. Since the current Stoneyridge code doesn't provide or use UART MMIO device operations, only the base addresses of the UART controllers from this array are used for now. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie868cd3e2f77b0f7253c9f6d91dd3bbc3e4b6b0e Reviewed-on: https://review.coreboot.org/c/coreboot/+/68531 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-18soc/amd: factor out writing extended PM registers in FADTFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I59985f283f1694beeacb0999340111146fa3f39b Reviewed-on: https://review.coreboot.org/c/coreboot/+/68494 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-18soc/amd/*/i2c: Move reset_i2c_peripherals to i2c.cFred Reitberger
Move i2c SoC related code from early_fch.c to i2c.c TEST=build boards for each SoC Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I69d4b32cf95ce74586bd8971c7ee4b56c1c2fc04 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68499 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2022-10-17soc/amd/*/smihandler: Make fch_apmc_smi_handler commonFred Reitberger
Rename soc/amd/common/block/cpu/smm/smi_ampc_helper.c to smi_apmc.c and add the fch_apmc_smi_handler function. Remove the duplicated function from picasso, cezanne, mendocino, and morgana SoC. The stoneyridge soc does not implement the APM_CNT_SMMINFO handler, so give the handler a unique name that does not conflict with the common handler name. Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I2e6fb59a1ee15b075ee3bbb5f95debe884b66789 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68441 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-15treewide: Use 'fadt->x_pm1a_evt_blk.addrl = fadt->pm1a_evt_blk'Felix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id3002dc976b82f71b1f60a6e32b16d60a7bbbead Reviewed-on: https://review.coreboot.org/c/coreboot/+/68427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-10-14soc/amd/sata.c: Hook up directly in devicetreeArthur Heymans
Cezanne has two SATA controllers, but doesn't select SOC_AMD_COMMON_BLOCK_SATA, so it's not added to the SATA devices in the Cezanne chipset devicetree. Change-Id: If7f0a9638151cf981d891464a2c3a0ec5fc9c780 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68142 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-10-14soc/amd/*: Hook up IOMMU ops in devicetreeArthur Heymans
This removed the need to maintain a PCI driver. Change-Id: I43def81d615749008fcc9de8734fa2aca752aa9d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68146 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-14soc/amd/*: Hook up LPC ops in devicetreeArthur Heymans
This removes the need for a PCI driver. Change-Id: I6674d13f434cfa27fa6514623ba305af6681f70d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68144 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-14soc/amd/*: Hook up SMBus ops to devicetreeArthur Heymans
This removes the need for a PCI driver. Change-Id: Iab75f8c28a247f1370f4425e19cc215678bfa3e5 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68140 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-10-14soc/amd/stoneyridge: move northbridge ops to northbridge deviceFelix Held
The northbridge ops should be added to the actual northbridge and not the first HT device. Neither of the devices has BARs on it, so read_resources implementation will still work correctly. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2e5f21bfe5fff043d7d9afafa360764203dd61f6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68409 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-14soc/amd/stoneyridge: use devicetree ops over pci driverFelix Held
Stoneyridge is a SoC so it makes sense to statically use ops instead of matching them to PCI DID/VID at runtime. In contrast to the other AMD SoCs in the coreboot tree the PC driver used the PCI ID of the first HT PCI device function, so add the ops to the device 0x18 function 0 devicetree entry in this patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I500521701479aa271ebd61e22a1494c8bfaf87fb Reviewed-on: https://review.coreboot.org/c/coreboot/+/68408 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-14soc/amd/stoneyridge: Hook up device_operations in chipset.cbFelix Held
This removes the need for a lot of boilerplate code in the soc code to hook up device_operations to devices. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id668587e1b747c28207b213b985204b7a961a631 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68410 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-13soc/amd/stoneyridge: add chipset devicetreesFelix Held
Add chipset devicetrees for Stoneyridge and Carrizo, which is also supported by the Stoneyridge code, but has more external PCIe ports and devices. The mainboard's devicetrees will be changed to use the aliases defined in the chipset devicetree in follow-up patches. This is a preparation to statically assign the ops for the internal devices statically in the SoC devicetree instead of dynamically adding them in ramstage. BKDG #55072 Rev 3.04 was used to check the PCI devices and functions and the MMIO addresses. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia45260b1168ed1d99993adfb98475da5b5c90d11 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68316 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-10-13payloads,src: Replace ALIGN(x, a) by ALIGN_UP(x, a) for clarityElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I80f3d2c90c58daa62651f6fd635c043b1ce38b84 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68255 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'fadt->x_pm1a_cnt_blk.addrl = fadt->pm1a_cnt_blk'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Ic48c5c165732c8397c06a2362191a94ae5805cf1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68276 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'fadt->x_pm_tmr_blk.addrl = fadt->pm_tmr_blk'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I7ddb4ea792b9a2153b7c77d2978d9e1c4544535d Reviewed-on: https://review.coreboot.org/c/coreboot/+/68275 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'gpe0_blk' for 'x_gpe0_blk.addrl'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I05d5097097b925a7bc8058f4c23e7c13a49f03c5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68273 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'gpe0_blk_len' for 'x_gpe0_blk.bit_width'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I581cacb6086d94fe65e6f4800454f447e1ada07b Reviewed-on: https://review.coreboot.org/c/coreboot/+/68272 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'fadt->pm_tmr_len' for 'x_pm_tmr_blk.bit_width'Elyes Haouas
Change-Id: Id4e2939b74ec93f50a4bedd0069090f0775b0556 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'fadt->pm1_cnt_len' for 'x_pm1a_cnt_blk.bit_width'Elyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I4e468e6bb58adc44bd66149eb79dc885dbf73c67 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68270 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-12treewide: Use 'fadt->pm1_evt_len' for 'x_pm1a_evt_blk.bit_width'Elyes Haouas
Change-Id: I1e51ccad32f1c5e692c76b331eedf4d3bb260d38 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68269 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-10-07soc/amd/{stoney,picasso}/Kconfig: Fix guarding of amdfwMatt DeVillier
apu/amdfw should be restricted to the RO region only when building with VBOOT + any RW region (RW_A or RW_A + RW_B); it is not tied to ChromeOS in any way. Fix guarding to match newer AMD platforms (eg, CZN/MDN). TEST=build google/zork without CHROMEOS, with VBOOT_SLOTS_RW_A Change-Id: I32d7fa7a4b3d41107cfdba96128a4a75f7066c6f Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68125 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-09-30soc/amd/stoneyridge/fch: use read[16,32]p to avoid typecastsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6372741284ad5f0453f0d4dfd8ebaddd7385f8ea Reviewed-on: https://review.coreboot.org/c/coreboot/+/67977 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2022-09-14cpu/amd/smm: Move MP & SMM init in a common placeArthur Heymans
Change-Id: I7c457ab69581f8c29f2d79c054ca3bc7e58a896e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64870 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-09-14soc/amd/common: Add common function to get cpu countArthur Heymans
This is the same for all supported AMD hardware. Change-Id: Ic6b954308dbb4c5a2050f1eb8f15acb41d0b81bd Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67617 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-09-01amd/*/Makefile.inc: Put common words into common Makefile.incZheng Bao
Definition of FIRMWARE_LOCATION, POUND_SIGN, DEP_FILES, amd_microcode_bins are moved to common Makefile.inc. Change-Id: I5a0ea27002e09d0b879bafad37a5d418ddb4e644 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/62658 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: Jon Murphy <jpmurphy@google.com>
2022-08-25soc/amd: rework SPI flash MMIO region handlingFelix Held
Only 16 MByte of the SPI flash can be mapped right below the 4 GB boundary. In case of a larger SPI flash size, still only the 16 MByte region starting at 0xff000000 can be configured as WRPROT and be reserved for the MMIO mapped SPI flash region. The next 16 MByte MMIO region starting at address 0xfe000000 contain for example the LAPIC MMIO region, the ACPIMMIO region and the UART/I2C controller MMIO regions which shouldn't be configured as WRPROT. Reserving this region for the MMIO mapped SPI flash would also result in an overlap with the MMIO resources mentioned above. In the case of a smaller SPI flash, reserving the full 16 MByte flash MMIO region makes sure that the resource allocator won't try to put anything else in the lower parts of the 16 MByte SPI mapping region. To avoid the issues described above, always reserve/cache the maximum amount of 16 MBytes of flash that can be mapped below 4 GB. TEST=On boards with 16 MByte SPI flash chips, the resulting image of a timeless build doesn't change with this patch. Verified this on Chausie (Mendocino), Majolica (Cezanne), Cereme (Picasso) and Google/Careena (Stoneyridge). On Mandolin (Picasso) with an 8 MByte flash, the resulting image of a timeless build is different, but neither the coreboot console output nor the Linux dmesg output shows any errors that might be related to this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie12bd48e48e267a84dc494f67e8e0c7a4a01a320 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66700 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-20soc/amd/stoneyridge: move early I2C init to early_fch.cFelix Held
Since the I2C controller is part of the FCH, move the early initialization from bootblock.c to early_fch.c which also matches what the newer AMD SoCs do. TEST=Successfully boots on google/liara and all I2C/cr50/TPM functions appear to work properly Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I22d3a8888eaa34ea612da719c408c0083769e806 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66866 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-20soc/amd/stoneyridge/early_fch: use common lpc_early_init functionFelix Held
The functionality of sb_enable_lpc is implemented in the common LPC support code as lpc_enable_controller. This gets called by the common lpc_early_init which also calls lpc_disable_decodes and lpc_set_spibase. The lpc_set_spibase call was already done in bootblock_fch_early_init, so the main change in code behavior is that now lpc_disable_decodes gets called during early FCH initialization. The lpc_enable_port80 and sb_lpc_decode calls after the lpc_early_init code will reenable some of the decodes. TEST=Successfully boots on google/liara, cbmem and dmesg logs look clean Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia58a6f609fa149a6c09ed99f08bdc4f05eb56f96 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66841 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-15soc/amd/*: move reset_i2c_peripherals call after early GPIO setupFelix Held
Since bootblock_soc_early_init gets called before bootblock_mainboard_early_init which does the early GPIO setup, external I2C level shifters that are controlled by GPIOs might not be enabled yet. Moving the reset_i2c_peripherals call to bootblock_soc_init makes sure that the early GPIO setup is already done when reset_i2c_peripherals is called. Haven't probed any SCL signal on the non-SoC side of the I2C level shifters yet, but the waveform on the SCL pin of I2C3 on the SoC of a barla/careena Chromebook doesn't have the longer than expected SCL pulses any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If02140aef56ed6db7ecee24811724b5b24e54a91 Reviewed-on: https://review.coreboot.org/c/coreboot/+/57291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2022-07-17soc/amd: Fix some white spaces issuesElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: Ibe20d48bdd8c776f9658620a13814f96e564dabc Reviewed-on: https://review.coreboot.org/c/coreboot/+/65907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-07-17soc/amd/*/include/soc/iomap.h: Fix some white spaces issuesElyes Haouas
Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I7b6e41fa3b7cd8c8f7327c690212ec4990e8baf5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/65895 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-07-14arch/x86: Mark prepare_and_run_postcar noreturnArthur Heymans
This moves the die() statement to a common place. Change-Id: I24c9f00bfee169b4ca57b469c089188ec62ddada Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65812 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Julius Werner <jwerner@chromium.org>
2022-06-22device/resource: Add _kb postfix for resource allocatorsKyösti Mälkki
There is a lot of going back-and-forth with the KiB arguments, start the work to migrate away from this. Change-Id: I329864d36137e9a99b5640f4f504c45a02060a40 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64658 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-06-21soc/amd/*: Move selection of DRIVERS_I2C_DESIGNWARE to common blockMatt DeVillier
All AMD SoCs which select SOC_AMD_COMMON_BLOCK_I2C also select DRIVERS_I2C_DESIGNWARE, so make the pairing explicit by moving the selection into SOC_AMD_COMMON_BLOCK_I2C. This will facilitating adding the Designware I2C bus ops handler in a subsequent commit. Change-Id: Ice30c8806766deb9a6ba617c3e633ab069af3b46 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2022-06-20soc/amd/stoneyridge: Align get_cpu_count to other targetsArthur Heymans
The CPUID function to get the number of cores on a package is common across multiple generations of AMD cpus. Change-Id: I28bff875ea2df7837e4495787cf8a4c2d522d43d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64869 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2022-06-20soc/amd/*: Make mtrr decision based on syscfgArthur Heymans
The syscfg has to option to automatically mark the range between 4G and TOM2, which contains DRAM, as WB. Making it generally not necessary to allocate MTRRs for memory above 4G if no PCI BARs are placed up there. Change-Id: Ifbacae28e272ab2f39f268ad034354a9c590d035 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64868 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-28 16:17:26 +0000