coreboot.git - my copy of coreboot

Age	Commit message (Collapse)	Author
2024-02-29	soc/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-07	soc/amd: drop unneeded data_fabric_set_mmio_np	Felix 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-02	soc/amd: commonize PCI root IOAPIC initialization	Felix 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-02	soc/amd/phoenix: add openSIL calls	Felix Held
	Add the calls to the openSIL stubs to do the silicon initialization, to get the APCI IO ports, and to get the memory map. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6f37bf211e130cb44927f8a0e7f9134d246dfc1c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80296 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-31	soc/amd/phoenix/chip: make FSP-S call conditional	Felix Held
	Only call amd_fsp_silicon_init if PLATFORM_USES_FSP2_0 is selected in Kconfig. I'm not 100% sure about the data_fabric_set_mmio_np call yet, but since it doesn't depend on PLATFORM_USES_FSP2_0 to compile, I'll look into that one later. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2666f1ac0f0354146ffe005b3ce99484defda7a8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80242 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-31	include/device/device.h: Remove CHIP_NAME() macro	Nicholas 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-27	soc/amd/*/acpi: use common soc_acpi_write_tables prototype	Felix 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-27	soc/amd: rename agesa_write_acpi_tables to soc_acpi_write_tables	Felix 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-20	soc/amd/*/chip: factor out FSP-S call	Felix 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>
2023-06-07	soc/amd/phoenix/chip: use common data fabric domain resource code	Felix Held
	Use the new common AMD code that gets the usable non-fixed MMIO windows from the data fabric MMIO decode registers and generate the PCI0 _CRS ACPI code based on those regions. For a more detailed description see the corresponding patch that changes the Picasso code to use this new code. In contrast to the Picasso code, this change will drop the unneeded _STA method inside the PCI0 scope which wasn't present in Picasso's ACPI code before it got replaced by the SSDT that gets generated by amd_pci_domain_fill_ssdt. BUG=b:283495475 TEST=Myst still boots and both the coreboot console and the kernel show the expected PCI MMIO ranges being used. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I425876c4ef470574e00e123d36101641240c98cf Reviewed-on: https://review.coreboot.org/c/coreboot/+/75559 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2023-01-17	soc/amd: introduce and use common amd_cpu_bus_ops struct	Felix 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-12	soc/amd: Change Morgana codename to Phoenix	Martin Roth
	Now that the next generation of APUs is officially announced, we can unmask morgana. The chip formerly known as Morgana is actually Phoenix. Surprise! This patch just changes the name across the entire codebase. Note that the fw.cfg file will stay pointing to the 3rdparty/amd_blobs/morgana/psp directory until the amd_blobs_repo is updated. Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: Ie9492a30ae9ff9cd7e15e0f2d239c32190ad4956 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71731 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>