summaryrefslogtreecommitdiff
path: root/src/soc/amd/common/block
AgeCommit message (Collapse)Author
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-10soc/amd: use apm_get_apmc() in APMC SMI handlerFelix Held
Instead of open-coding this functionality, call the apm_get_apmc() helper function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iac6b614d900e51d91a0c155116a5edc29775ea99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79836 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-08arch/x86: introduce HAVE_CONFIGURABLE_APMC_SMI_PORTFelix Held
Introduce the HAVE_CONFIGURABLE_APMC_SMI_PORT Kconfig option that when not selected will result in a default implementation of pm_acpi_smi_cmd_port to be included in the build that returns APM_CNT. SoCs that provide their own pm_acpi_smi_cmd_port implementation, need to select this Kconfig option. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iaceb61b0f2a630d7afe2e0780b6a2a9806ea62f9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79566 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-01-05soc/amd/common/emmc: add Kconfig option to skip powering off eMMCFelix Held
Add a Kconfig option to skip powering off the eMMC controller via the AOAC block in the case where the eMMC controller is disabled in the devicetree. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0dbe819222972d9bf0789671b031ad83648e8917 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79825 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> 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-11soc/amd/common/data_fabric: pass PCI segment group to domain codeFelix Held
Return the PCI segment group number from data_fabric_get_pci_bus_numbers via pointer argument so that amd_pci_domain_scan_bus can handle the PCI segment group numbers once coreboot supports more than one PCI segment group. For now, just print an error and return if the buses are on a PCI segment group other than 0. TEST=Mandolin still boots Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia53cda0ba656201c2197d05bc0d4a8fbbe8ad5d9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79412 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-12-06soc/amd/common: Move PCIe CLKREQ programming under fspMatt DeVillier
CLKREQ programming as currently implemented is completely dependent on FSP DXIO descriptors, so move under common/fsp/pci and rename the Kconfig to reflect the move. TEST=build google/{guybrush, skyrim, myst} Change-Id: I87b53d092ddc367b134c25949f9da7670a6a1d88 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79016 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-12-02soc/amd: Add DBG2 ACPI tableZheng Bao
Dump the DBG2 table on Linux console. $> acpidump -s ACPI: DBG2 0x0000000000000000 000054 (v00 COREv4 COREBOOT 00000000 **) $> acpidump > acpidump.bin $> acpixtract -a acpidump.bin $> iasl -d dbg2.dat $> cat dbg2.dsl /* * ACPI Data Table [DBG2] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "DBG2" [Debug Port table type 2] [004h 0004 4] Table Length : 00000054 [008h 0008 1] Revision : 00 [009h 0009 1] Checksum : FA [00Ah 0010 6] Oem ID : "COREv4" [010h 0016 8] Oem Table ID : "COREBOOT" [018h 0024 4] Oem Revision : 00000000 [01Ch 0028 4] Asl Compiler ID : "CORE" [020h 0032 4] Asl Compiler Revision : 20220331 [024h 0036 4] Info Offset : 0000002C [028h 0040 4] Info Count : 00000001 [02Ch 0044 1] Revision : 00 [02Dh 0045 2] Length : 0028 [02Fh 0047 1] Register Count : 01 [030h 0048 2] Namepath Length : 0002 [032h 0050 2] Namepath Offset : 0026 [034h 0052 2] OEM Data Length : 0000 [Optional field not present] [036h 0054 2] OEM Data Offset : 0000 [Optional field not present] [038h 0056 2] Port Type : 8000 [03Ah 0058 2] Port Subtype : 0012 [03Ch 0060 2] Reserved : 0000 [03Eh 0062 2] Base Address Offset : 0016 [040h 0064 2] Address Size Offset : 0022 [042h 006612] Base Address Register : [Generic Address Structure] [042h 0066 1] Space ID : 00 [SystemMemory] [043h 0067 1] Bit Width : 00 [044h 0068 1] Bit Offset : 00 [045h 0069 1] Encoded Access Width : 03 [DWord Access:32] [046h 0070 8] Address : 00000000FEDC9000 [04Eh 0078 4] Address Size : 00000100 [052h 0082 2] Namepath : "." Raw Table Data: Length 84 (0x54) 00: 44 42 47 32 54 00 00 00 00 FA 43 4F 52 45 76 34 // DBG2T.....COREv4 10: 43 4F 52 45 42 4F 4F 54 00 00 00 00 43 4F 52 45 // COREBOOT....CORE 20: 31 03 22 20 2C 00 00 00 01 00 00 00 00 28 00 01 // 1." ,........(.. 30: 02 00 26 00 00 00 00 00 00 80 12 00 00 00 16 00 // ..&............. 40: 22 00 00 00 00 03 00 90 DC FE 00 00 00 00 00 01 // "............... 50: 00 00 2E 00 // .... BUG=b:303689867 Change-Id: I3c97a78d1889549421baf0bc1a2e8f959a0f47e2 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79174 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-10device/Kconfig: rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORTFelix Held
Rename AZALIA_PLUGIN_SUPPORT to AZALIA_HDA_CODEC_SUPPORT and add a help text to this Kconfig option to clarify what this option is about. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I71e36869c6ebf77f43ca78f5e451aebfb59f1c74 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-11-09soc/amd: Remove unnecessary choice symbol name from PSP KconfigMartin Roth
There's no reason to name this choice block. Remove the name. Change-Id: Iebf8b1e7af928b988ab514d9dd85d2e70bf00c09 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78917 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-07soc/amd/common,stoneyridge: drop invalid hda_soc_ssdt_quirksFelix Held
Drop the hda_soc_ssdt_quirks function since it doesn't apply for any of the SoCs supported by the Stoneyridge code which was the only SoC implementing it. This code was added when commit 91a7abf25c72 ("soc/amd/hda: Move HDA PCI device from DSDT to SSDT") rewrote the code originally added in commit 1587dc8a2b4d ("soc/amd/stoneyridge: Add northbridge support") as a copy from northbridge/amd/pi/00670F00. This code was moved around in commit 6580408a7e0a ("amd/pi/hudson: Move audio to northbridge"), since the HDA controller was moved from the FCH to the northbridge complex. When the controller was moved, the PCI config space interface also changed, so those bits are no longer the DisableNoSnoop, DisableNoSnoopOverride, and EnableNoSnoopRequest bits of the Misc Control register of the HDA controller, but some bits within the ClassCodeW field of the ACGAZ Mirrot Reg Ctrl 0 register. BKDG #55072 Rev 3.04 (Stoneyridge), BKDG #50742 Rev 3.08 (family 15h model 60h-6fh / 00670F00), and BKDG #52740 Rev 3.05 (family 16h model 30h-3fh) were used as a reference. Only the SoC with BKDG #52740 still has the HDA controller in the FCH; the other two have it in the northbridge. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77fc76752b1c7de62ba8a196f15c198f55be3074 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78940 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-06soc/amd/common/block/i2c: add pre-processor guards for ACPIFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8dc93b12b81abee41f6f225f41d1f9953d1d93e1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78898 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2023-11-02soc/amd/common/psp: Remove unnecessary prompts from KconfigMartin Roth
I think this was probably a cut & paste error. We don't want prompts for the "default" Kconfig options. Those should be set by the platform, not the end user. These prompts didn't make sense where they were in the Kconfig menus either. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Idcd2ba84591d31a9a25bcc6cae3ec163939d7836 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78818 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <ericllai@google.com>
2023-10-25soc/amd/common/smm: Add option for late SMM lockingMatt DeVillier
Pre-Zen SoCs like Stoneyridge call into an AGESA binary as part of S3 resume, which will fail if SMM is locked, causing the device to (eventually) cold boot. To mitigate this, add a new Kconfig to enable "late" SMM locking, which restores the previous behavior prior to commit 43ed5d253422 ("cpu/amd: Move locking SMM as part of SMM init"). TEST=tested with rest of patch train Change-Id: I9971814415271a6a107c327523a0a7c188a91df6 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78352 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-25soc/amd/*/Kconfig: rework SPL optionsFelix Held
Move all security patch level (SPL) related Kconfig options to the common AMD PSP Kconfig file. Commit 4ab1db82bb30 ("soc/amd: rework SPL file override and SPL fusing handling") already reworked the SPL handling, but missed that another Kconfig option SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL controlled if the PSP mailbox command to update the SPL fuses was sent by the code that got added to the build when PERFORM_SPL_FUSING was selected. To make things less unexpected, rename PERFORM_SPL_FUSING to SOC_AMD_COMMON_BLOCK_PSP_SPL since it actually controls if the SPL support code is added to the build and also rename SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL to PERFORM_SPL_FUSING. This changes what PERFORM_SPL_FUSING will do from including the code that could do the fusing if another option is set to being the option that controls if the fusing mailbox command will be set. All SoCs that support SPL now select SOC_AMD_COMMON_BLOCK_PSP_SPL in their Kconfig, which won't burn any SPL fuses. The logic in the Skyrim mainboard Kconfig file is reworked to select PERFORM_SPL_FUSING for all boards on which the SPL fuses should be updated; on Guybrush PERFORM_SPL_FUSING default is changed to y for all variants. The option to include the code that checks the SPL fusing conditions and allows sending the command to update the SPL fuses if the corresponding Kconfig is set doesn't need to be added on the mainboard level, since it's already selected at the SoC level. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I12fd8775db66f16fe632674cd67c6af483e8d4e2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78309 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-10-25soc/amd/common: Add ACP device to common block graphics driverCoolStar
Supports a brand new ACP driver for STONEY / Grunt chromebooks. AMD's Audio CoProcessor handles i2s/tdm audio, and is located on the GPU. On Windows the PCIe device for the GPU is owned by the AMD proprietary driver, hence a separate device has to be added for the ACP driver. Fortunately since IOMMU is disabled on STONEY, the driver itself can pull BAR5 from the GPU and use that to initialize, so no special configuration is required in ACPI other than the ID. Change-Id: I0e31c3b31fa9fb99578c04b79fce2d8c1d695561 Signed-off-by: CoolStar <coolstarorganization@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78430 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-24soc/amd/common/graphics: Factor out FSP graphics initMatt DeVillier
Factor out the FSP-dependent graphics init call and header into a separate file, so that the common graphics init can be used by non-FSP platforms (eg Stoneyridge) without any preprocessor guards. TEST=build google/skyrim Change-Id: Ib025ad3adec0945b4454892d78c30b4cc79e57a0 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78599 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-20device/device.h: Rename pci_domain_scan_busArthur Heymans
On all targets the domain works as a host bridge. Xeon-sp code intends to feature multiple host bridges below a domain, hence rename the function to pci_host_bridge_scan_bus. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326 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> Reviewed-by: Yidi Lin <yidilin@google.com>
2023-10-16soc/amd/common/data_fabric_helper: add pre-processor guards for ACPIFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iec6e05bbe9fad7d78002560b78169dc293294af6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78341 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-10-16soc/amd/common/data_fabric/extended_mmio: fix compile errorsFelix Held
This code only gets built when the SOC selects SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO which no SoC before Genoa does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia5495ebf0f157fd0c456ce44acaf1ab222a188dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/78340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-10-04soc/amd: rework SPL file override and SPL fusing handlingFelix Held
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a way to override the default SPL file configured in the SoC's fw.cfg file by passing the '--spl-table' parameter to amdfwtool which will then use the override instead of the SPL file from the fw.cfg file. When SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix call in the makefile will result in no '--spl-table' parameter being passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In order to not pass an SPL override by default, remove the default from the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the same SPL file as in fw.cfg file anyway. Now only when a mainboard sets this option to point to a file, that file will be used as an override. This override is used to include a special SPL file needed for the verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an empty string by default, neither the SPL_TABLE_FILE Kconfig option nor it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE, so remove the dependency in the Kconfig and the ifeq in the Makefile. Before this patch, the HAVE_SPL_FILE option controlled two things that shouldn't be controlled by the same Kconfig option: Only when HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into account, and it also controls if spl_fuse.c got added to the build which when added will send the SPL fusing command to the PSP. So the case of needing an SPL file override, but not updating the SPL fuses wasn't supported before. The SPL file in the amdfw part will be used by the PSP bootloader for the anti-rollback feature which makes sure that the SPL file version isn't lower than what is in the SPL fuses. For this the SPL file needs to be present in the PSP directory table. The SPL version check happens way before we're running code on the x86 cores. The SPL fusing PSP command that can be sent by coreboot will tell the PSP to update the SPL fuses so that the fused minimal SPL version will be updated to the current SPL version. Since the former HAVE_SPL_FILE option now only controls if the SPL fusing command will be sent to the PSP mailbox, rename it to PERFORM_SPL_FUSING to clarify what this will do and update the help text correctly describe what this does. TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman with Phoenix APU and Skyrim result in identical binaries. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-02soc/amd/common/noncar/cpu: simplify get_reserved_phys_addr_bitsFelix Held
Simplify the code a bit by returning 0 early in the function when the SYSCFG_MSR_SMEE bit isn't set. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Jeremy Compostella <jeremy.compostella@intel.com> Change-Id: I7536b82d98e55c51105448090d1206e1ed7f62d8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78176 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-02soc/amd/common: use common physical address bit reservation codeFelix Held
Instead of having the get_usable_physical_address_bits function that only got used in the data fabric domain resource reporting code, drop this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the common AMD non-CAR CPU and rename get_sme_reserved_address_bits to get_reserved_phys_addr_bits so that the common cpu_phys_address_size function will return the correct number of usable physical address bits which now can be used everywhere. The common AMD CAR CPU support is only selected by Stoneyridge which doesn't support secure memory encryption, so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the SOC_AMD_COMMON_BLOCK_CAR Kconfig option. Before only the MMIO region reporting took the reserved physical address bits into account, but now also the MTRR calculation will take those reserved bits into account. See the AMD64 Programmers Manual volume 2 (document number 24593) for details. Chapter 7.10.5 from revision 3.41 of this document was used as a reference. The MTRR handling code in older Linux kernels complains when the upper reserved bits in the MTRR mask weren't set, but sets them after complaining and then continues to boot. This issue is no longer present in version 6.5 of the Linux kernel. The calculation of the TSEG mask however still needs to take all physical bits into account, including the ones reserved for the memory encryption. When not setting the reserved bits in the TSEG mask, the Mandolin board with a Picasso APU won't boot to the OS any more due to not returning from SeaBIOS calling into the VBIOS. Haven't root-caused what exactly causes this breakage, but I think previously when something else was wrong with the SMM initialization, also something went wrong when calling into the VBIOS. TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2 and Windows 10 boots on it via EDK2. TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following warning, but it still continues the boot process as described above: mtrr: your BIOS has configured an incorrect mask, fixing it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-25soc/amd/common/graphics: Update VBIOS cache data before hashingMatt DeVillier
On the first boot after flashing, the data read from the FMAP and stored in vbios_data is not valid, so hashing it produces a value which will not match on the subsequent boot, requiring an additional boot before the vbios_data and hash match / before the GOP driver can be skipped. To fix this, update vbios_data before hashing. BUG=b:271850970 BRANCH=skyrim TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected, verify that GOP driver execution is skipping on 2nd boot after flashing when booting in normal / verified boot mode. Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727 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-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/cezanne,common: expose eMMC device in ACPI when enabledFelix Held
When the eMMC MMIO device is enabled in the devicetree, it needs to be exposed in ACPI in order for the OS driver to be able to attach to it. The Cezanne eMMC controller isn't used in google/guybrush, so this the code path where the eMMC MMIO device is enabled in the devicetree can't be easily tested. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989 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-18soc/amd/common/data_fabric_helper: factor out data_fabric_set_mmio_npFelix Held
Factor out data_fabric_set_mmio_np and the helper functions it uses into a separate compilation unit. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I58625c5a038f668f8e30ae29f03402e1e2c4bee3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77986 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-09-18soc/amd/common/data_fabric_helper: use data_fabric_get_mmio_base_sizeFelix Held
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf instead of open coding the functionality. This will fix the printing of the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO case which wasn't handled properly before. TEST=Console output from this function doesn't change on Mandolin: === 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 0 ffff 90 9 4 fed00000 fed0ffff 93 x x 9 5 0 ffff 90 9 6 0 ffff 90 9 7 0 ffff 90 9 === 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 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If602922648deca0caef23a9999c82acdd128b182 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-18soc/amd/common/data_fabric_helper: make some helper functions staticFelix Held
data_fabric_disable_mmio_reg and data_fabric_find_unused_mmio_reg are only used by data_fabric_set_mmio_np in the same file, so make them static and drop the prototype from the header file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6bf7a868aae2fd01b8adecd3e4cba6ff6d5119af Reviewed-on: https://review.coreboot.org/c/coreboot/+/77985 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-09-14x86: Add .data section support for pre-memory stagesJeremy Compostella
x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-09-09soc/amd/common: Remove __attribute__(())Elyes Haouas
Change-Id: I2866dcdd6900c98310b4b3736b40ebe4eaa77ea2 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77719 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-31soc/amd/common/data_fabric: add support for extended MMIO addressesFelix Held
The Genoa SoC supports MMIO addresses larger than 48 bits. Since the MMIO base and limit registers in the data fabric only contain bits 16 to 47 of the MMIO address, the MMIO address extension register is introduced on some SoCs like Genoa. This additional register contains the upper bits of the MMIO base and limit. Since it's not available on all SoCs, introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO Kconfig option to select the correct data_fabric_get_mmio_base_size implementation to be added to the build. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic304f5797bc5661c1d511c95e457c6dde169d329 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77514 Reviewed-by: Martin Roth <martin.roth@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> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-08-29soc/amd/common/data_fabric/Makefile: remove invalid commentFelix Held
The !CONFIG_SOC_AMD_COMMON_BLOCK_APOB_NV_DISABLE comment was likely a copy-paste leftover, so remove it. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I45b12d1dc5af84be99d54fea0c9ccf610cf5dae3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77513 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
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-25soc/amd/common/include/root_complex: add IOHC MISC SMN base addressesFelix Held
The Genoa server SoC has 4 IOHC PCI roots instead of the 1 the mobile SoCs have, so add the additional 3 SMN base address definitions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I72dba39bff7c7a739e1dfddd80e7f22e65b5f139 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77395 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-15soc/amd/common/lpc: use fixed_io_range_flags instead of open codingFelix Held
Instead of open coding the same functionality, use fixed_io_range_flags to tell the resource allocator about the FCH subtractively decoding the first 0x1000 bytes of I/O space. Also update the comment to match the code. TEST=On Mandolin the flags of this resource stay the same (0xc0040100). Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia30a87a4e37c98248568476b74af2730a3c0e88d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77170 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-15soc/amd/common/data_fabric/domain: use get_iohc_fabric_idFelix Held
Use get_iohc_fabric_id() to translate the coreboot domain's number into the destination data fabric ID of the PCI root. This allows using the coreboot domain 0 as primary domain of the SoC in all cases, so it's still possible to use config_of_soc(). This allows dropping the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN_MULTI_PCI_ROOT Kconfig option and do the check if the destination fabric ID in the PCI bus number, MMIO, and IO decode registers is the correct one for the domain without the need to use a non-zero number for the primary PCI root domain. TEST=Mandolin still boots and the PCI bus, IO and MMIO resources still get reported correctly. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I880ee0bf5c185cfe4af7de0d39581eb951ee603a Reviewed-on: https://review.coreboot.org/c/coreboot/+/77169 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.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-13soc/amd/common/data_fabric: handle multiple PCI root domainsFelix Held
In the case of SoCs hat have more than one PCI root, we need to check to which PCI root the PCI bus number, IO and MMIO regions configured in the data fabric registers get routed to and only tell the resource allocator about the resources that get routed to the current PCI root domain. For this the numbers of the domains need to match the PCI root's destination data fabric ID. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib6a6412f733d321044678d2b064c33418a53861c Reviewed-on: https://review.coreboot.org/c/coreboot/+/77113 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-12soc/amd/common/data_fabric: read PCI bus decoding from DF registersFelix Held
The data fabric also controls which PCI bus numbers get decoded to the PCI root. In order for the resource allocator to know how the hardware is configured, read the corresponding data fabric registers to get the information that then gets passed to the allocator. Picasso, Cezanne, Mendocino and Rembrandt only support one PCI segment with 256 buses while the Phoenix and Glinda data fabric hardware has support for more PCI segments. Due to this change, the register layout is different and incompatible between those two, so introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_MULTI_PCI_SEGMENT Kconfig option for a SoC to specify which implementation is needed. At the moment, coreboot doesn't have support for multiple PCI segments and the code doesn't support PCI segments other than segment 0. On Picasso the PCI bus number limit read back from the data fabric register is 255 even though CONFIG_ECAM_MMCONF_BUS_NUMBER is set to 64, so also make sure that the bus and limit returned by data_fabric_get_pci_bus_numbers is within the expected limits. TEST=PCI bus allocation still works on Mandolin (Picasso) and Birman (Phoenix). Picasso has 64 PCI buses. coreboot puts this info into the resource producer in _SB\PCI0\_CRS which the Linux kernel reads: * coreboot: PCI0 _CRS: adding busses [0-3f] * Linux: pci_bus 0000:00: root bus resource [bus 00-3f] This matches the information in the ACPI MCFG table. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ide5fa9b3e95cfd59232048910cc8feacb6dbdb94 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77080 Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-11soc/amd/common/data_fabric/domain: set and use max_subordinateFelix Held
Set the maximum subordinate bus number of the domain to the last PCI bus number that is decoded to this PCI root. This makes sure that the resource allocator knows the maximum number of PCI buses on this PCI root to not assign bus numbers to buses below this PCI root that aren't routed to that PCI root. Now that we have this info in the link list structure or the domain device, we can pass the max_subordinate field to the acpigen_resource_producer_bus_number call and can leave the subordinate number after pci_domain_scan_bus is done unchanged instead of setting it to the limit. TEST=On Mandolin both the bus resource producer in _SB\PCI0\_CRS and the PCI bus number allocation remain unchanged. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2ee75b2a7054a306b0c7d98c5357391c029187bb Reviewed-on: https://review.coreboot.org/c/coreboot/+/77112 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-11soc/amd: Add definition of SPI ROM remappingZheng Bao
Change-Id: Icafa36ae2e07068c276600067bba1d0377f0824b Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74258 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-09soc/amd/common/include/data_fabric: add missing device/device.h includeFelix Held
device/device.h provides struct device. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie03f6d15d94f2858e293b9f57505034263c03bbe Reviewed-on: https://review.coreboot.org/c/coreboot/+/77074 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-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-08cpu/amd/pi/00730F01: Use common code for mp_initArthur Heymans
TEST=APU2 still boots and doesn't show any new errors in dmesg. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia9f0eb3df8fd2dfe395f616da981cc3a0cd3b29d Reviewed-on: https://review.coreboot.org/c/coreboot/+/64891 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-08soc/amd/common/data_fabric/domain: read IO decode windows from registersFelix Held
Before add_io_regions only reported one fixed IO range to the resource allocator that covered the whole IO range from 0x0000 to 0xffff. Instead read the data fabric IO space decode base and limit address register pairs to get the actual IO port decoding from the data fabric registers. This will also help with adding support for multiple PCI root domains to the common data fabric domain code so that Genoa can use it. In that case each PCI root domain will only decode a part of the whole IO port range. Beware that the data fabric IO base and limit fields can contain values that correspond to IO port addresses far outside of the addressable IO port range. In case of Picasso, the IO limit read from the only enabled DF IO range register would be 0x1ffffff after converting the raw data to an IO port address. To not give the resource allocator wrong constraints make sure that the IO limit we report will be at maximum 0xffff. TEST=On Mandolin (Picasso) and Birman (Phoenix) the full range of IO port addresses still gets reported as a domain IO resource producer like before the patch: DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I087d96f7bdaae0d7b53089f6abaf0500a4b064e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76960 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-08soc/amd/common/data_fabric/domain: rename add_io_regionsFelix Held
Rename add_io_regions to add_data_fabric_io_regions to be consistent with add_data_fabric_mmio_regions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia990cc14dd6dc162ad614a6e9e0b36426cb04670 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76934 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>
2023-08-08soc/amd/common/data_fabric/domain: factor out report_data_fabric_ioFelix Held
As a preparation to read the IO decode ranges from the data fabric registers instead of having it hard-coded, factor out the report_data_fabric_io function to report one IO producer region from add_io_regions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I51c3f8cd6749623f1a4bad14873d53b8a52be737 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76933 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-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: 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/data_fabric_helper: use DF broadcast read/write functionsFelix Held
Instead of open coding the broadcast data fabric PCI register access in the functions for indirect non-broadcast data fabric register access, just use the existing data_fabric_broadcast_[read,write]32 functions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I174c1e6ee4856d97c5ec6d07bb8c217d6df9425f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76887 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> 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-08ACPI: Add helper fill_fadt_extended_pm_io()Kyösti Mälkki
Once platform code has filled in the (legacy) ACPI PM register map, added function will fill in the extended entries in FADT. TEST=samsung/lumpy and amd/mandolin FADT stays unchanged. Change-Id: I90925fce35458cf5480bfefc7cdddebd41b42058 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74913 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-06device, soc: Add SPDX license headers to MakefilesMartin Roth
To help identify the licenses of the various files contained in the coreboot source, we've added SPDX headers to the top of all of the .c and .h files. This extends that practice to Makefiles. Any file in the coreboot project without a specific license is bound to the license of the overall coreboot project, GPL Version 2. This patch adds the GPL V2 license identifier to the top of all makefiles in the device and soc directories that don't already have an SPDX license line at the top. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I89c05c7c1c39424de2e3547c10661c7e3f58b8f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76951 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Tim Crawford <tcrawford@system76.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-08-04soc/amd/common/data_fabric_helper: add comment about cfg_inst_acc_enFelix Held
Since all indirect data fabric register accesses will be non-broadcast accesses that target a specific data fabric instance, the cfg_inst_acc_en bit in the DF_FICAA_BIOS register will always be set since that makes the indirect access target only a specific data fabric instance. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9aff01750c2c1e3506141b3ed293a980a64f8fac Reviewed-on: https://review.coreboot.org/c/coreboot/+/76885 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-08-01soc/amd/common: Redefine EFS_OFFSETZheng Bao
The EFS_OFFSET is the relative address to flash base. We can not assume the flash size is 16M. The change will affect only Gardenia and Pademelon whose flash size are 8M. Change-Id: Ia68032db05264c55d333deec588ad9690a4ed2c1 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76764 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-31soc/amd/common/cpu: Add Kconfig to program the PSP_ADDR MSRMatt DeVillier
The PSP_ADDR_MSR is programmed into the BSP by FSP, but not always propagated to the other cores/APs. Add a hook to run a function which will read the MSR value from the BSP, and program it into the APs, guarded by a Kconfig. SoCs which wish to utilize this feature can select the Kconfig. BUG=b:293571109 BRANCH=skyrim TEST=tested with rest of patch train Change-Id: I14af1a092965254979df404d8d7d9a28a15b44b8 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76808 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-07-30soc/amd/common/data_fabric/domain: skip reserved resources for ACPIFelix Held
The non-PCI resources added to the domain device are resource consumers, so they mustn't be reported as resource producers. To make sure that this is the case, skip all resources that have the IORESOURCE_RESERVE flag set in amd_pci_domain_fill_ssdt. Commit 7a5dd781d147 ("soc/amd/common/data_fabric/domain: provide amd_pci_domain_fill_ssdt") that introduced amd_pci_domain_fill_ssdt already contained the bug, but since no MMIO range consumers were added back then, the bug only became visible when commit 32169720bb67 ("soc/amd/common/data_fabric/domain: report non-PCI MMIO resources") added the reserved non-PCI MMIO resources to the domain device's resources resulting in MMIO producer objects being generated for MMIO consumers. Those producers that should have been consumers then overlapped with the actual MMIO resource producers which caused Windows to BSOD with an ACPI_BIOS_ERROR. TEST=The non-PCI MMIO resources are no longer added as resource producers and Windows boots again on google/frostflow. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: Matt DeVillier <matt.devillier@gmail.com> Change-Id: Ib099675bc5bea93bf7c2a80f741bef067fd37a58 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76818 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-30soc/amd/common/data_fabric/domain: continue after unassigned resourceFelix Held
When iterating over the resource list in amd_pci_domain_fill_ssdt, don't return when a resource is unassigned, but just continue to the next loop iteration so the resulting SSDT will be complete and not broken due to a missing resource template footer and the scope not being closed. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I39fe516f27a6d971fb9c57a1e64ead79d23aff08 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76817 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-28soc/amd/commonn/block/include/psp_efs.h: Remove unused functionFred Reitberger
Commit 49d8aa7043ea ("soc/amd/common/block/psp: Unmap EFS region after use") removed the 'efs_is_valid' function but left the function signature in the header file. TEST=stoney/picasso/cezanne/mendocino/phoenix builds Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: Ib596946679b50be63868af57e3428b4d65845419 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76750 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-27soc/amd/noncar/memlayout_x86.ld: Conditionally add fspm regionFelix Held
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1e75f29a52179b72b25092f0ffdfd91a182d6648 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76471 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-27soc/amd/noncar/memlayout_x86.ld: Move ramstage link addressArthur Heymans
This address is more certain to not collide with other symbols. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I02eddf43a00c443a1193d6db77d6fad3715216f3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76494 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-27soc/amd/noncar/memmap.c: Support non-FSP use casesFelix Held
Without FSP we assume TSEG is right above CBMEM. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8700803617c3fe4890e497c6d7b94f1d36e21cb4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76472 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-27soc/amd/noncar/memmap.c: factor out FSP-specific SMM region codeFelix Held
Factor out the common FSP-specific code to get the location and size of the SMM region from the HOB that FSP has put into memory. This moves FSP-specific code out of the common AMD SoC code into the FSP-specific common AMD SoC code folder. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie137bb0f4e7438a1694810ae71592a34f9d8c86e Reviewed-on: https://review.coreboot.org/c/coreboot/+/76760 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> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.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-27soc/amd/cpu.c: Conditionally define .acpi_fill_ssdtFelix Held
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I0e81c08191f3c5f768bd3cad0e4915d4476c739f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76493 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-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/common/acpi/ivrs: probe IOAPIC device on domain deviceFelix Held
This reverts commit e33d253793f6 ("soc/amd/common/block/acpi/ivrs: fix missing IOAPIC[1] error"). Now that the per PCI root domain IOAPIC MMIO resource is reported on the domain device, we can again probe the resource on the domain device instead of the northbridge PCI device in that domain. This will make the IVRS code compatible again with the work in progress Genoa SoC support. TEST=Linux doesn't complain about the IOAPIC[1] missing in the IVRS on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib861b19d798fc8ee6603e8803d8d1939be08d275 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76659 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-07-25soc/amd/common/data_fabric/domain: report non-PCI MMIO resourcesFelix Held
Call read_non_pci_resources from amd_pci_domain_read_resources to tell the resource allocator about the non-PCI MMIO regions within the data fabric MMIO regions so that the allocator won't place any PCI MMIO in the same areas. TEST=On Mandolin 3 new non-PCI resources get reported to the allocator: avoid_fixed_resources: DOMAIN: 0000 04 base fd100000 limit fd1fffff mem (fixed) avoid_fixed_resources: DOMAIN: 0000 05 base fd000000 limit fd0fffff mem (fixed) avoid_fixed_resources: DOMAIN: 0000 20000120 base fec01000 limit fec01fff mem (fixed) Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7f69b86e376e3368d4f156ccf93791cc00886489 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76599 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-25soc/amd/common/root_complex: add function to report non-PCI resourcesFelix Held
Introduce the common read_non_pci_resources function to read the base address of the non-PCI resources within the MMIO regions configured in the data fabric registers and pass that info to the resource allocator. Each SoC will need to provide implementations for get_iohc_misc_smn_base and get_iohc_non_pci_mmio_regs in order for read_non_pci_resources to know the SoC-specific base addresses, register offsets and MMIO region sizes. In case of SoCs with only one PCI root domain, the domain parameter of get_iohc_misc_smn_base will be unused, but in the case of SoCs with more than one PCI root domains, this parameter will be used by the SoC-specific code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If9aca67fa0f5a0d504371367aaae5908bcb17dd9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76553 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> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-07-24soc/amd/common/block/apob: Add Kconfig option to disable APOB NVFred Reitberger
Add Kconfig option to disable the non-volatile APOB cache for a mainboard using an SOC that supports APOB. BUG=b:290763369 TEST=verify APOB cache is disabled when selected Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Change-Id: I0170355bbf29ea6386fa69a318e61f057b9a9a3f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76566 Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-20soc/amd/common/smn/Kconfig: expand SMN acronymFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icce4092f1e09d492e0faf4b5e85525871614d73d Reviewed-on: https://review.coreboot.org/c/coreboot/+/76607 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-07-20soc/amd/common/block/smn: add smn_read64Felix Held
Add smn_read64 which calls smn_read32 twice to read two adjacent 32 bit SMN registers and merges the results into a 64 bit value which it then returns. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib2d58ec9818559cbefd7b819ae311ad02fafa18f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76552 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@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-17soc/amd/common/pm/pmlib: use PM register mapping in ACPIMMIO regionFelix Held
In all SoC pm_set_power_failure_state gets called either after a call to enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled after reset on the SoC. This allows to use pm_read8 and pm_write8 that use the ACPIMMIO mapping of the PM registers instead of pm_io_read8 and pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports used on older generations to access to the PM registers not being implemented any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0d0523d2c4920da41b3fb73cf62f22a60f1643a Reviewed-on: https://review.coreboot.org/c/coreboot/+/76463 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-17soc/amd/common/lpc/lpc_util: use PM register mapping in ACPIMMIO regionFelix Held
In all SoC lpc_early_init gets called either after a call to enable_acpimmio_decode_pm04() or the ACPIMMIO mapping is already enabled after reset on the SoC. This allows to use pm_read8 and pm_write8 that use the ACPIMMIO mapping of the PM registers to set the PM_LPC_ENABLE bit in the PM_LPC_GATING register instead of pm_io_read8 and pm_io_write8 which won't work on Phoenix and Glinda due to the IO ports used on older generations to access to the PM registers not being implemented any more. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8b31ec4e03a06796502c89e3c2cfaac2d41b0ed9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76461 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-17soc/amd/common/acpimmio/mmio_util: drop enable_acpimmio_decode_pm24Felix Held
None of the platforms that used enable_acpimmio_decode_pm24 is in the tree any more, so drop this function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iea345a825c4581bf2acb932692ebcad2a7a5b4ed Reviewed-on: https://review.coreboot.org/c/coreboot/+/76457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-07-14soc/amd/common: Add warning if microcode CBFS filename is in useMartin Roth
Because of the way that the CBFS filename is generated from the contents of the microcode patch, if a duplicate microcode patch is included in the build, the makefile would create a second copy of the name, which doesn't work. This led to "odd" results where the other attributes of the first copy were erased, causing cbfstool to fail. The cause of the failure is not immediately obvious, and is a little difficult to track down. This patch causes an immediate failure and gives a reason as to the cause of the issue. When a failure is seen, this is the result: File1: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHXn4_A0.bin File2: 3rdparty/amd_blobs/phoenix/psp/TypeId0x66_UcodePatch_PHX4_A0.bin src/soc/amd/common/block/cpu/Makefile.inc:25: *** Error: The cbfs filename "cpu_microcode_a740.bin" is used for both above files. Check your microcode patches for duplicates.. Stop. TEST=Now checked for both positive and negative failures. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I3d34dc5585182545bdcbfa6370ebc34aa767cae2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76423 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-14soc/amd/phoenix: Disable APOB CacheKarthikeyan Ramasubramanian
There is a data abort in ABL when the memory training data is used from APOB Cache. Disable APOB Cache until the cause is identified. The downside of this change is that the memory training happens in every boot cycle. BUG=b:290763369 TEST=Build BIOS image and boot to OS in Myst. Trigger a reboot from AP console and ensure that the system boots to OS. Change-Id: I20f4f40cdaac68bca6e121e3a238d13fe80d0d3c Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76422 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-07-14mb/google: AMD: move tpm_tis to AMD common codeGrzegorz Bernacki
It moves cr50_plat_irq_status() to common code and adds Kconfig option to specify GPIO used for interrupt. BUG=b:277787305 TEST=Build all affected platform and confirm using right GPIO number. Tested on Skyrim. Change-Id: I775c4e24cffee99b6ac3e05b58a75425029a86c8 Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75621 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-07-12soc/amd/common: Use newer function for resource declarationsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iad8b7c705d5053700850065f90314444904b5b54 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76289 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> 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>
2023-07-04soc/amd/common/block/acpi/ivrs: use IOMMU PCI register definitionsFelix Held
Use IOMMU_CAP_BASE_[LO,HI] instead of magic values. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7032d9f032a22649951ef1535f39b918eb8bd539 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76223 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-07-04soc/amd/common/block/iommu: factor out PCI register definitionsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie155cab1f659e9f7b64cd87ba8a77260056656d8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76222 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>
2023-07-04soc/amd/common/block/uart: remove DRIVERS_UART_8250MEMEric Lai
Select DRIVERS_UART_8250MEM_32 will select DRIVERS_UART_8250MEM too. Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Change-Id: I87a47e2d76ab7a0717edf725bf94d87f9f2357f1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76184 Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-06-28soc/amd/common/block/acpi/ivrs: fix missing IOAPIC[1] errorFelix Held
When probing the resource with the IOMMU_IOAPIC_IDX index, we need to use the PCI device 0 function 0 on the first bus in the domain for probing and not the domain device, since the resource isn't on the domain device, but on the northbridge device which is B0F0D0 in the case of the APUs. TEST=This fixes the following error on Mandolin with Picasso: AMD-Vi: [Firmware Bug]: : IOAPIC[1] not in IVRS table AMD-Vi: Disabling interrupt remapping Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id88f17d68ba5accef6561837478828bd3d24baa5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76117 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-27soc/amd/block/ivrs: Add NULL check for IVRSNaresh Solanki
Add NULL check for ivrs pointer before use. Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Change-Id: Ibeb0ea3bcaa3512a93500588ad4f11046edee61f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-06-26soc/amd/common/iommu.c: Make sure iommu is enabledArthur Heymans
Don't rely on vendorcode to set enable bit on IOMMU. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Change-Id: I1805a20656b7fb3915f8cc93c618ee074461840f Reviewed-on: https://review.coreboot.org/c/coreboot/+/75829 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-06-26soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_[range,entry]Felix Held
Zero-initialize the ivhd_range and ivhd_entry structs to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iccacc89bfc497449ad0716a3436949505b65f748 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76079 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-26soc/amd/common/block/acpi/ivrs: use size of instance instead of typeFelix Held
To determine the length parameter of memset, use sizeof with the instance as argument instead of the type. The behavior is the same, but it clarifies parameters in the memset call a bit. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I63674fbed7097a583cd77fa6e700652d6dcc5565 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76078 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-26soc/amd/common/block/acpi/ivrs: use memset on ivhd_[11,40]Felix Held
Assign the current address casted to acpi_ivrs_ivhd[11,40]_t pointer to *ivhd_[11,40] at the beginning of acpi_fill_ivrs[11,40] and then use memset on *ivhd_[11,40] to zero-initialize the structs. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I70b12fee99d6c71318189ac35e615589a4c8c629 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76077 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-06-23soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_hpet structFelix Held
Zero-initialize the ivhd_hpet struct right at the beginning of the ivhd_describe_hpet function to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If4d3563c485eed4a7cb0526a62f7b6c80f763bfd Reviewed-on: https://review.coreboot.org/c/coreboot/+/76074 Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-06-23soc/amd/common/acpi/ivrs: add HID argument to ivhd_describe_f0_deviceFelix Held
Allow the caller to specify the HID that gets written to the ivrs_ivhd_f0_entry_t struct. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I830f1fbbd535b100c88997ece10142a5d553950f Reviewed-on: https://review.coreboot.org/c/coreboot/+/76073 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2023-06-23soc/amd/common/block/acpi/ivrs: zero-initialize ivhd_f0 structFelix Held
Zero-initialize the ivhd_f0 struct right at the beginning of the ivhd_describe_f0_device function to make sure that the whole struct is in a defined state. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia6750b58dacb9b9192ed21128eb6e3a4495b96d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76072 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
2023-06-23soc/amd/common/block/acpi/ivrs: conditionally generate eMMC entryFelix Held
The eMMC entry in the IVRS table should only be generated if an eMMC controller is present in the SoC. Where the PCI_DEVFN(0x13, 1) is from is currently unclear to me. There is no PCI device 0x13 on bus 0 and the eMMC controller is also an MMIO device and not a PCI device, but this is what the reference code does. My guess would be that it mainly needs to be a unique PCI device that won't collide with any existing PCI device in the SoC. Add a comment about this too. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I00865cb7caf82547e89eb5e77817e3d8ca5d35dd Reviewed-on: https://review.coreboot.org/c/coreboot/+/75933 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-06-23Makefile.inc: don't add fmap_config.h dependency twiceFelix Held
Commit d054bbd4f1ba ("Makefile.inc: fix multiple jobs build issue") added a dependency on $(obj)/fmap_config.h to all .c source files in all stages, so it's not needed any more to add it as a dependency to files that include fmap_config.h. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b62917f32ae9f51f079b243a606e5db07ca9099 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76002 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 13:39:39 +0000