summaryrefslogtreecommitdiff
path: root/src/soc/amd/picasso
AgeCommit message (Collapse)Author
2024-08-09soc/amd/*: pass PSP RPMC NVRAM base and size to amdfwtoolFelix Held
Pass the PSP NVRAM base and size to amdfwtool for all SoCs except Genoa and Stoneyridge which don't use/support this. If a mainboard has an section named 'PSP_RPMC_NVRAM' in its FMAP file, the start and length of it in the flash will be passed to amdfwtool which then adds the base and length to the corresponding type 0x54 PSP directory table entry. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id9f8a7eec68a5222be63e46173132f1c4a461b4f Reviewed-on: https://review.coreboot.org/c/coreboot/+/83815 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-08soc/amd/picasso/Makefile: move PSP_NVRAM_[BASE,SIZE]Felix Held
Move PSP_NVRAM_BASE and PSP_NVRAM_SIZE from the BIOS directory table items to the PSP Directory Table items, since the corresponding region will be referenced by the PSP directory table and not the BIOS directory table. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iff7568ea05c701ecd346cc7590cf93b091ff31a2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83813 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-05soc/amd: add PSP SMI handler stubFelix Held
The PSP can send SMIs to the x86 side to have the SMI handler service requests from the PSP. This commit adds an empty PSP SMI handler; the actual implementation is added in later patches to keep the patches relatively small. This patch is a slightly modified version of parts of CB:65523. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I65989ff529d728cd9d2cd60b384295417bef77ad Reviewed-on: https://review.coreboot.org/c/coreboot/+/83739 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-25soc/amd: add SoC-specific root_complex.c to SMMFelix Held
The PSP code introduced in a following patch needs both SoC-specific functions get_iohc_info and get_iohc_non_pci_mmio_regs to also be available in SMM, so add those compilation units to the corresponding target. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4e32084b45f07131c80b642bc73d865fc57688a8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83445 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-07-25soc/amd/*/root_complex: introduce and use domain_iohc_info structFelix Held
Instead of implementing the functions get_iohc_misc_smn_base and get_iohc_fabric_id in the SoC code, move those functions to the common AMD code, and implement get_iohc_info in the SoC code that returns a pointer to and the size of a SoC-specific array of domain_iohc_info structs that contains the info needed by the common code instead. This allows to iterate over the domain_iohc_info structs which will be used in a later patch to find the PSP MMIO base address in both ramstage and smm. TEST=Mandolin still boots and all non-PCI MIO resources are still reported to the resource allocator Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifce3d2b540d14ba3cba36f7cbf248fb7c63483fe Reviewed-on: https://review.coreboot.org/c/coreboot/+/83443 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-05-29tree: Remove unused <stddef.h>Elyes Haouas
Change-Id: I7d7ad562eeff7247b7377b6570d489faee0aeda0 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82669 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yidi Lin <yidilin@google.com>
2024-05-23device: drop unnecessary CHECK_REV_IN_OPROM_NAME optionFelix Held
The CHECK_REV_IN_OPROM_NAME Kconfig option was introduced to solve the problem of the PCI VID/DID combination of the Picasso iGPU not being sufficient information to know which VGA BIOS file to run, so a new function that additionally checks the PCI revision of that device was introduced. Later it turned out that there might be a case where even that isn't sufficient, so the soc_is_raven2() function is used in the remap function to always use the correct VBIOS file. Picasso is the only SoC that selected the CHECK_REV_IN_OPROM_NAME Kconfig option, so all other SoCs are unaffected by this change. Now that we use the VBIOS images with only the PCI VID and DID in the CBFS file name for Picasso, SeaBIOS will find the VBIOS with the same ID as the iGPU in CBFS and we don't need the workaround to add a third VBIOS image via VGA_BIOS_DGPU_* that has the name that SeaBIOS expects. This will result in SeaBIOS now running the VBIOS that has the same PCI VID/DID as the hardware which will be the wrong one in the RV2 silicon showing the PCO silicon PCI VID/DID, but that was also the case with the VGA_BIOS_DGPU_* workaround where the board's Kconfig just selected one of the two possible images during build time and hoped that it was the correct one for that actual hardware. The only board where this patch might cause a regression compared to the old behavior is the AMD Cereme reference board with Pollock APU, but I'm not even sure if any coreboot developer still has one of those boards, so I'm willing to accept that. To properly solve the problem with SeaBIOS using the correct VBIOS file in all cases, we'd need to generate that info during coreboot runtime and somehow pass it to SeaBIOS, but that's out of scope for this patch. TEST=On Mandolin with PCO silicon, the display output in both SeaBIOS and Ubuntu still works. Booting Windows 10 via the pre-built EDK2 payload that I'm using also resulted in the display output working. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia6de533c536044698d85404427719b8f534870fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/82598 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-15soc/amd/picasso: Mark eMMC as non-removable for Windows 10/11 installCoolStar
Mark eMMC as non-removable to allow Windows 10/11 to install now that edk2 can boot from it. Change-Id: If0e14106521f99cb97d1bf421f4d82d1234c2f15 Signed-off-by: CoolStar <coolstarorganization@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2024-03-30soc/amd: Remove blank lines before '}' and after '{'Elyes Haouas
Change-Id: I0203e77dd23fa026cd252abbda50f1e9f6892721 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-03-28cpu/x86/Kconfig: Mark 64bit support as stableArthur Heymans
With SMM holding page tables itself, we can consider SMM support stable and safe enough for general use. Also update the respective documentation. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-03-28soc/amd/noncar: Increase bootblock size from 64K to 128KArthur Heymans
When linking in page tables more place is needed. Size the bootblock is top aligned, this has no impact the final size for existing setups. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I23f176d63d3c303b13331a77ad5ac6c7a19073d3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80348 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-03-23soc/amd/*/memmap: factor out common read_lower_soc_memmap_resourcesFelix Held
Since the code for reporting the memory map below cbmem_top is basically identical for all non-CAR AMD SoCs, factor this out into a common read_lower_soc_memmap_resources implementation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id64462b97d144ccdf78ebb051d82a4aa37f8ee98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81389 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-29soc/amd: move common pci_domain_fill_ssdt implementation to acpi/Felix Held
Even though it has an 'amd_' prefix, the amd_pci_domain_fill_ssdt implementation doesn't contain any AMD-specific code and can also be used by other SoCs. So factor it out, move the implementation to src/acpi/acpigen_pci_root_resource_producer.c, and rename it to pci_domain_fill_ssdt. When a SoC now assigns pci_domain_fill_ssdt to its domain operation's acpi_fill_ssdt function pointer, the PCI domain resource producer information will be added to the SSDT. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7bd8568cf0b7051c74adbedfe0e416a0938ccb99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80464 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-12soc/amd/picasso: Use gpp_clk_setup_common functionVarshit Pandya
In follow up to CB:80285 use gpp_clk_setup_common for picasso as well. Change-Id: I68d498d08d5975037086c84ff2f7fdb265ee84d9 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80414 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-12soc/amd/picasso: Use pcie_gpp_dxio_update_clk_req_configVarshit Pandya
This function turns off gpp_clk for the devices which are disabled, and adds the code to fix up the clock configuration depending on dxio descriptors. Also this brings picasso in line with cezanne, mendocino and phoenix. This also prepares picasso to use the common function gpp_clk_setup_common. Change-Id: Ice2e3a5a78359da9a438434c7d4aa1eca878d396 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80413 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-07soc/amd: drop unneeded data_fabric_set_mmio_npFelix Held
Drop the unneeded data_fabric_set_mmio_np function and the corresponding SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems with only one FCH, its MMIO region will be subtractively decoded and there's no need to add a non-posted data fabric MMIO region after the FSP/openSIL has already configured the data fabric decode windows. In systems with more than one FCH, openSIL will already take care of initializing everything for the additional FCH, so we also won't need to do anything in that case. Since dropping this function also removes both data_fabric_print_mmio_conf calls before and after adding the unneeded non-posted MMIO region, replace the data_fabric_set_mmio_np call with a data_fabric_print_mmio_conf call to still print the data fabric MMIO decode regions set up by the FSP/openSIL. TEST=Mandolin still boots successfully Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-02soc/amd: commonize PCI root IOAPIC initializationFelix Held
Make the initialization of the IOAPIC(s) in the PCI root(s) common across all AMD family 17h+ SoCs. For this the more general implementation from the Genoa code that supports multiple PC roots is moved to the common AMD code. All other family 17h+ SoCs are then adapted to use the common code. For those non-Genoa SoCs, the initialization of this second IOAPIC is moved from the northbridge device to the domain device above to match Genoa. Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-01soc/amd: factor out memmap from root_complexFelix Held
Now that the SoC-specific memory map is reported on the domain device instead of the northbridge device, factor out the read_soc_memmap_resources function from root_complex.c to new memmap.c file. For now each SoC still has its own memmap.c file, but the plan is to eventually have a common implementation that works for all AMD family 17h+ SoCs. For that I'll still need to look closer into the differences between the FSP and the openSIL integration though. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifd7659e9a55de9df24118b6d6c885a21dc6f14a9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80272 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-01soc/amd/common/data_fabric/domain: introduce add_pci_cfg_resourcesFelix Held
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the legacy PCI config space access is needed on all AMD SoCs, implement a common add_pci_cfg_resources function that reports both and gets called from amd_pci_domain_read_resources and don't report those in the SoC- specific code any more. The only functional change is that on Genoa now the IO ports used for the legacy PCI config space access get reserved. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-01soc/amd: rework DRAM and fixed resource reportingFelix Held
Introduce read_soc_memmap_resources which gets called by amd_pci_domain_read_resources for the first domain of the SoC to report the DRAM and PCI config space access resources to the allocator. For Genoa this allows to use amd_pci_domain_read_resources as read_resources in the genoa_pci_domain_ops instead of needing to wrap that call to be able to call add_opensil_memmap for the first domain. For the other family 17h+ SoCs the moves the reporting of the DRAM resources and the PCI config space access resources from the northbridge device to the domain device. TEST=Resources still get reported on Mandolin, but now under the domain instead of the northbridge PCI device Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib19fd94e06fa3a1d95ade7fafe22db013045a942 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80268 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-01soc/amd/*/root_complex: use unsigned long for resource indexFelix Held
Use an unsigned long as resource index type instead of an int to match the data type used for the index in the resource struct. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0f58e32a535326116460545287cc59aaf94166a0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80267 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-01-31device/device.h: Rename busses for clarityArthur Heymans
This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-31include/device/device.h: Remove CHIP_NAME() macroNicholas Sudsgaard
Macros can be confusing on their own; hiding commas make things worse. This can sometimes be downright misleading. A "good" example would be the code in soc/intel/xeon_sp/spr/chip.c: CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev, This appears as CHIP_NAME() being some struct when in fact these are defining 2 separate members of the same struct. It was decided to remove this macro altogether, as it does not do anything special and incurs a maintenance burden. Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0 Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239 Reviewed-by: Yidi Lin <yidilin@google.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-27soc/amd: move acpi_add_fsp_tables implementation to common FSP codeFelix Held
Since the acpi_add_fsp_tables implementation is identical for all SoCs, factor it out and move it to the common AMD FSP code. Also guard the acpi_add_fsp_tables call in soc_acpi_write_tables with if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: factor out acpi_add_fsp_tablesFelix Held
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function and move the remaining parts of the soc_acpi_write_tables function to the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with Genoa and only leaves the FSP-specific code in agesa_acpi.c which will be made common in a following patch. I decided against also renaming agesa_acpi.c to acpi_fsp.c, since that would have made the diff less readable and the files get deleted in a following patch anyway. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-27soc/amd/picasso: factor out CRAT table generationFelix Held
Factor out the code to add the CRAT ACPI table into a separate file and add the acpi_add_crat_table function that can then be called from soc_acpi_write_tables to better isolate all code specific to the CRAT table. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4a7853748512811d3d4e124224fcd459e527522c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80223 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: use common ACPI_SCI_IRQ definitionFelix Held
ACPI_SCI_IRQ is defined as 9 for all AMD SoCs, so move the definition to the common amdblocks/acpi.h. Since all but Stoneyridge's soc/acpi.h are now empty, delete those files too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8210c98dc4cf2c6001d5273d132053278ff7fea5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80222 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd/*/acpi: use common soc_acpi_write_tables prototypeFelix Held
Since the definition is the same for all SoCs, move it to the common amdblock/acpi.h header. Since the Stoneyridge northbridge.c file also includes this prototype, remove the static attribute of the function there. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib9aa215f2b4ba58f43fed2c751d989f1719e0a17 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80221 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: use expected function signature for soc_acpi_write_tablesFelix Held
A pointer to soc_acpi_write_tables gets assigned to the write_acpi_tables element of the device_operations struct, so make sure that the function has the expected function signature which in this case means using unsigned long as type for both the 'current' parameter and the return value. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iee45badb904fa20c6db146edbc00c40ca09361d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80218 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: rename agesa_write_acpi_tables to soc_acpi_write_tablesFelix Held
It's not the AGESA code that generates most of the ACPI tables, so rename the function. This also aligns the other SoCs more with Genoa. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6b2e6c4cb7139c8bde01b4440ab2e923a1086827 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80217 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-26vc/amd: move verstage on PSP files to new psp_verstage folderFelix Held
Move the verstage on PSP files in vendorcode from the fsp subdirectory to a new psp_verstage subdirectory, since those files aren't specific to the case of the FSP being used for the silicon initialization. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic47f8b18bc515600add7838f4c7afcb4fff7c004 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80209 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-01-26soc/amd: factor out common acpi_add_ivrs_table implementationFelix Held
Instead of open-coding this functionality in all AMD SoCs, factor it out into a common implementation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idb65c398b747e70ec67107e0a1d4bd6551501347 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80208 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-01-24soc/amd/*: Rename Makefiles from .inc to .mkMartin Roth
The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ie449267fe4fdd75110f577e1b9f748cd06140950 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80071 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-01-20soc/amd/*/chip: factor out FSP-S callFelix Held
Move the call into the FSP code to a file in the common AMD FSP code to isolate the FSP-specific parts of the code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic8236db7ac80275a65020b7e7a9acce8314c831c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80084 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-20soc/amd: factor out non-CAR romstage to common codeFelix Held
Since the romstage code is very similar between all AMD non-CAR SoCs, factor out a common romstage implementation. All SoCs that select SOC_AMD_COMMON_BLOCK_PM_CHIPSET_STATE_SAVE call fill_chipset_state, so this Kconfig option can be used to determine whether to make that call. In the FSP case, amd_fsp_early_init gets called, while in the case of an implementation that doesn't rely on an FSP to do the initialization, cbmem_initialize_empty gets called to set up CBMEM which otherwise would be done inside the FSP driver code. Since only some SoCs call fch_disable_legacy_dma_io again in romstage right after amd_fsp_early_init, introduce the new SOC_AMD_COMMON_ROMSTAGE_LEGACY_DMA_FIXUP Kconfig option, so that the SoCs can specify if this call is needed or not. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4a0695714ba08b13a58b12a490da50cb7f5a1ca9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80083 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-01-20soc/amd/*/romstage: factor out FSP-M callFelix Held
Move the call into the FSP code to a file in the common AMD FSP code to isolate the FSP-specific parts of the code and a preparation to make the romstage of all non-CAR AMD SoCs common. Without isolating the call into the FSP-M code, building the common romstage would fail for genoa_poc due to fsp/api.h not being in the include path. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I30cf1bee2ec1a507dc8e61eaf44067663e2505ae Reviewed-on: https://review.coreboot.org/c/coreboot/+/80002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-17Reland "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi
This reverts commit acbc4912375085a099c2427def464d6e481f2a90. Reason for revert: CB:79525 fixes the issue that led to the revert by not maintaining the heap in the SMM-stored copy of ramstage at all. Change-Id: I3c8ef785486d275c9341859d34fce12253bd2bb9 Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80023 Reviewed-by: Sean Rhodes <sean@starlabs.systems> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> 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>
2024-01-11soc/amd/common/acpi: factor out common MADT codeFelix Held
The acpi_fill_madt implementation from the Genoa PoC also works for the other AMD SoCs that select SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN, so factor out this function to the common AMD ACPI code and change those other SoCs to use the new common functionality instead of having their own implementations. The old code on the single-domain SoCs used the GNB_IO_APIC_ADDR base address to create the MADT entry for the additional IOAPIC in the root complex. The new code iterates over all domains and looks for a resource with the IOMMU_IOAPIC_IDX index in each domain and if it finds it, it creates an MADT entry for that IOAPIC. This resource is created earlier in the boot process when the non-PCI resources are read from the IOHC registers and reported to the allocator. TEST=The resulting MADT doesn't change on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4cc0d3f30b4e6ba29542dcfde84ccac90820d258 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79861 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-05soc/amd/picasso/Kconfig: select SOC_AMD_COMMON_BLOCK_EMMC_SKIP_POWEROFFFelix Held
Commit 850b6c6254ab ("soc/amd/picasso: add eMMC MMIO device to devicetree") broke both S3 resume on Morphius SKUs that use an NVMe SSD instead of an eMMC and boot on the currently out-of-tree ASRock X370 Killer SLI board. In the latter case, commenting out the power_off_aoac_device call inside the emmc_enable function fixed things. TEST=This fixes S3 resume on Morphius with NVMe SSD and an equivalent change discussed in the patch mentioned above that caused the regression also fixed boot on the ASRock board. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Change-Id: Id976734c64efe7e0c3d8b073c8009849be291241 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79826 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-04soc/amd/picasso/acpi: move SoC-common code from dsdt.asl to soc.aslFelix Held
To avoid code duplication and to also bring the mainboards using the Picasso SoC more in line with Cezanne and newer, factor out the SoC- specific code from the mainboard's dsdt.asl files to the SoC's soc.asl. TEST=Timeless builds result in identical images for Bilby, Mandolin, and Zork/Morphius Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id4ed3a3d3cb55c8b3b474c66a7c1700e24fe908e Reviewed-on: https://review.coreboot.org/c/coreboot/+/79653 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-12-26soc/amd/picasso/fsp_s_params: use is_dev_enabledFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5b692aaa2e3f768cc03bca71eff3ceb1a8733ad3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79670 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-12-15soc/amd: drop fill_fadt_extended_pm_regsFelix Held
Call fill_fadt_extended_pm_io directly from the SoC's acpi_fill_fadt functions instead of calling fill_fadt_extended_pm_regs that only calls fill_fadt_extended_pm_io. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I442bc2801cf74c1d836d3b0d88f281bceb5122b8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79529 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-12-06soc/amd/*/chipset.cb: don't call dummy device functions host bridgesFelix Held
Function 0 of the devices that have the bridges to other buses are dummy functions that can be left enabled to not have to shuffle around the device function numbers when the first PCI bridge on those devices isn't enabled. Those dummy device functions are however not PCI host bridges, so change the comments from 'Dummy Host Bridge' to 'Dummy device function'. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Nico Huber <nico.h@gmx.de> Change-Id: Ibddfdf558d84bc44434d718b86f41bd06044b22a Reviewed-on: https://review.coreboot.org/c/coreboot/+/79396 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-11-07Revert "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi
This reverts commit 44a48ce7a46c36df69f7b2cf3552bf10fa5f61b6. Reason for revert: It breaks wakeup from suspend on a bunch of boards. While this approach of eyeballing "correct" values by chipset _should_ be fixed, it should also be accompanied by compile time verification that the memory map works out. Since nobody seems to care enough, let's just revert this, instead of keeping the tree broken for a bunch of configurations. Change-Id: I3cd73b6ce8b15f06d3480a03ab472dcd444d7ccc Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78850 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-11-06soc/amd/*/iomap: drop unused I2C_MASTER_START_INDEX definitionsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0eae9e4d246bd07f43b1d77e5ad7649c010d0efe Reviewed-on: https://review.coreboot.org/c/coreboot/+/78899 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-11-02soc/amd/*: Ensure PSP soft fuse bitmask set properlyMatt DeVillier
Commit e728766f4596 ("soc/amd/mendocino: Do not load MP2 Firmware when in RO") added logic to ensure that the MP2 disable soft fuse bit was set for the RO section, but failed to check if the bit was already set otherwise (as it is for non-ChromeOS builds). This caused the bit to appear twice in the PSP_RO_SOFTFUSE_BITS string, and when the string was converted to a series of numeric values and added together, bit (n+1) ended up being set instead of bit n. To mitigate this, use the makefile sort() function to ensure the PSP_[RO_]SOFTFUSE_BITS string does not contain any duplicates before the bitmask is calculated. Apply this to all AMD SoC makefiles where the softfuse bits are added. TEST=build/boot google/skyrim (frostflow). Use a verbose build (V=1) to verify that the correct soft fuse value is passed to amdfwtool for RO and RW_A/B for both ChromeOS and non-ChromeOS builds. Change-Id: I2e207e20132d44016fbcb986bdfd8e935d8fead5 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78823 Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-10-11Kconfig: Bring HEAP_SIZE to a common, large valuePatrick Georgi
We have a tiny HEAP_SIZE by default, except when we don't, and mainboards that override it, or not. Since memory isn't exactly at a premium these days, and unused heap doesn't cost anything extra, just crank it up to the highest value we have in the tree by default and remove all overrides. Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020 Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-21soc/amd/*/cpu: factor out common noncar mp_init_cpusFelix Held
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation, factor it out and move it to a common location. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-19soc/amd/picasso: add eMMC MMIO device to devicetreeFelix Held
Add the eMMC MMIO device to the devicetree and make it use the common AMD eMMC driver. Since there is now a device for this in the devicetree, also use this device to determine if the FSP should be told if the eMMC controller is supposed to be disabled. TEST=On Mandolin the eMMC controller both disappears in the Windows 10 device manager and in dmesg on Ubuntu 2022.04 LTS TEST=Morphius with NVMe SSD still works Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-18soc/amd: introduce SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGIONFelix Held
Add a separate Kconfig option for adding np_region.c to the build. Only the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call data_fabric_set_mmio_np which is implemented in that file, so only select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option for those. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-12soc/amd/*/Makefile: drop wrong EFS diagramsFelix Held
The EFS data structure diagrams in the Makefiles of Picasso and newer SoCs were wrong, since the BIOS directory table pointer is in a different location than shown in the diagram. Since the diagram also wasn't that easy to understand and amdfwtool does all of that handling, drop the wrong diagram from the Makefiles. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-09-06soc/amd: correctly report I2C controller state in ACPIFelix Held
Instead of reporting all I2C controllers in the system as enabled in the corresponding ACPI device's _STA method, report the I2C devices that are disabled in the devicetree as disabled in the corresponding _STA method too. This is done by returning the contents of the STAT variable inside each device's scope in the DSDT that have a default value of 0 (device not present/disabled). For all enabled and hidden I2C devices i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and visible) or 0xb (device enabled, but hidden) to the STAT name inside the same scope, but in the SSDT. This object in the SSDT will then override the default in the DSDT resulting in the _STA method returning the correct status of each device. The code was inspired by commit 7cf9c7451808 ("soc/amd/*: Fix UART ACPI device status"). TEST=On Mandolin all I2C controllers are disabled and with this patch none shows up in the Windows 10 device manager. When enabling an I2C controller in the devicetree for testing, it shows up again in the Windows device manager. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-09-01util/amdfwtool: Deal with psp position in flash offset directlyZheng Bao
It is based on work by Arthur Heymans, 69852. Get rid of the confusing "position index" and use the relative flash offset as the Kconfig setting instead. TEST=binary identical on amd/birman amd/majolica amd/gardenia amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon pcengines/apu2 google/skyrim google/guybrush google/zork google/kahlee google/myst (The test should be done with INCLUDE_CONFIG_FILE=n) Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-08-26soc/amd: Move psp_transfer.h out of each SOC into commonMartin Roth
The psp_transfer.h file was the same under all SoCs, and is really tied to the file common/vboot/transfer.c, not the SOC. This patch makes an include directory under vboot to put the header into and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes the header file available to all platforms, so that new chips that don't use the psp_verstage don't have to make a psp_transfer.h file just to satisfy the compiler. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-15soc/amd/*/root_complex: introduce get_iohc_fabric_idFelix Held
Implement get_iohc_fabric_id for each SoC that translates the coreboot domain number to the fabric ID of the corresponding PCI root. This allows the primary domain to have the number 0 even though the destination data fabric ID will be non-zero. Keeping the primary domain number 0 allows to use config_of_soc() which can be resolved at link time and not need to dynamically find the SoC device to get the config. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6538a777619eed974b449fc70d3fe3084ba447dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/77168 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-09treewide: Get rid of "NO_DDRx" selectionElyes Haouas
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-09soc/amd/picasso/include/data_fabric: add DF PCI config map registerFelix Held
PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide492f4479b85cd885044bbf74d8bf18c12e552b Reviewed-on: https://review.coreboot.org/c/coreboot/+/77075 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-09soc/amd/*: Fix UART ACPI device statusMatt DeVillier
Prior to commit d1c0f958d198 ("acpi: Call acpi_fill_ssdt() only for enabled devices"), uart_inject_ssdt() was used to set the ACPI status (_STA) for both enabled and disabled devices. The aforementioned commit limited it to being called only on enabled devices, which left disabled devices without any _STA method at all -- which the OS assumes means that the device is present and enabled. To fix this, create the _STA method in the UART asl code for each port, and set the return value to a name variable (STAT) which defaults to 0 (not present/disabled). Then, have uart_inject_ssdt() set STAT to present and enabled (0xF) for UARTs actually present on the board. TEST=build/boot google/skyrim (frostflow), dump ACPI tables, and verify that _STA returns 0xF only for UARTs enabled in devicetree. Change-Id: Id89e74c3ea7f53280935898ee35311b7cf3b152a Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77092 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-08soc/amd/picasso/include/data_fabric: add data fabric IO decode registersFelix Held
PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I61d4fca48d71010bbc4bd94a2fb8889bad08f1cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/76935 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-08soc/amd/*/include/data_fabric: add dst_ prefix to fabric_id fieldFelix Held
Rename the fabric_id struct field in the df_mmio_control union to dst_fabric_id to both better match the register definitions and also be a bit clearer about what this is doing. Also use tabs for indentation in the struct inside the df_mmio_control union. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0a17d82a5d7b66a8f84854f21fbbb319da81ac43 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76932 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-08-08soc/amd/*/include/data_fabric: reorder register definitionsFelix Held
Order the data fabric register definitions by function number and register offset. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia3066ad0f564520cb322a3e41a413eb3bf51260d Reviewed-on: https://review.coreboot.org/c/coreboot/+/76923 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-08soc/amd/*/include/data_fabric: rename D18F0_DRAM_* to DF_DRAM_*Felix Held
Now that the data fabric PCI device functions are included in the register definitions, the remaining data fabric device function numbers can be dropped from the define names. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1a26402b8078d288a7e32c1668591d001fa3ede9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76889 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-08soc/amd/*/include/data_fabric: rename D18F0_MMIO_* to DF_MMIO_*Felix Held
Now that the data fabric PCI device functions are included in the register definitions, the remaining data fabric device function numbers can be dropped from the define names. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia0355838ac1d513ba562fd6fb4672342dd383498 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76888 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-08soc/amd/common/include/data_fabric_defs: introduce & use DF_REG_* macrosFelix Held
To have both the PCI function number and the register offset into the config space of that function of the data fabric device in the data fabric register definitions, introduce and use the DF_REG_ID, DF_REG_FN and DF_REG_REG macros. The DF_REG_ID macro is used for register definitions where both the function number and the register offset are specified, and the DF_REG_FN and DF_REG_REG macros are used to extract the function number and the register offset from the register defines. This will allow having one define for accessing an indexed group of registers that are on different functions of the data fabric device. TEST=MMIO resources read from the data fabric's MMIO decode registers don't change on Mandolin and the ACPI CRAT table is also identical. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I63a284b26081c170a217b082b100c482f6158e7e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76886 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-05src/*/post_code.h: Change post code prefix to POSTCODEYuchen He
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. header="src/soc/amd/common/block/include/amdblocks/post_codes.h \ src/include/cpu/intel/post_codes.h \ src/soc/intel/common/block/include/intelblocks/post_codes.h" array=`grep -r "#define POST_" $header | \ tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2` for str in $array; do splitstr=`echo $str | cut -d '_' -f2-` grep -r $str src | cut -d ':' -f 1 | \ xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g" done Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad Signed-off-by: Yuchen He <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-27soc/amd/common/fsp: factor out read_fsp_resources from root_complex.cFelix Held
Factor out the common FSP-specific code to report the usable and reserved memory resources read from the HOBs that FSP has put into memory. This both reduces code duplication and also moves FSP-specific code out of the SoC code into the FSP-specific common AMD SoC code folder. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib373c52030209235559c9cd383f48ee1b3f8f79b Reviewed-on: https://review.coreboot.org/c/coreboot/+/76759 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-25soc/amd/*/root_complex: introduce and use SMN_IOHC_MISC_BASE_13B1Felix Held
On the mobile SoCs, SMN_IOHC_MISC_BASE_13B1 is the only IOHC misc base address, but on for example Genoa it's the address of the IOHC misc base of the second IOHC. Due to it not being the first one on Genoa, use 13B1 as part of the name instead of using an index of 0 which would look odd in the Genoa case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1db28ec03a3ba1c2040d8a1500ae17aa9705f6e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76756 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> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/*/root_complex: don't report root complex IOAPIC resource twiceFelix Held
Since the per PCI root IOAPIC is now reported as domain MMIO resource and the IVRS code now again probes for the IOAPIC resource on the domain device, the IOAPIC resource doesn't need to be reported as resource of the northbridge PCI device any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8604bd321ec4239076b1be99dca095e47f8b75a7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76600 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-07-25soc/amd/picasso/root_complex: add non-PCI MMIO registersFelix Held
Add the SoC-specific non-PCI MMIO register list. PPR #55570 Rev 3.18 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If7bfcdd9b70b71fe6aedcab3694698967d48e18e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76554 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-24soc/amd/*/Makefile.inc: Do not add APOB NV entry when disabledFred Reitberger
Do not add type 0x63 entry to amdfw.rom when APOB_NV cache is disabled. BUG=b:290763369 TEST=boot birman multiple times with/without APOB_NV cache enabled Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Iefe6f56d7dbedd289680f25a5f372eaa12e967b6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76568 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-21vendorcode/amd/fsp/common: Refactor dmi_info.hKonrad Adamczyk
SoC family is able to provide SoC-specific information via amd/fsp/<soc_family>/soc_dmi_info.h. Use common amd/fsp/common/dmi_info.h for all AMD platforms. This way, duplicated dmi_info.h files in vendorcode/amd/fsp/<soc_family>/ can be removed. BUG=b:288520486 TEST=Dump `dmidecode -t 17`. Change-Id: I5e0109af51b78360f7038b20a2975aceb721a7d5 Signed-off-by: Konrad Adamczyk <konrada@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76107 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-07-18soc/amd/*/root_complex.c: Use newer function for resource declarationsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: If2048c9cade731b2e4464d0670e0578f5f4bcea0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-07-17soc/amd/common/acpimmio: factor out IO port access to PM registersFelix Held
Factor out all functions that use the indirect IO port based access to the PM registers into a new compilation unit and only select it on platforms that support this interface. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9c059e450e2137f7e05441ab89c1f0e7077be9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/76458 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-07soc/amd/*/globalnvs,nvs: remove deprecated & unused CBMC field from GNVSFelix Held
Commit cde4f3b2790d ("acpi/gnvs.c: Drop unused pointer to the cbmem console") removed writing the coreboot memory console pointer to the GNVS and kept the CBMC field as reserved. Since those fields aren't needed any more and there are no dependencies on the absolute position of the different fields in GNVS as long as both GNVS definitions on the C and the ASL side match, remove the deprecated and unused CBMC field from the GNVS structs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iadfaf5a4ec1401b027dbfb6a7c6ce74a1dcecdfa Reviewed-on: https://review.coreboot.org/c/coreboot/+/76351 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-07-07soc/amd/*/Makefile.inc: Use _tohex instead of printfFred Reitberger
Use the _tohex function to convert values to hex instead of 'shell printf' TEST=timeless builds identical for grunt,dalboz,guybrush,chausie,birman Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ic7f7d1b764479088cc0980b208d8d603bc712832 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76314 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-06acpi/gnvs.c: Drop unused pointer to the cbmem consoleArthur Heymans
Change-Id: I7e2018dbccead15fcd84e34df8207120d3a0c57c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64303 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
2023-07-03soc/amd/*: Utilize get_fmap_value() Makefile function where possibleMatt DeVillier
Replace: $(shell awk '$$2 == "xyz" {print $$3}' $(obj)/fmap_config.h) with: $(call get_fmap_value,xyz) to improve code readability/maintainability. Change-Id: If6859108c7d5611a63fc38909dc75195bfb1d59a Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76168 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-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-19soc/amd/*: Use proper resource function to declare GNB IOAPICsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I296697d579b9ad8e35b22ada939a74a5ef6d6f61 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75828 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-15soc/amd/*/root_complex: reserve IOMMU MMIO areaFelix Held
This makes sure that the resource allocator won't use this address range for anything else. In the systems I looked at, this was between the end of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO region, but better reserve it here so nothing else will get allocated there if this expectation isn't met. TEST=Reserved region is printed in the console logs: update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-14soc/amd/acpi/ivrs: Use specific IOMMU resource index on all SOCArthur Heymans
By adding all DXIO IOAPIC with the same resource index, the IVRS code can always pick that resource which simplifies the code. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I10345e2337dcb709c2c1a8e57a1b7dd9c04adb9e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75710 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
2023-06-09soc/amd: add ops xhci_pci_ops to XHCI controllers in devicetreeFelix Held
Instead of adding the new PCI IDs of the XHCI controllers in every new chip generation to the pci_xhci driver, bind the driver to the internal PCI devices of the XHCI controllers via the device ops statement in the chipset devicetree. The PCI device function of the XHCI2 controller in Mendocino can be either a dummy device or the XHCI controller, so the device ops are attached to that device in the mainboard devicetree instead. The Glinda code is right now just a copy of the Mendocino code, so it'll change in the future, but for consistency the equivalent changes to those in Mendocino are applied there too. Since the device ops are now attached to the devices via the static devicetree entry, also remove both the xhci_pci_driver struct and the amd_pci_device_ids array from drivers/usb/pci_xhci/pci_xhci.c. TEST=SSDT entries for the XHCI controllers are still generated on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9c455002c6d2aac576fe24eee0c31744b4507bb0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75713 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-06-08soc/amd/picasso/acpi/northbridge: drop _STA method from PCI0 scopeFelix Held
The PCI root complex itself isn't on an enumerable bus, so without providing an _STA method, the device will still be assumed to be present and visible, so this won't change behavior. This also brings Picasso more in line with Cezanne and newer SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Nico Huber <nico.h@gmx.de> Change-Id: Ied48b48113f6e871e90d17cbd216be003f05b5ef Reviewed-on: https://review.coreboot.org/c/coreboot/+/74993 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-07soc/amd/*/root_complex: use VGA_MMIO_* definesFelix Held
Replace the magic constants by using defines. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I16179a37b6ee19bc3b4862b7dcb3bbc4caf63f2e Reviewed-on: https://review.coreboot.org/c/coreboot/+/75668 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-06-07soc/amd/picasso/acpi: rename sb_fch.asl to mmio.aslFelix Held
This file only contain the ACPI code describing the MMIO devices in the FCH, so rename it to mmio.asl. This also brings the Picasso ACPI code a bit more in line with the ACPI code of the newer SoCs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I64490ba8e34ae1fbe6aea1ab6496b5b04ac4d0aa Reviewed-on: https://review.coreboot.org/c/coreboot/+/75591 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/picasso/acpi: move remaining parts of sb_pic0_fch.asl to soc.aslFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I785abfc90c99b58c11d57847573f550fcea1f774 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75590 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-06-07soc/amd/picasso/acpi: use ROOT_BRIDGE macroFelix Held
Instead of having the different static parts of the PCI0 device in northbridge.asl and sb_pci0_fch.asl, instantiate the static parts of the PCI0 device via the ROOT_BRIDGE macro in soc.asl. TEST=Both Ubuntu 2022.4 and Windows 10 still boot successfully and don't show any new ACPI-related error. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2587d8bb270dc3edce9dfa570a5018116fc9187f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75569 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-06-07soc/amd/common/data_fabric/domain: write _BBN method in SSDTFelix Held
Instead of having PCI0's _BBN method in the DSDT that always returns 0, use acpigen_write_BBN to generate the _BBN method that returns the first PCI bus number in the PCI domain/host bridge. TEST=On mandolin the _BBN method in the _SB/PCI0 scope is now in the SSDT instead of the DSDT, but still returns 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8badeb0064b498d3f18217ea24bff73676913b02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74992 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-07soc/amd/picasso/chip: use common data fabric domain resource codeFelix Held
Use amd_pci_domain_read_resources function that gets the configured MMIO regions for the PCI root domain from the data fabric's MMIO decode registers instead of using pci_domain_read_resources. This results in the same IO port range being used by the allocator, but makes sure that the allocator will only allocate non-fixed MMIO resources in the address ranges that get decoded to the PCI root complex. In order for the PCI0 _CRS ACPI resource template to match the decoded PCI root domain MMIO windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code instead of having a mostly hard-coded _CRS method in the DSDT. This makes sure that the OS will know about the MMIO regions it is allowed to used. Before this patch, only the region from TOM1 to right below CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the PCI0 _CRS method. Also the resource allocator didn't get any constraint on which address ranges it can use to put the non-fixed MMIO resources. This approach worked until now, since all address range from 0 up to right below TOM1 was filled with either usable or reserved memory and the allocator was allocating beginning right from TOM1, since it was using the bottom-up allocation approach and everything below TOM1 was already in use. The MMIO region from TOM1 to right below CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window configured in the data fabric's MMIO decode registers, so everything seemed to work fine. However, when either selecting RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke badly. This was partially due to the allocator putting non-fixed MMIO resources in regions that weren't decoded to the PCI root, since AMD family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the wrong ranges the allocator used also weren't advertised in ACPI. TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends up with a non-working system when the MMIO ranges aren't reported correctly to the resource allocator due to the reasons descried above, Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2 payload and Windows 10 boots with EDK payload. There's however an EDK2 bug that results the MMCONFIG region not being advertised in the e820 table, which causes Linux to not use the MMCONFIG and fall back to the legacy PCI config access method. This only happens with EDK2 payload and everything works fine when using SeaBIOS as payload. That e820 issue is unaffected by this patch. At the end of the data_fabric_set_mmio_np call, this is the data fabric MMIO register configuration: === Data Fabric MMIO configuration registers === idx base limit control R W NP F-ID 0 fc000000 febfffff 93 x x 9 1 10000000000 ffffffffffff 93 x x 9 2 d0000000 f7ffffff 93 x x 9 3 fed00000 fedfffff 1093 x x x 9 4 0 ffff 90 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 The limit of the data fabric MMIO decode register 1 is configured as 0xffffffffffff although this is way beyond the addressable memory space. add_data_fabric_mmio_regions fixes this up, so the range that gets passed to the allocator in that case is 0x7fcffffffff which takes both the reserved most significant address bits used for the memory encryption and the 12GB reserved data fabric MMIO at the top of the usable address space into account. This results in the following domain ranges passed to the resource allocator: DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff The IO resource producer region is split into two parts to not cover the PCI config IO region resource consumer. This results in these resources being added to the PCI0 _CRS resource template: amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0' PCI0 _CRS: adding busses [0-3f] PCI0 _CRS: adding IO range [0-cf7] PCI0 _CRS: adding IO range [d00-ffff] PCI0 _CRS: adding MMIO range [fc000000-febfffff] PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff] PCI0 _CRS: adding MMIO range [d0000000-f7ffffff] PCI0 _CRS: adding VGA resource Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg: PCI host bridge to bus 0000:00 pci_bus 0000:00: root bus resource [bus 00-3f] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window] pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window] pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window] Another noteworthy thing I wasn't aware of at first when testing ACPI changes on Windows 10 is that a normal Windows shutdown and boot cycle won't result in it processing the changed ACPI tables; you have to tell it to reboot to do a proper full boot where it will process the updated ACPI tables (and fail if it dislikes something about the ACPI tables and bytecode). Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-06-06soc/amd/*/root_complex: reserve PCI config IO portsFelix Held
This makes sure that the resource allocator won't use those ports for anything else. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie42260902ee2b383dd5867ac813cae029f706f2d Reviewed-on: https://review.coreboot.org/c/coreboot/+/75556 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-06-02soc/amd/common/block/cpu: Refactor ucode allocationGrzegorz Bernacki
Move microcode load/unload to pre_mp_init and post_mp_init callbacks. It allows to make sure that ucode is freed only if all APs updated microcode. BUG=b:278264488 TEST=Build and run with additional debug prints added to confirm that data are correctly unmapped Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-05-31soc/amd/picasso/acpi/sb_pci0_fch: replace Memory32Fixed with DWordMemoryFelix Held
This brings the ACPI code more in line with both what the new code for the AMD SoCs will do and also what the current Intel code does. This was mainly done to have a reduced delta to the new AMD domain resource handling functions to debug it, but it might still be useful to upstream this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-05-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide MISC deviceFelix Held
Don't set bit 2 of the return value of the _STA method in order for Windows not to show a warning about an unknown device in the device manager for this device. TEST=The unknown device with device instance path ACPI\AMD0040\3 disappeared from the device manager in Windows 10 build 19045 on a Mandolin board with a Picasso APU. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If005f06843956004c281fd70cf364171148cb9ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-13soc/amd/*/acpi/mmio.asl,sb_fch.asl: change AAHB's _STA back to methodFelix Held
Commit 396fb3db74db ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB device") didn't only change the visibility of the device, but also changed the _STA method to a name. While this worked, the specification says that _STA is supposed to be a method, so change it back to being a method. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-08soc/amd/*/acpi/northbridge,pci0: don't hide PCI0 root device from OSFelix Held
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates that the device should be shown in the user interface. This ports commit c259d7192806 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS") forward from Stoneyridge to the newer AMD SoCs. TEST=On Mandolin the PCI Express Root Complex now shows up in the device manager on Windows 10 and when switching the view to 'devices by connection', all PCI(e) devices are shown below it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-29sb,soc/amd,intel: Drop include <cpu/x86/smm.h>Kyösti Mälkki
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT entries for SMI architectural"). Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-29ACPI: Make FADT entries for RTC/CMOS architecturalKyösti Mälkki
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY that points to same offset. Since the century field inside RTC falls within the NVRAM space, and could interfere with OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY. There were no reference for the use of offset 0x48 for century. Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-27ACPI: Make FADT entries for SMI architecturalKyösti Mälkki
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-27soc/amd: Drop acpi_fill_madt_irqoverride()Kyösti Mälkki
It is unused. The use of field irq is problematic as it should appear relative to IOAPIC GSI bases in the devicetree. Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-26soc/amd: Use ACPI_COMMON_MADT_IOAPICKyösti Mälkki
Change IRQ #0 to GSI #2 override to positive edge trigger from the bus ISA default (positive edge). Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 10:04:56 +0000