summaryrefslogtreecommitdiff
path: root/src/soc/amd/common
AgeCommit message (Collapse)Author
2024-10-28soc/amd/common/psp: add RPMC provisioning codeFelix Held
Add the code to request the provisioning of the RPMC root key from the PSP. When RPMC hasn't already been provisioned enabled and the PSP has detected a SPI flash chip that both supports RPMC and has monotonic counters that can still be provisioned, we send the PSP mailbox command to request the RPMC provisioning and then reset the system, so the PSP can do the actual provisioning. TEST=On an out of tree AMD reference board using the Cezanne SoC code, provisioning RPMC works as expected when selecting the corresponding PERFORM_RPMC_PROVISIONING Kconfig option: 1st boot to initiate the RPMC provisioning: [DEBUG] PSP: Querying PSP capabilities...OK [DEBUG] PSP: Querying HSTI state...OK [SPEW ] RPMC isn't provisioned [SPEW ] SPI flash supports RPMC [SPEW ] RPMC revision 0 [SPEW ] PSP NVRAM isn't healthy [SPEW ] PSP NVRAM is using RPMC protection [SPEW ] SPI flash RPMC counter 0 can still be provisioned [SPEW ] SPI flash RPMC counter 1 can still be provisioned [SPEW ] SPI flash RPMC counter 2 can still be provisioned [SPEW ] SPI flash RPMC counter 3 can still be provisioned [SPEW ] SPI flash RPMC counter 0 is in use [SPEW ] SPI flash RPMC counter 1 is not in use [SPEW ] SPI flash RPMC counter 2 is not in use [SPEW ] SPI flash RPMC counter 3 is not in use [SPEW ] SoC RPMC slot 0 can still be provisioned [SPEW ] SoC RPMC slot 1 can still be provisioned [SPEW ] SoC RPMC slot 2 can still be provisioned [SPEW ] SoC RPMC slot 3 can still be provisioned [DEBUG] RPMC: perform fusing using RPMC counter address 0 [DEBUG] OK [NOTE ] RPMC: Rebooting [INFO ] warm_reset() called! 2nd boot after the provisioning is done: [DEBUG] PSP: Querying PSP capabilities...OK [DEBUG] PSP: Querying HSTI state...OK [SPEW ] RPMC is provisioned [SPEW ] SPI flash supports RPMC [SPEW ] RPMC revision 0 [SPEW ] PSP NVRAM isn't healthy [SPEW ] PSP NVRAM is using RPMC protection [SPEW ] SPI flash RPMC counter 0 has already been provisioned [SPEW ] SPI flash RPMC counter 1 can still be provisioned [SPEW ] SPI flash RPMC counter 2 can still be provisioned [SPEW ] SPI flash RPMC counter 3 can still be provisioned [SPEW ] SPI flash RPMC counter 0 is in use [SPEW ] SPI flash RPMC counter 1 is not in use [SPEW ] SPI flash RPMC counter 2 is not in use [SPEW ] SPI flash RPMC counter 3 is not in use [SPEW ] SoC RPMC slot 0 has already been provisioned [SPEW ] SoC RPMC slot 1 can still be provisioned [SPEW ] SoC RPMC slot 2 can still be provisioned [SPEW ] SoC RPMC slot 3 can still be provisioned Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia7760c0bf7618ca60ef160329d0110ac8109032a Reviewed-on: https://review.coreboot.org/c/coreboot/+/84707 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-10-28soc/amd/common/psp: add code for reporting RPMC statusFelix Held
Add the code to query the status of the replay-protected monotonic counter (RPMC) infrastructure from the PSP and display it in a decoded form. Certain SPI flash chips have 4 32-bit monotonic counters in addition to the actual flash storage. During the RPMC root key provisioning process, which is done at the end of manufacturing, a 256 bit RPMC root key is generated by the PSP and programmed into both SoC fuses and the RPMC SPI flash chip. After that, commands to read or increment the monotonic counters can be sent to the SPI flash which are protected by a HMAC-SHA-256 signature using a key derived from the provisioned RPMC root key. The code to do the RPMC provisioning is added in a follow-up patch. TEST=On an out of tree AMD reference board using the Cezanne SoC code and with the SOC_AMD_COMMON_BLOCK_PSP_RPMC Kconfig option selected, the newly added code prints this on the console after the provisioning was done: [DEBUG] PSP: Querying PSP capabilities...OK [DEBUG] PSP: Querying HSTI state...OK [SPEW ] RPMC is provisioned [SPEW ] SPI flash supports RPMC [SPEW ] RPMC revision 0 [SPEW ] PSP NVRAM isn't healthy [SPEW ] PSP NVRAM is using RPMC protection [SPEW ] SPI flash RPMC counter 0 has already been provisioned [SPEW ] SPI flash RPMC counter 1 can still be provisioned [SPEW ] SPI flash RPMC counter 2 can still be provisioned [SPEW ] SPI flash RPMC counter 3 can still be provisioned [SPEW ] SPI flash RPMC counter 0 is in use [SPEW ] SPI flash RPMC counter 1 is not in use [SPEW ] SPI flash RPMC counter 2 is not in use [SPEW ] SPI flash RPMC counter 3 is not in use [SPEW ] SoC RPMC slot 0 has already been provisioned [SPEW ] SoC RPMC slot 1 can still be provisioned [SPEW ] SoC RPMC slot 2 can still be provisioned [SPEW ] SoC RPMC slot 3 can still be provisioned Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I498eec58189da710b725ac6575c68ba7ab0bcc43 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84706 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-10-28soc/amd/common/block/psp: fix logic bug in psp_get_* functionsFelix Held
The functions psp_get_ftpm_capabilties, psp_get_hsti_state, and psp_get_psp_capabilities which were added in commit 5e7ab1a23346 ("soc/amd/common/psp: add helper functions to retrieve capability bits") have a bug in the 'cmd_status' error handling logic. In case of an error, 'cmd_status' is non-zero, while the check somehow expected the opposite. Fix the bug by returning an error if 'cmd_status' is non-zero. Change-Id: Iafcd185ec4a8a4c0e463b0ac5bac3ef78a0af305 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84836 Reviewed-by: Ana Carolina Cabral Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2024-10-11soc/amd/common/block/psp/Kconfig: drop some 'default n'Felix Held
Since the Kconfig default for boolean options is already 'n', there's no need to add that default to the option. Still kept the 'default n' for the 3 options that result in fuses inside the SoC to be burnt (PERFORM_RPMC_PROVISIONING, PERFORM_SPL_FUSING and PSP_PLATFORM_SECURE_BOOT) to point out the fact that that's not selected by default more clearly. Change-Id: I55971f1f130d8ec23d4572a215008d9465e1520a Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84719 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-10-11soc/amd/common/psp_smi_flash: add RPMC command-specific data structuresFelix Held
Add the data structures used for the command buffers for the PSP SMI commands to increment and request the state of the monotonic counters in the SPI flash. These data structures are specific to the PSP SMI mailbox interface and not the data structures from the RPMC specification. The AGESA code was used as a reference. Change-Id: I8bc8ff4cf9b7ebd0e034f040dde2db8385bb8f79 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84704 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
2024-10-09soc/amd/common/psp: add and call PSP SMI SPI RPMC function stubsFelix Held
In the case where the x86 owns the SPI controller and the RPMC feature is used, the PSP will send an SMI to the x86 side for it to send the RPMC increment monotonic counter and RPMC request monotonic counter commands to the SPI flash and return the result to the PSP. Add stubs as handlers for those two PSP SMI commands. Change-Id: If6091d2b0002f817922cac4cba373f0f981b646e Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84702 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ana Cabral
2024-09-16soc/amd/common/psp/psb: add missing newline in debug messageFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I794899fa55b510e6f39dadc1a831b86389ab31ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/84355 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-27soc/amd/common/psp: move PSP SMI SPI access function prototypesFelix Held
Now that we have the local psp_smi_flash.h header, move the psp_smi_spi_* function prototypes there. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I12cbbabf6a960836fe0c5dc1424c08550cb66a7a Reviewed-on: https://review.coreboot.org/c/coreboot/+/84068 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-27soc/amd/common/psp: consistently use uint[8,16,32,64]_t data typesFelix Held
Use the uint[8,16,32,64]_t data types everywhere instead of a mixture of uint[8,16,32,64]_t and u[8,16,32,64] data types for consistency. Suggested-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I36151ecf94619afaf690dbb73834fcff3c51fdac Reviewed-on: https://review.coreboot.org/c/coreboot/+/84067 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-27soc/amd/common/psp: add helper functions to retrieve capability bitsFelix Held
Add helper functions to send the PSP commands to query the fTPM and PSP capability bits as well as the HSTI state. All SoCs using any PSP generation support the MBOX_BIOS_CMD_PSP_FTPM_QUERY command and some generation 1 and all generation 2 PSP SoCs support the MBOX_BIOS_CMD_HSTI_QUERY command, so implement those two in the common psp.c. Only PSP generation 2 supports the MBOX_BIOS_CMD_PSP_CAPS_QUERY command, so implement that one in psp_gen2.c. This code is ported and modified from github.com/teslamotors/coreboot/tree/tesla-4.12-amd Document #54267 revision 1.06 was used as reference for the 1st PSP generation and document #55758 revision 2.04 was used for the 2nd PSP generation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4e17f994fb332690828c55742262da793e297d99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84066 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-27soc/amd/common/psp/psp_def: rename MBOX_BIOS_CMD_PSP_QUERYFelix Held
Rename MBOX_BIOS_CMD_PSP_QUERY to MBOX_BIOS_CMD_PSP_FTPM_QUERY to bring it a bit more in line with document #55758 revision 2.04 and to avoid confusion when another command is added in a follow-up patch. In document #54267 revision 1.06 this command is called MBOX_BIOS_CMD_PSP_QUERY and in document #55758 revision 2.04 it's called MBOX_BIOS_CMD_FTPM_QUERY, so just name it MBOX_BIOS_CMD_PSP_FTPM_QUERY in coreboot which should be the least confusing name for it that still somewhat aligns with the documentation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id085b34363d39528bd125dfb77596d3ed13b6fa9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84065 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-27soc/amd/common/psp/psp_smi_flash: implement generation 1 supportFelix Held
Implement the request buffer access functions for the PSP generation 1 case. In this case, only the SMI_TARGET_NVRAM is supported, so always return this target NV ID and always return true in the validity checks which in the PSP generation 2 case check if the target NV ID is valid. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7e141f846e930bab6972a281745c0180ac52c291 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84064 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-27soc/amd/common/psp/psp_smi_flash: introduce common data structuresFelix Held
The request buffer data structures differ between the PSP generation 1 and 2 in the way that the generation 2 added the 64 bit target NV ID field right at the beginning of the request buffer data structures. In order to make the data structure definitions common, remove the target_nv_id struct element via the preprocessor in case the SOC_AMD_COMMON_BLOCK_PSP_GEN2 option isn't selected. Since the request buffer data structures are now common for both generations, also remove the 'v2' from the struct names. Document #54267 revision 1.06 was used as reference for the 1st PSP generation and document #55758 revision 2.04 was used for the 2nd PSP generation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibe0bd2d8e6a5c39cc67a49e7bb3a51ce0900a39a Reviewed-on: https://review.coreboot.org/c/coreboot/+/84063 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-27soc/amd/common/psp/psp_smi_flash: factor out generation-specific codeFelix Held
Factor out the code to access the request buffer into PSP generation specific file. This is a preparation for adding PSP SMI flash access support for the PSP generation 1 which has a slightly different request buffer layout. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8e18f7ea53592d9fd413ad56e8d137cfc13ad5d4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84062 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-27soc/amd/common/psp/psp_def: rework command buffer documentationFelix Held
The existing comment on the mbox_default_buffer struct was outdated and didn't reflect the current state, so rework it to keep it a bit more generic and also add the document number for the newer generations of CPUs. To better document which commands use non-default buffers, add the names of the commands using the non-default buffers to those buffer struct definitions. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I510d953217240243392e8a415358524257bd28b1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84061 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-07soc/amd/common/psp_smi_flash: add buffer overflow checksFelix Held
Before 'handle_psp_command' calls any of the functions in this file, it make sure that the 'size' field in the command buffer's header doesn't indicate that the command buffer is larger than the SMM memory region reserved for it. The read/write command buffer has a 'num_bytes' field to indicate how many bytes should be read from the SPI flash and put into the data buffer within the command buffer or how many bytes from this buffer should be written to the flash. While we should be able to assume that the PSP won't send us malformed command buffer, we should still better check this just to be sure. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib4e8514eedc3ad154a705c8a1e85d367e452dbed Reviewed-on: https://review.coreboot.org/c/coreboot/+/83778 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi_flash: implement SPI read/write/erase commandFelix Held
Use coreboot's SPI flash access infrastructure to do the flash read, write, or erase operations as requested from the PSP. This patch is a modified version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I4957a6d316015cc7037acf52facb6cc69188d446 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83777 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-08-07soc/amd/common/psp_smi_flash: implement SPI info commandFelix Held
Detect the block size of the SPI flash and number of flash blocks reserved for the flash region corresponding to the 'target_nv_id' field in the command buffer. This information is then written to the corresponding fields in the command buffer. Since detecting the flash chip still might result in accesses to it, make sure that it's available for use and not currently used by an OS driver. Since this code is inside the SMI handler, we don't have to worry about this code to be interrupted, so we don't need to set some bit to tell other code that we're currently using the SPI controller in the SMI handler. This patch is a modified version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I19041a27a9e8f901d42c3f60af834df625455ea6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83776 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi_flash: add spi_controller_availableFelix Held
The SPI_SEMAPHORE_DRIVER_LOCKED bit in the SPI_MISC_CNTRL register doesn't affect the hardware, but it re-used by AMD as a semaphore to synchronize the access to the SPI controller between SMM and non-SMM software like an OS-level driver. Since it doesn't affect the hardware, it's marked as reserved in the PPRs. Add the 'spi_controller_available' helper function to check this bit to see if some software or driver outside of SMM is currently using the SPI flash controller to avoid interfering with that operation. This patch is a slightly reworked version of parts of CB:65523. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I49218e03a5dd555b2b2d34eaad86673e9fc908c3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83775 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi_flash: add find_psp_spi_flash_device_regionFelix Held
Add 'find_psp_spi_flash_device_region' to get a pointer to the spi_flash struct of the SPI flash used in the system and the region_device struct for the target FMAP region specified by the target NV ID from the PSP to x86 mailbox command. In order to have small patches, the newly added static 'find_psp_spi_flash_device_region' function is marked as inline; that inline will be removed in a following patch that calls this new function. This patch is a slightly reworked version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I64b8fba2392de46ecd4c786cef0d5b6acdbd865a Reviewed-on: https://review.coreboot.org/c/coreboot/+/83774 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi_flash: validate target SPI region IDFelix Held
Add and use functions to validate the target non-volatile storage ID in the different command buffer structs. This patch is a slightly reworked version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: Idda0166c862d41d380b2ed21345eead5e0a1c135 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83758 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi_flash: add command-specific data structuresFelix Held
This patch is a slightly modified version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I41efeecf9243ddbbd8dc3f842c5ce11058bb7999 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83757 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp: add and call PSP SMI SPI access function stubsFelix Held
Add stub functions for the SPI flash access from the PSP SMI handler and call them for the corresponding P2C mailbox commands. Parts of this patch are taken from CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: Iedbc9d41eb0d4e8d81eeba9c01281161eb839991 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83756 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-07soc/amd/common/psp_smi: implement P2C mailbox handlingFelix Held
When the PSP wants to access the SPI flash during runtime, but isn't the owner of the SPI flash controller, it sends an SMI to the x86 side. The corresponding SMI handler then checks the P2C (PSP to core) mailbox for the command and data, processes the command, and if needed puts the requested data into the P2C buffer. The P2C mailbox is a memory region in TSEG aka SMM memory. Both location and size are communicated to the PSP via the PSP SMM info mailbox command which is sent right after mpinit is done. This commit adds the code to access the P2C mailbox to the PSP SMI handler code, but the handling of the actual mailbox commands the PSP sends to the SMI handler is added in later patches to keep the patch size manageable. This patch is a heavily reworked version of parts of CB:65523. Document #55758 Rev. 2.04 was used as a reference. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I50479bed2332addae652026c6818460eeb6403af Reviewed-on: https://review.coreboot.org/c/coreboot/+/83740 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-07soc/amd/common/include/spi: add and use SPI_MISC_CNTRL defineFelix Held
This register is currently used by the SPI DMA code that sets an undocumented bit. A later patch will add and use some other bit in this register. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I48447dcfb3cee07619a9b42434731f0b21458021 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83773 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-05soc/amd: add PSP SMI handler stubFelix Held
The PSP can send SMIs to the x86 side to have the SMI handler service requests from the PSP. This commit adds an empty PSP SMI handler; the actual implementation is added in later patches to keep the patches relatively small. This patch is a slightly modified version of parts of CB:65523. Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I65989ff529d728cd9d2cd60b384295417bef77ad Reviewed-on: https://review.coreboot.org/c/coreboot/+/83739 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-08-01soc/amd/common/smi_util: add PSP SMI helper functionsFelix Held
The PSP can send SMIs to the x86 side of the system. Add helper functions to configure and to reset the PSP SMI generation. Since Stoneyridge also selects SOC_AMD_COMMON_BLOCK_SMI, add the SMITRIG0_PSP define and rename SMITYPE_FCH_FAKE0 to SMITYPE_PSP in its SoC-specific smi.h to bring it in line with the newer SoCs. This patch is split out from CB:65523. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Signed-off-by: Ritul Guru <ritul.bits@gmail.com> Change-Id: I525a447c9a75fdb95b9750e85a02896056315edf Reviewed-on: https://review.coreboot.org/c/coreboot/+/83702 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-31soc/amd/common/psp: move buffer sizes to common headerFelix Held
Since the P2C_BUFFER_MAXSIZE value will be needed in another compilation unit, move the define to the common psp_def.h. P2C_BUFFER_MAXSIZE is moved there too for consistency reasons. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8d4d93760c90ad6e0ecadf70600b1d697a02fa82 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83701 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-31soc/amd/common/psp_smm: introduce and use send_psp_command_smmFelix Held
When sending mailbox commands to the PSP from SMM, the SMM flag needs to be set right before sending the mailbox command and cleared right after the command is sent. In order to not have this code duplicated, factor it out into a function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3628463dece9d11703d5a068fe7c604108b69c1f Reviewed-on: https://review.coreboot.org/c/coreboot/+/83700 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-07-31soc/amd/common/psp_smm: add comments to psp_notify_smmFelix Held
The reasoning behind this and the positive side effects of this aren't too clear from the code, so point those out in a comment. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4f4121031fc1ef600cdf5551f61f1ef4e03b56a5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83699 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-07-31soc/amd/common/psp_smm: add/improve comments to buffers and flagsFelix Held
Since it's not exactly obvious what 'c2p_buffer', 'p2c_buffer' and 'smm_flag' are used for, add comments to those. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4ec092a92fe9f0686ffb7103e441802fc05381f4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83698 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-07-31device: introduce and use dev_get_domain_idFelix Held
To avoid having constructs like 'dev->path.domain.domain' in the SoC code, create the 'dev_get_domain_id' helper function that returns the domain ID of either that device if it's a domain device or the corresponding domain device's domain ID, and use it in the code. If this function is called with a device other than PCI or domain type, it won't have a domain number. In order to not need to call 'die', 'dev_get_domain_id' will print an error and return 0 which is a valid domain number. In that case, the calling code should be fixed. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3d79f19846cea49609f848a4c42747ac1052c288 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83644 Reviewed-by: Shuo Liu <shuo.liu@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-25soc/amd/common/psp_gen2: use MMIO access againFelix Held
Now that we have a get_psp_mmio_base function that will work on all SoCs that use the psp_gen2 code, we can move back to accessing the PSP registers via their MMIO mapping. This sort-of reverts commit 198cc26e4951 ("soc/amd/common/block/psp/psp_gen2: use SMN access to PSP"). When doing SMN accesses from the SMI handler after the OS has taken over ownership of the platform, there's the possibility to cause trouble by clobbering the SMN access index register from SMM. So that should be either avoided completely or the SMI code needs to save and restore the original contents of the SMN index register. The PSP MMIO base will be set up by the FSP before the resource allocation in coreboot and be treated like a fixed resource by the allocator. The first SMI where corresponding handler calls 'get_psp_mmio_base' happens when ramstage triggers the APM_CNT_SMMINFO SMI right after mpinit which happens after the resource allocation. So the PSP MMIO base address is expected to be configured and so the 'get_psp_mmio_base' function will cache the base address and won't need to do any SMN access in subsequent calls that might happen after the OS has take over control. This isn't currently an issue, since the only PSP mailbox command from the SMI handler after coreboot is done and the OS has taken over will be during the S3/S4/S5 entry, and this will be triggered by the OS as the last step after it is done with all its preparations for suspend/ shutdown. There will however be future patches that add SMI-handlers which can send PSP mailbox commands during OS runtime, and so we have to make sure we don't clobber the SMN index register. TEST=PSP mailbox commands are still sent correctly on Mandolin. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I25f16d575991021d65b7b578956d9f90bfd15f6c Reviewed-on: https://review.coreboot.org/c/coreboot/+/83448 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>
2024-07-25soc/amd/common/psp_gen2: return status from soc_read_c2p38Felix Held
This sort-of reverts commit 00ec1b9fc7ba ("soc/amd/common/block/psp/ psp_gen2: simplify soc_read_c2p38") and is done as a preparation to switch back to using the MMIO access to the PSP mailbox registers. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icca3c7832295ae9932778f6a64c493e474dad507 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83447 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-07-25soc/amd/common/block/psp_gen2: add get_psp_mmio_baseFelix Held
Add get_psp_mmio_base which reads the PSP MMIO base address from the hardware registers. Since this function will not only be called in ramstage, but also in SMM, we can't just look for the specific domain resource consumer like it is done for the IOAPICs in the northbridge, but have to get this base address from the registers. In order to limit the performance impact of this, the base address gets cached in a static variable if an enabled PSP MMIO base register is found. We expect that this register is locked when it was configured and enabled; if we run into the unexpected case that the PSP MMIO register is enabled, but not locked, set the lock bit of the corresponding base address register to be sure that it won't change until the next reset and that the hardware value can't be different than the cached value. This is a preparation to move back to using MMIO access to the PSP registers and will also enable cases that require the use of the MMIO mapping of the PSP registers. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1d51e30f186508b0fe1ab5eb79c73e6d4b9d1a4a Reviewed-on: https://review.coreboot.org/c/coreboot/+/83446 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-07-25soc/amd/*/root_complex: introduce and use domain_iohc_info structFelix Held
Instead of implementing the functions get_iohc_misc_smn_base and get_iohc_fabric_id in the SoC code, move those functions to the common AMD code, and implement get_iohc_info in the SoC code that returns a pointer to and the size of a SoC-specific array of domain_iohc_info structs that contains the info needed by the common code instead. This allows to iterate over the domain_iohc_info structs which will be used in a later patch to find the PSP MMIO base address in both ramstage and smm. TEST=Mandolin still boots and all non-PCI MIO resources are still reported to the resource allocator Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifce3d2b540d14ba3cba36f7cbf248fb7c63483fe Reviewed-on: https://review.coreboot.org/c/coreboot/+/83443 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-07-25acpi,soc: use is_domain0 functionFelix Held
No need to open-code this when we have a function for this. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iae570ba750cb29456436349b4263808e2e410e2e Reviewed-on: https://review.coreboot.org/c/coreboot/+/83643 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Shuo Liu <shuo.liu@intel.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2024-07-25soc/amd: Ensure bank 0 is selected before accessing VBNV in CMOSYu-Ping Wu
In AMD platforms, the bit 4 of CMOS's Register A (0x0a) is DV0 bank selection (0 for Bank 0; 1 for Bank 1) [1]. Since the MC146818 driver accesses VBNV via Bank 0, the bit must be cleared before we can save VBNV to CMOS in verstage. Usually there's no problem with that, because the Register A is configured in cmos_init() in ramstage. However, if CMOS has lost power, then in the first boot after that, the bit may contain arbitrary data in verstage. If that bit happens to be 1, then CMOS writes in verstage will fail. To fix the problem, define vbnv_platform_init_cmos() to call cmos_init(0), which will configure the Register A and therefore allow saving VBNV to CMOS in verstage. [1] 48751_16h_bkdg.pdf BUG=b:346716300 TEST=CMOS writes succeeded in verstage after battery cutoff BRANCH=skyrim Change-Id: Idf167387b403be1977ebc08daa1f40646dd8c83f Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83495 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-25soc/amd/psp_verstage: Add -Oz flag for clangYu-Ping Wu
When we tried to add CMOS support to PSP verstage (CB:83495), the clang builds failed on boards with cezanne SoC (such as Guybrush), due to over-sized verstage. On the other hand, there is no such problem for gcc builds on the same boards. Building PSP verstage by clang generates much larger verstage size (81K) compared with using gcc (67K). To unblock adding features to verstage, temporarily enable -Oz for clang builds. Change-Id: I033458556986ade88fb8e68499b632deae4dd419 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83594 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de>
2024-07-22soc/amd/common/root_complex: move IOHC_MMIO_EN definition to headerFelix Held
To be able to use the IOHC_MMIO_EN define in other compilation units, move the define to the corresponding header file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If88950418406d1709ed95b3d05f7e6ad66438f95 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83444 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-07-10cbmem_top: Change the return value to uintptr_tElyes Haouas
Change-Id: Ib757c0548f6f643747ba8d70228b3d6dfa5182cd Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82752 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-07-04soc/amd/common/acpi/ivrs: use PCI_DEVFN macroFelix Held
Use the PCI_DEVFN macro to make the calculation of the ivhd->device_id value a bit clearer. TEST=Timeless build results in identical binary for Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b7949ad3524790e7d7d527c488a32e785f55bc0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83343 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-28tree: Remove unused <stdarg.h>Elyes Haouas
<stdarg.h> header is used to define macros for handling variable argument lists in functions like printf. It does not depend on the string or memory manipulation functions provided by <string.h>. So let follow conventions and include only the necessary headers in each header file. Change-Id: I07ffc65b7feefb8ec4ab8dd268113f9ed8d24685 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82664 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-13soc/amd/common/block/psp: Comment unused symbolElyes Haouas
This adds a comment for unused AMD_FWM_POSITION_20000_DEFAULT. Change-Id: Id8369f488893e7e5b2e7e7126d1b53199ed1aa77 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81973 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-04-24soc/amd/common/amd_pci_util.h: assign 0 to PIN_A in pcie_swizzle_pinFelix Held
Explicitly assign a value of 0 to the first value of the pcie_swizzle_pin enum. This won't change the behavior, but clarifies that the actual values of the enum elements matter. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I21850e21f859f2079f804d4344a1a11856b27d90 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-04-24soc/amd/common/amd_pci_util.h: rename bridge irq in pci_routing_infoFelix Held
Rename the 'irq' element of the pci_routing_info struct to 'bridge_irq' to better describe what it's doing. This struct element contains the number of the northbridge IOAPIC IRQ input the bridge IRQ is connected to signal power management or error reporting IRQs. Right now, coreboot doesn't put this information into the ACPI bytecode. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6410be673d15d6f9b5eb4c80b51fb705fec5b155 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-04-22vc/amd/opensil/stub/ramstage: add acpi_add_opensil_tables stubFelix Held
In the non-stub openSIL coreboot glue code, this can be used to add the ALIB SSDT. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3ccd2e81211417ad4ac94f208572e0fa4e1cf97c Reviewed-on: https://review.coreboot.org/c/coreboot/+/82012 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-22drivers/intel/fsp2_0: Introduce fsp print helper macrosAppukuttan V K
This patch introduces fsp print helper macros to print `efi_return_status_t' with the appropriate format. These macros are now used for fsp debug prints with return status efi_return_status_t is defined as UINT64 or UNIT32 based on the selected architecture BUG=b:329034258 TEST=Verified on Meteor Lake board (Rex) Change-Id: If6342c4d40c76b702351070e424797c21138a4a9 Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81630 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-12tree: Drop duplicated <device/{path,resource}.h>Elyes Haouas
<device/device.h> is supposed to provide <device/{path,resource}.h> Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-11tree: Drop unused <timestamp.h>Elyes Haouas
Change-Id: Ic690a7543f8a1e072650917d7a1e9e3b9dc371a3 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81823 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Jakub Czapiga <czapiga@google.com>
2024-04-11tree: Drop unused <string.h>Elyes Haouas
Change-Id: I0e216cbc4acf9571c65c345a1764e74485f89438 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81818 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-10tree: Drop unused <stdio.h>Elyes Haouas
Change-Id: I26c2abfce3417ed096d945745770fcae91a1e4ad Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81814 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Dinesh Gehlot <digehlot@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-09tree: Drop unused <post.h>Elyes Haouas
Change-Id: Ic7f6690786661e523292f7382df71ae4ad04d593 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81815 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-04-09tree: Drop unused <console/console.h>Elyes Haouas
Change-Id: Ib1a8fc50217c84e835080c70269ff50fc001392c Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81811 Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm> Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-30soc/amd: Remove blank lines before '}' and after '{'Elyes Haouas
Change-Id: I0203e77dd23fa026cd252abbda50f1e9f6892721 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81457 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-03-28cpu/x86: Link page tables in stage if possibleArthur Heymans
When switching back and forth between 32 to 64 bit mode, for example to call a 32-bits FSP or to call the payload, new page tables in the respective stage will be linked. The advantages of this approach are: - No need to determine a good place for page tables in CBFS that does not overlap. - Works with non memory mapped flash (however all coreboot targets currently do support this) - If later stages can use their own page tables which fits better with the vboot RO/RW flow A disadvantage is that it increases the stage size. This could be improved upon by using 1G pages and generating the pages at runtime. Note: qemu cannot have the page tables in the RO boot medium and needs to relocate them at runtime. This is why keeping the existing code with page tables in CBFS is done for now. TEST: Booted to payload on google/vilbox and qemu/q35 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-28soc/amd/non_car/memlayout_x86.ld: Top align the codeArthur Heymans
This does the following: - Top align the bootblock so that the only the memory needed gets used. This might slightly reduce the time the PSP needs to decompress the bootblock in memory - Use a memory directive to assert that the 16bit code is inside the top 64K segment - Use the program counter less. While the BDF linker is happy about running the program counter backwards, LLD is not. There is no downside to this. - Use a symbol rather that the program counter for sections. LLD gets confused when (.) is used along with '<': it places the section at the start of the memory region, rather than at the program counter. Using a variable name works around this. - Use a 'last_byte' section to make sure the first instruction is at 0xfff0. Both the BDF and the LLD linkers seems to work well with this code TEST: Both BFD and LLD are able to link the bootblock Change-Id: I18bdf262f9c358aa01795b11efcb863686edc79c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81433 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-03-28security/tpm: resolve conflicts in TSS implementationsSergii Dmytruk
No functional changes. Refactor code such that there won't be any compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled in. One might want to support both TPM families for example if TPM is pluggable, while currently one has to reflash firmware along with switching TPM device. Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a Ticket: https://ticket.coreboot.org/issues/433 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-03-23soc/amd/common/noncar/memmap: reduce visibility of memmap_early_dramFelix Held
The memmap_early_dram struct is now only used inside the non-CAR memmap.c, so move the struct definition there. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id2bb3d3a9e01e9bae9463c582cb105b95c673a38 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81432 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-03-23soc/amd/common/cpu/noncar/memmap: use VGA MMIO defines everywhereFelix Held
Only the VGA MMIO range used the VGA_MMIO_* defines, but instead of using constants for the end of the region before that and the beginning of the region after that, the VGA_MMIO_* defines can be used. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I45c3888efb942cdd15416b730e36a9fb1ddd9697 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81391 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-03-23soc/amd/common/cpu/noncar/memmap: make local variables constFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If3424df80655a150f27c7296a5683b528873816b Reviewed-on: https://review.coreboot.org/c/coreboot/+/81390 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-03-23soc/amd/*/memmap: factor out common read_lower_soc_memmap_resourcesFelix Held
Since the code for reporting the memory map below cbmem_top is basically identical for all non-CAR AMD SoCs, factor this out into a common read_lower_soc_memmap_resources implementation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id64462b97d144ccdf78ebb051d82a4aa37f8ee98 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81389 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-29soc/amd: move common pci_domain_fill_ssdt implementation to acpi/Felix Held
Even though it has an 'amd_' prefix, the amd_pci_domain_fill_ssdt implementation doesn't contain any AMD-specific code and can also be used by other SoCs. So factor it out, move the implementation to src/acpi/acpigen_pci_root_resource_producer.c, and rename it to pci_domain_fill_ssdt. When a SoC now assigns pci_domain_fill_ssdt to its domain operation's acpi_fill_ssdt function pointer, the PCI domain resource producer information will be added to the SSDT. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7bd8568cf0b7051c74adbedfe0e416a0938ccb99 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80464 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-26util/amdfwtool: build amdfwtool only for all tools or AMD CPUsMartin Roth
When we're building non-AMD processors, don't bother building amdfwtool unless we're specifically building all of the tools like for abuild. Change-Id: I9021674a06d65a79e24020790d317ab947c505fe Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80714 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-23soc/amd/common/acp: use clrsetbits32p to avoid need for castsFelix Held
Use clrsetbits32p instead of clrsetbits32 to not need to cast the uintptr_t address to void * in the function call. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic29bf04866a7e1d5c831422f31803a724a41069b Reviewed-on: https://review.coreboot.org/c/coreboot/+/80700 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-23arch/x86/ioapic: use uintptr_t for IOAPIC base addressFelix Held
Use uintptr_t for the IOAPIC base parameter of the various IOAPIC- related functions to avoid needing type casts in the callers. This also allows dropping the VIO_APIC_VADDR define and consistently use the IO_APIC_ADDR define instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I912943e923ff092708e90138caa5e1daf269a69f Reviewed-on: https://review.coreboot.org/c/coreboot/+/80358 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-02-18soc: Add SPDX license headers to Kconfig filesMartin Roth
Change-Id: Ie7bc4f3ae00bb9601001dbb71e7c3c84fd4f759a Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80596 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Yidi Lin <yidilin@google.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-10soc/amd: Factor out gpp_clk_setup functionVarshit Pandya
gpp_clk_setup code in most AMD SoC is similar and it can moved to common code. The only thing which is SoC dependent in this function is the SoC config, hence keep it in SoC code and move everything else in new gpp_clk_setup_common function which is in soc/amd/common. Picasso and Glinda don't have pcie_gpp_dxio_update_clk_req_config fixup function so they are addressed in later patches. Change-Id: I7d7da4bfe079f07e31212247dbf3acd14daa6447 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80285 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>
2024-02-08soc/amd/common/data_fabric/domain: drop unneeded parenthesisFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I84a7b7b1b2c45b773c6f10b39e7813db3f96546e Reviewed-on: https://review.coreboot.org/c/coreboot/+/80408 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-08soc/amd/common/data_fabric/domain: don't report DRAM as MMIO producerFelix Held
In commit 30f36c35e75a ("soc/amd: rework DRAM and fixed resource reporting") the reporting of the DRAM resources was moved from the northbridge PCI device to the domain device. amd_pci_domain_fill_ssdt didn't skip those DRAM resources when generation the resource producer ranges which made Windows 10 very unhappy when it tried to evaluating the ACPI tables causing it to reboot in a loop. To fix this, add a check to also skip the resources that have the IORESOURCE_STORED flag set when generating the resource producer ranges for the PCI root. TEST=Windows 10 now successfully boots and reboots again on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7b6d3fd8c7f89aa4364de7963d745aef8d6b6f42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80407 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-08cpu/x86/64bit: Turn jumping to long mode into a macroArthur Heymans
This makes it easier to reuse, e.g. if you want to do it twice in one assembly file. Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-02-07soc/amd: drop unneeded data_fabric_set_mmio_npFelix Held
Drop the unneeded data_fabric_set_mmio_np function and the corresponding SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig symbol. In systems with only one FCH, its MMIO region will be subtractively decoded and there's no need to add a non-posted data fabric MMIO region after the FSP/openSIL has already configured the data fabric decode windows. In systems with more than one FCH, openSIL will already take care of initializing everything for the additional FCH, so we also won't need to do anything in that case. Since dropping this function also removes both data_fabric_print_mmio_conf calls before and after adding the unneeded non-posted MMIO region, replace the data_fabric_set_mmio_np call with a data_fabric_print_mmio_conf call to still print the data fabric MMIO decode regions set up by the FSP/openSIL. TEST=Mandolin still boots successfully Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I474b6e066060abb3fe5b78505521c7782cc192ee Reviewed-on: https://review.coreboot.org/c/coreboot/+/80355 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-02soc/amd: commonize PCI root IOAPIC initializationFelix Held
Make the initialization of the IOAPIC(s) in the PCI root(s) common across all AMD family 17h+ SoCs. For this the more general implementation from the Genoa code that supports multiple PC roots is moved to the common AMD code. All other family 17h+ SoCs are then adapted to use the common code. For those non-Genoa SoCs, the initialization of this second IOAPIC is moved from the northbridge device to the domain device above to match Genoa. Test=Both the FCH IOAPIC and the PCIe root IOAPIC are still initialized on Mandolin Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7c0ec6ac2f11cb11e46248cceec96c1fd2a49c16 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80286 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-02soc/amd/common/amdblocks/pci_clk_req: remove unneeded includeFelix Held
Remove the unused soc/platform_descriptors.h include and add the missing types.h include. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie0b066aa5dc657f7709f9cce734a025180bf5bfe Reviewed-on: https://review.coreboot.org/c/coreboot/+/80291 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-02-01soc/amd/common/data_fabric/domain: introduce add_pci_cfg_resourcesFelix Held
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the legacy PCI config space access is needed on all AMD SoCs, implement a common add_pci_cfg_resources function that reports both and gets called from amd_pci_domain_read_resources and don't report those in the SoC- specific code any more. The only functional change is that on Genoa now the IO ports used for the legacy PCI config space access get reserved. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-01soc/amd: rework DRAM and fixed resource reportingFelix Held
Introduce read_soc_memmap_resources which gets called by amd_pci_domain_read_resources for the first domain of the SoC to report the DRAM and PCI config space access resources to the allocator. For Genoa this allows to use amd_pci_domain_read_resources as read_resources in the genoa_pci_domain_ops instead of needing to wrap that call to be able to call add_opensil_memmap for the first domain. For the other family 17h+ SoCs the moves the reporting of the DRAM resources and the PCI config space access resources from the northbridge device to the domain device. TEST=Resources still get reported on Mandolin, but now under the domain instead of the northbridge PCI device Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib19fd94e06fa3a1d95ade7fafe22db013045a942 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80268 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-01soc/amd/*/root_complex: use unsigned long for resource indexFelix Held
Use an unsigned long as resource index type instead of an int to match the data type used for the index in the resource struct. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0f58e32a535326116460545287cc59aaf94166a0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80267 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-02-01soc/amd/common/data_fabric/domain: use unsigned long for resource indexFelix Held
Use an unsigned long as resource index type instead of an int to match the data type used for the index in the resource struct. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I60ac0e30627001698565b7256421780f9a94bf65 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80266 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-02-01soc/amd/common,genoa_poc/domain: rework check for 1st domainFelix Held
Previously the code checked if the first downstream bus of the domain was bus 0 in segment group 0 to only run certain code for the first domain. Instead check if the domain number is 0 which should make the code a bit easier to understand. TEST=add_opensil_memmap still gets called exactly once on Onyx Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id8cc0078843e5e0361a53ba897cde508cee16aad Reviewed-on: https://review.coreboot.org/c/coreboot/+/79996 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-31soc/amd/noncar/memlayout.ld: Warn about incorrect reset vectorArthur Heymans
The x86 core always starts with an IP at 0xfff0. This needs to match in the code. Change-Id: Ibced50e4348a2b46511328f9b3f3afa836feb9a5 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64951 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-31device/device.h: Rename busses for clarityArthur Heymans
This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-29device/device.h: Drop multiple linksArthur Heymans
Multiple links are unused throughout the tree and make the code more confusing as an iteration over all busses is needed to get downstream devices. This also not done consistently e.g. the allocator does not care about multiple links on busses. A better way of dealing multiple links below a device is to feature dummy devices with each their respective bus. This drops the sconfig capability to declare the same device multiple times which was previously used to declare multiple links. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Iab6fe269faef46ae77ed1ea425440cf5c7dbd49b Reviewed-on: https://review.coreboot.org/c/coreboot/+/78328 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jincheng Li <jincheng.li@intel.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2024-01-27soc/amd: move acpi_add_fsp_tables implementation to common FSP codeFelix Held
Since the acpi_add_fsp_tables implementation is identical for all SoCs, factor it out and move it to the common AMD FSP code. Also guard the acpi_add_fsp_tables call in soc_acpi_write_tables with if (CONFIG(PLATFORM_USES_FSP2_0)) to properly handle the FSP dependency. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8917a346f586e77b3b3278c73aed8cf61f3c9e6a Reviewed-on: https://review.coreboot.org/c/coreboot/+/80225 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: factor out acpi_add_fsp_tablesFelix Held
Factor out acpi_add_fsp_tables from the soc_acpi_write_tables function and move the remaining parts of the soc_acpi_write_tables function to the SoC's acpi.c. This aligns the other family 17h/19h SoCs more with Genoa and only leaves the FSP-specific code in agesa_acpi.c which will be made common in a following patch. I decided against also renaming agesa_acpi.c to acpi_fsp.c, since that would have made the diff less readable and the files get deleted in a following patch anyway. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia87ac0e77c5e673e694703b85a4bab85a34b980e Reviewed-on: https://review.coreboot.org/c/coreboot/+/80224 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-27soc/amd/picasso: factor out CRAT table generationFelix Held
Factor out the code to add the CRAT ACPI table into a separate file and add the acpi_add_crat_table function that can then be called from soc_acpi_write_tables to better isolate all code specific to the CRAT table. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4a7853748512811d3d4e124224fcd459e527522c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80223 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd: use common ACPI_SCI_IRQ definitionFelix Held
ACPI_SCI_IRQ is defined as 9 for all AMD SoCs, so move the definition to the common amdblocks/acpi.h. Since all but Stoneyridge's soc/acpi.h are now empty, delete those files too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8210c98dc4cf2c6001d5273d132053278ff7fea5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80222 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd/*/acpi: use common soc_acpi_write_tables prototypeFelix Held
Since the definition is the same for all SoCs, move it to the common amdblock/acpi.h header. Since the Stoneyridge northbridge.c file also includes this prototype, remove the static attribute of the function there. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ib9aa215f2b4ba58f43fed2c751d989f1719e0a17 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80221 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-27soc/amd/common/include/acpi: add missing device/device.h includeFelix Held
The southbridge_write_acpi_tables function uses a struct device type parameter, but device/device.h that provides the definition wasn't included. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I5245fa132ec9b84bbc483a31788bcd6fac0736e1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80220 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-27soc/amd/common/fsp: use expected types for add_agesa_fsp_acpi_tableFelix Held
add_agesa_fsp_acpi_table should use the same type for the 'current' parameter and return value as the calling soc_acpi_write_tables does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie9f770b1d847ea28e4dbd96298a723d794b91a02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80219 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-26soc/amd: factor out common acpi_add_ivrs_table implementationFelix Held
Instead of open-coding this functionality in all AMD SoCs, factor it out into a common implementation. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idb65c398b747e70ec67107e0a1d4bd6551501347 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80208 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-01-25soc/amd/common: Fix typoVarshit Pandya
Change-Id: Ida6e87908ae6996529057c8df12dbe046ee54b98 Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80161 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-24soc/amd/*: Rename Makefiles from .inc to .mkMartin Roth
The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ie449267fe4fdd75110f577e1b9f748cd06140950 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80071 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-01-20soc/amd/*/chip: factor out FSP-S callFelix Held
Move the call into the FSP code to a file in the common AMD FSP code to isolate the FSP-specific parts of the code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic8236db7ac80275a65020b7e7a9acce8314c831c Reviewed-on: https://review.coreboot.org/c/coreboot/+/80084 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-20soc/amd: factor out non-CAR romstage to common codeFelix Held
Since the romstage code is very similar between all AMD non-CAR SoCs, factor out a common romstage implementation. All SoCs that select SOC_AMD_COMMON_BLOCK_PM_CHIPSET_STATE_SAVE call fill_chipset_state, so this Kconfig option can be used to determine whether to make that call. In the FSP case, amd_fsp_early_init gets called, while in the case of an implementation that doesn't rely on an FSP to do the initialization, cbmem_initialize_empty gets called to set up CBMEM which otherwise would be done inside the FSP driver code. Since only some SoCs call fch_disable_legacy_dma_io again in romstage right after amd_fsp_early_init, introduce the new SOC_AMD_COMMON_ROMSTAGE_LEGACY_DMA_FIXUP Kconfig option, so that the SoCs can specify if this call is needed or not. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4a0695714ba08b13a58b12a490da50cb7f5a1ca9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80083 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-01-20soc/amd/*/romstage: factor out FSP-M callFelix Held
Move the call into the FSP code to a file in the common AMD FSP code to isolate the FSP-specific parts of the code and a preparation to make the romstage of all non-CAR AMD SoCs common. Without isolating the call into the FSP-M code, building the common romstage would fail for genoa_poc due to fsp/api.h not being in the include path. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I30cf1bee2ec1a507dc8e61eaf44067663e2505ae Reviewed-on: https://review.coreboot.org/c/coreboot/+/80002 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-17tree: More use accessor functions for struct region fieldsNico Huber
Always use the high-level API region_offset() and region_sz() functions. This excludes the internal `region.c` code as well as unit tests. FIT payload support was also skipped, as it seems it never tried to use the API and would need a bigger overhaul. Change-Id: I18f1e37a06783aecde9024c15876b67bfeed70ee Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79955 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-01-16device: Add support for multiple PCI segment groupsFelix Held
Add initial support for multiple PCI segment groups. Instead of modifying secondary in the bus struct introduce a new segment_group struct element and keep existing common code. Since all platforms currently only use 1 segment this is not a functional change. On platforms that support more than 1 segment the segment has to be set when creating the PCI domain. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ied3313c41896362dd989ee2ab1b1bcdced840aa8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79927 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-01-13soc/amd/common/data_fabric/domain: write _SEG method in SSDTFelix Held
As a preparation for the multi PCI segment group support, use acpigen_write_BBN to generate the _SEG method that returns the segment group number of the PCI root. Until the multi PCI segment group support is enabled in coreboot, it will always return 0. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I2a812dcc564c5319385e9ad482d29b2984a71b8a Reviewed-on: https://review.coreboot.org/c/coreboot/+/79924 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-11soc/amd: move IOMMU_IOAPIC_IDX define to amdblocks/ioapic.hFelix Held
Move the IOMMU_IOAPIC_IDX define from amdblocks/data_fabric.h to amdblocks/ioapic.h which is both a more logical place for it to be and this is also a preparation to use the common AMD MADT code for the Stoneyridge SoC. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iaa20e802cf5ed93f0d05842abb1aea0d43b1cac4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79862 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 19:04:35 +0000