summaryrefslogtreecommitdiff
path: root/src/soc/amd
AgeCommit message (Collapse)Author
2023-10-20soc/amd/common/psp_verstage: Add PSP_VERSTACK_STACK_IS_MAPPED configKarthikeyan Ramasubramanian
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if a buffer comes from within SRAM address range, then it is passed directly to Crypto Engine. Otherwise a bounce bufer from the stack is used. But on SoCs like Picasso where PSP Verstage stack is mapped to a virtual address space this check fails causing a bounce buffer to be used and hence a stack overflow. Fix this issue by assuming that the buffer comes from the SRAM always in such SoCs and pass the buffer directly to crypto engine. BUG=b:259649666 TEST=Build and boot to OS in Dalboz with unsigned PSP verstage. Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
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-12soc/amd/genoa/include/data_fabric: add VGA decode enable registerFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iaf4a1fd61ad1d545b1ea0ab3fcf6c7a3d0260cd0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78319 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-10-11soc/amd/genoa: add root complex support codeFelix Held
This functionality will eventually be used by the common data fabric domain resource reporting code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ieedd432c144e53e43d8099ec617a15056bb36fd1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78307 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-11soc/amd/genoa/include: add data_fabric.hFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I18871af0a8dbc1423524b681d516476e63b9596a Reviewed-on: https://review.coreboot.org/c/coreboot/+/78306 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2023-10-11soc/amd/genoa: Enable uartVarshit Pandya
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: I1529657f30b6e228c2e3cd7e0438255522381367 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76507 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-11soc/amd/genoa: Add GPIO supportVarshit Pandya
Change-Id: I2e827e9ffbb2ec1be0f1247b77660a9fdeb04f7b Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78222 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-11soc/amd/genoa: Add SMI supportVarshit Pandya
Add SMI definitions as per Genoa PPR Doc #55901 Change-Id: I491f4075cef8976e4b0762752c9e2e3c2ef886d5 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78221 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-11soc/amd/genoa: Add GPIO definitionsVarshit Pandya
Add GPIO definitions as per Genoa PPR Doc #55901 Change-Id: I0c4e425699c9a158ca95a1baf94f7756f0b12b44 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78220 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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-10-10soc/amd/genoa: Enable eSPI earlyArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I4965eac4ec3d600b1e840affce4e5b4fa2ea4360 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76508 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-10-10soc/amd/genoa: Add aoac.c & enable AOAC devices earlyArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic9553e6016c92c9b1678c395cd6a9e6860bf8a76 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76506 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-10soc/amd/genoa: Enable cf9 IO earlyArthur Heymans
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I05990c2aca40d9cf47a9ebdfd269b80b8f60e300 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76505 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-09soc/amd/common/vboot: Fix PSP verstage timestamps after TSC adoptionKarthikeyan Ramasubramanian
Commit 26d54b70e282 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP Verstage timestamps (in microseconds) to the x86 TSC rate. But it included only the base_time during the adjustment leaving the individual entry timestamp. This leads to incorrectly adjusted PSP Verstage timestamps. Fix the adjustment logic. BUG=None TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage timestamps in cbmem -t output are adjusted correctly. Before this change: 5:start of verified boot 67,890 (69,936) 503:starting to initialize TPM 67,890 (0) 504:finished TPM initialization 67,902 (12) 505:starting to verify keyblock/preamble (RSA) 67,906 (3) 506:finished verifying keyblock/preamble (RSA) 67,984 (77) 511:starting TPM PCR extend 67,984 (0) 512:finished TPM PCR extend 67,992 (7) 513:starting locking TPM 67,992 (0) 514:finished locking TPM 67,995 (3) 6:end of verified boot 67,995 (0) 11:start of bootblock 572,152 (504,156) After this change: 5:start of verified boot 71,000 (73,040) 503:starting to initialize TPM 71,065 (65) 504:finished TPM initialization 101,506 (30,441) 505:starting to verify keyblock/preamble (RSA) 110,624 (9,118) 506:finished verifying keyblock/preamble (RSA) 297,101 (186,477) 511:starting TPM PCR extend 297,297 (196) 512:finished TPM PCR extend 315,338 (18,041) 513:starting locking TPM 315,341 (3) 514:finished locking TPM 322,922 (7,581) 6:end of verified boot 322,943 (21) 11:start of bootblock 570,296 (247,353) Change-Id: I3e52bef22f65596152f29c511bed680427660ff5 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231 Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
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-28treewide: convert to tpm_result_tJon Murphy
Convert TPM functions to return TPM error codes(referred to as tpm_result_t) values to match the TCG standard. BUG=b:296439237 TEST=build and boot to Skyrim BRANCH=None Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1 Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666 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-09-28soc/amd/genoa: Enable ECAM MMCONF supportArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: I70db8bf9f553fa9bfd2a5c20a1393119786047f8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76504 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-28soc/amd/genoa/reset.c: Add reset methodsArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ifb4d7dda5fcf1ccacb901b24e4f7cf6945ee16e0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76503 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-28soc/amd/genoa/southbridge.h: Add PM related macrosArthur Heymans
All verified with PPR. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: If288079310ba74333f04173978f6a123ce95f4d9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76502 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-28soc/amd/genoa: Add timer & tsc supportArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: Ie1ae2ba4d4833570ca0621023bdeed67ccabe5cb Reviewed-on: https://review.coreboot.org/c/coreboot/+/76501 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-28soc/amd/genoa: Add function to fetch common code dt configurationArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: I5d5d3ff27ab0953844f9bbef30b6487fb480e29b Reviewed-on: https://review.coreboot.org/c/coreboot/+/76500 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>
2023-09-28soc/amd/genoa: Deal with memory map for 32M or larger flashArthur Heymans
Only the lower half of the flash gets memory mapped below 4G in the current setup. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: Iffe5c17a50f3254411a4847c7e635ce0fd282fde Reviewed-on: https://review.coreboot.org/c/coreboot/+/76499 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-28soc/amd/genoa: Add Kconfig/Makefile to generate PSP imageArthur Heymans
TESTED: AMD onyx reaches x86 code Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Change-Id: I95d84f93663a80f322fd4d7cdeb35ccfe0ec7d21 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76498 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>
2023-09-28soc/amd/genoa: Add chipset.cbvbpandya
Change-Id: I6c9879a9f06f81d577bc09f6001158d7f9326362 Signed-off-by: vbpandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78082 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>
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-21soc/amd/mendocino: Do not load MP2 Firmware when in ROKarthikeyan Ramasubramanian
Currently MP2 Firmware is not built into RO firmware section but the soft fuse bit to disable MP2 firmware loading is not set. This causes the device to boot loop during recovery mode. Set the bit to disable MP2 firmware loading in RO. BUG=b:259554520 TEST=Build and boot to OS in Skyrim under both normal and recovery modes. Change-Id: I9e4cf4f72e2d36ad3cc33629ddb501ecdbf5eda9 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78023 Reviewed-by: Robert Zieba <robertzieba@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jon Murphy <jpmurphy@google.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Martin L Roth <gaumless@gmail.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-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-18drivers/tpm: Make temp test value naming consistentJon Murphy
Make naming convention consistent across all functions return values. BUG=b:296439237 TEST=Boot to OS on Skyrim BRANCH=None Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
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-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-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-05soc/amd/common/vboot: Drop reporting of Silicon levelMatt DeVillier
Per the PSP team, this field in the transfer buffer isn't used anymore and always set to zero, causing devices to incorrectly report having pre-production silicon. Change-Id: Ida4bf4b9328ac83d905e4c3f822e6ceabe9be79d Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77630 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-09-05amdfwtool: Add FW type FUSE_CHAIN in the config fileZheng Bao
We don't have file for the fuse chain, but we need to set the level for some cases. Change-Id: Idb546f761ae10b0d19a9879a9a644b788828d523 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77506 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-09-04soc/amd/common: Use CBFSTOOL_ADD_CMD_OPTIONS when adding psp imageArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I639fb1e911a7449d0db0d2bfcfbb6f4f225b0cef Reviewed-on: https://review.coreboot.org/c/coreboot/+/76496 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-09-04soc/amd/mendocino: Specify and use FSP binaries for platformMatt DeVillier
Specify the default path to, and automatically include the FSP binaries needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board configs, and matches use in previous patforms. TEST=build/boot google/skyrim Change-Id: Ic837d264327723c8dc18a60fb16e8d41fe38b44e Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77625 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-09-04soc/amd/cezanne: select ADD_FSP_BINARIES if USE_AMD_BLOBSMatt DeVillier
Automatically include the FSP binaries needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board configs, and matches use in soc/amd/picasso. TEST=build/boot google/guybrush Change-Id: I5b6e34085410a2aafe5d7876be5097f28f521ce8 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77624 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-01soc/amd/genoa: Add minimal viable code for compilationArthur Heymans
This adds a dummy soc (genoa) based on EXAMPLE_MIN86 with amd linker script hooked up. Default to 64bit code as that will be a sensible default for this platform (high memory access required for RAS setup). Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I69253466084d17c4359d7e824d69f12490b076e4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76495 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2023-09-01amd/soc/common: Use relative offset for AMDFWZheng Bao
The amdfw.rom is mostly in region COREBOOT. Calculate the relative address as the CBFS module address. That is for future 32M flash size support. TEST=binary identical test 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 This commit is part of a series of patches to support 32/64M flash. BUG=b:255374782 Change-Id: I2add8e4e6755e582b3be6a150cf83d1468f2f1be Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72961 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-15nb,soc/amd/*/northbridge: use mmio_range to add IOAPIC2 resourcesFelix Held
Instead of open coding this, use the mmio_range helper function to tell the resource allocator about the northbridge's IOAPIC's MMIO. This change sets the IORESOURCE_RESERVE and IORESOURCE_STORED bits in the resource flags that weren't set before, but mmio_range is already used elsewhere for similar purposes. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id66a73cdb22fd551e4359914ba5513313dcc3193 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77173 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
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/glinda/Kconfig: fix commentFelix Held
The SOC_AMD_REMBRANDT_BASE comment at the end of Glinda's Kconfig is probably a leftover from the Mendocino/Rembrandt SoC this file was copied from. Change it to SOC_AMD_GLINDA to match the corresponding 'if SOC_AMD_GLINDA' in the file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I85132e4840c1bc713cfc2f3493f800d66edd10ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/77121 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
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-10soc/amd/mendocino/include/data_fabric: fix IOMS0_FABRIC_ID for RembrandtFelix Held
Rembrandt has different data fabric component IDs compared to Mendocino. PPR #56558 Rev 3.04 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3c840a3e071a289d9e02143ee790c26faeda029d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77081 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-08-10soc/amd/common/psp_verstage: Enable Legacy IO only on older SoCsKarthikeyan Ramasubramanian
With reference to the Picasso PPR 55570 Rev 3.18, LegacyIoEn bit is 0 on reset and setting it will enable the decoding of the following legacy IO ports: 0x20, 0x21, 0xA0, 0xA1 (PIC); 0x40, 0x41, 0x42, 0x43, 0x61 (8254 timer); 0x70, 0x71, 0x72, 0x73 (RTC); 0x92. Verstage does not use those legacy IO ports. Also newer SoCs like Phoenix do not support Legacy I/O registers to access Power Management registers and accessing them from PSP verstage causes a hang. Hence enable legacy IO only on platforms that support it. BUG=b::284984667 TEST=Build Myst BIOS image with PSP Verstage. Boot to OS successfully with PSP verstage. Change-Id: I5e74b4cd1fa7e942770976e5e2197ded47503660 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76692 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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/glinda/include/data_fabric: add DF PCI config map registerFelix Held
PPRs #57254 Rev 1.52 and #57255 Rev 0.33 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie54fd6c5a82f368018d0b5fb811a6c9220c2c70b Reviewed-on: https://review.coreboot.org/c/coreboot/+/77079 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-09soc/amd/phoenix/include/data_fabric: add DF PCI config map registerFelix Held
PPRs #57019 Rev 3.05 and #57396 Rev 3.06 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id0fe478a710ecc1f2c8b36347aaf2d1634ebba9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/77078 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-09soc/amd/mendocino/include/data_fabric: add DF PCI config map registerFelix Held
PPRs #57243 Rev 3.02 and #56558 Rev 3.04 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibabe8faa79e3dcd02f4c885d29b9634645947b98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77077 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/cezanne/include/data_fabric: add DF PCI config map registerFelix Held
PPR #56569 Rev 3.04 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idfac7d996c6de9ea7c6adf2760de0ad97ffb9ec0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/77076 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/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/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-09soc/amd/stoneyridge: use SoC common uart opsMatt DeVillier
Define the UARTs as MMIO devices in the chipset devicetrees. Drop ACPI _STA in asl since now handled by common SSDT generator. Implement wait_for_aoac_enabled() since required by SoC common code, and ensure compiled during all stages necessary. TEST=build/boot google/liara, verify console UART still functional. Change-Id: Ibecafdfa189d9c63a29b63759c5b965d03719009 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77093 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/glinda/include/data_fabric: add data fabric IO decode registersFelix Held
PPRs #57254 Rev 1.52 and #57255 Rev 0.33 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia58e26caa1ba910b41911991b176a1ac8c4e0065 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76959 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-08soc/amd/phoenix/include/data_fabric: add data fabric IO decode registersFelix Held
PPRs #57019 Rev 3.05 and #57396 Rev 3.06 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I769dc317115981391cf0f4e0b743c600407a6eb6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76958 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-08soc/amd/mendocino/include/data_fabric: add DF IO decode registersFelix Held
PPRs #57243 Rev 3.02 and #56558 Rev 3.04 were used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic68e73e28362abc5d812839b40282114c7ba25ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/76957 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2023-08-08soc/amd/cezanne/include/data_fabric: add data fabric IO decode registersFelix Held
PPR #56569 Rev 3.04 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifcae9c9ad664d50100cd40692fd9631845f76671 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76956 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
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/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: 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/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/phoenix: Makefile change to include split hash tableKarthikeyan Ramasubramanian
Include multiple hash tables into relevant CBFS. BUG=b:277292697 TEST=Ensure that all multiple hash tables are part of Myst BIOS image with PSP verstage enabled. Change-Id: I1601f4a01db5b2bbf8b5636ef9e69e41c1d9a980 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76589 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-04soc/amd/phoenix: Add SVC call to inject v2 hash tablesKarthikeyan Ramasubramanian
On mainboards using Phoenix SoC with PSP verstage enabled, to accommodate growing number of PSP binaries, multiple smaller hash tables are introduced. Also some hash tables are in V2 format identifying the concerned PSP binaries using UUID. Add SVC calls to support multiple hash tables with different versions. BUG=b:277292697 TEST=Build and boot to OS in Myst with PSP verstage enabled. Ensure that all the hash tables are injected successfully. Ensure that PSP validated all the signed PSP binaries using the injected hash tables successfully. Change-Id: I64e1b1af55cb95067403e89da4fb31bec704cd4f Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76588 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-04soc/amd/common/psp_verstage: Support multiple hash tablesKarthikeyan Ramasubramanian
Currently PSP verstage updates PSP bootloader with one unified hash table containing hashes for all the signed PSP binaries to be validated. With growing number of PSP binaries to validate and memory constraints in PSP, there is a requirement to split and update the hash table into multiple smaller chunks. Hence change the update_psp_fw_hash_table() signature such that the hash tables are updated in a chipset specific way. BUG=b:277292697 TEST=Build and boot to OS in Myst with PSP verstage enabled. Build the Skyrim BIOS image and confirm that the hash table is identical before and after this change. Change-Id: I75aac5bc5e7f61069be25d801d0838fdf565d3d1 Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76587 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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/mendocino: select SOC_AMD_COMMON_BLOCK_CPU_SYNC_PSP_ADDR_MSRMatt DeVillier
Select this Kconfig to ensure the PSP_ADD_MSR is properly programmed across all cores. This resolves a Windows BSOD "CRYPTO_LIBRARY_INTERNAL_ERROR." BUG=b:293571109 BRANCH=skyrim TEST=build/boot google/skyrim, use rdmsr to verify MSR value identical across all cores. Change-Id: I67391b49496d767912f5d81c1758a52a70fca6f6 Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76809 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>