summaryrefslogtreecommitdiff
path: root/src/soc/amd
AgeCommit message (Collapse)Author
2024-11-07soc/amd/common/psp/rpmc: bring debug output in line with fmap sectionFelix Held
Call the PSP RPMC NVRAM 'PSP RPMC NVRAM' instead of 'PSP NVRAM' in the debug console output to not be misleading, since the RPMC feature uses the 'PSP_RPMC_NVRAM' fmap section and not the 'PSP_NVRAM' fmap section. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie89dfcfe4b8780f422c222477bb627e03bd3662d Reviewed-on: https://review.coreboot.org/c/coreboot/+/85007 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-11-05soc/amd/common/psp_smi_flash: refactor SPI controller busy checkFelix Held
Since the functions that call 'spi_controller_available' end up checking if the SPI controller is busy, refactor the function into 'spi_controller_busy' to simplify the logic on the caller's side. Also move printing of the notice that the SPI controller is busy to 'spi_controller_busy' to not have that duplicated in caller. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibc21ab6eacf07c4adffdb4658142c2f9dfcbf2a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84920 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-11-05soc/amd/common/psp_smi_flash: factor out get_flash_deviceFelix Held
Since the RPMC-related functions will only need the spi_flash struct, but not the region_device struct of the store region corresponding to the 'target_nv_id', factor out 'get_flash_device' from 'find_psp_spi_flash_device_region'. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia99d3454df2c1c4182c193da7de1bbb4eef18313 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84905 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ana Carolina Cabral
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-10-03soc/amd/glinda/.../iomap.h: Update for glindaMaximilian Brune
Remove TODO after checking the addresses are still valid. source: PPR 57254 Rev 1.59 Table "Address Space Mapping under APB BUS" Change-Id: If282ce5687b8a2bdae03ebfc5a37fe5b8b17647a Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84380 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-10-03soc/amd/glinda/include/smu.h: Update mailbox register addressesAvinash Munduru
Signed-off-by: Avinash Munduru <AvinashMunduru@amd.com> Change-Id: I427186aa9f0fb0650b2ab8d6171a51a33edf2778 Tested-by: Avinash Munduru <Avinash.Munduru@amd.com> Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84384 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-10-03soc/amd/.../amd_pci_int_defs.h: Update according to datasheetMaximilian Brune
HPET and MISC1/2 and registers are used interchangeably in the datasheets. Add an alias to emphasise that they refer to the same. source: PPR #57396 Rev 3.10 Table "ValidValuesTable: PCI interrupt index list" PPR #57254 Rev 1.59 Table "ValidValuesTable: PCI interrupt index list" PPR #57396 Rev 3.10 FCH::IO::IntrMisc1Map and FCH::IO::IntrMisc2Map PPR #57254 Rev 1.59 FCH::IO::IntrMisc1Map and FCH::IO::IntrMisc2Map Change-Id: I64f685e507e1cd5ee90e1b18526b9d59ed4c1b34 Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84574 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-10-03soc/amd/*: Explicitly include static.h for config_of_socNicholas Chin
As per commit 865173153760 ("sconfig: Move config_of_soc from device.h to static.h"), sources that require access to the devicetree should directly include static.h so that it can be removed from device.h, eliminating unnecessary dependencies on static.h for files that only need the types and function declarations in device.h. Change-Id: I9db5d80ca0a75ccff3b8e24db0ccbd6b36c84dcb Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84587 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2024-09-30soc/amd/glinda: Update pci int defsMaximilian Brune
Update IRQs according to datasheet/PPR. source: PPR #57254 Rev 1.59 Table 137 Change-Id: I843e5e2b01301eb02cb5be347e122cffbe76d80d Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84375 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-09-30soc/amd/glinda: Update gpp bridge naming schemeMaximilian Brune
This patch updates the naming scheme used for the GPP bridges. The naming scheme now matches what we also have on phoenix. Change-Id: I9f740d75a3561dba2ed65acb16bb4259f632307d Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84378 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-09-30soc/amd/glinda: Update SCI mappingMaximilian Brune
source: PPR #57254 Rev 1.71 Change-Id: I5eaed888109b89c25bcf0ba91abefa7c36c1851b Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84381 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-09-30soc/amd/glinda/include/soc/smi.h: Update for glindaMaximilian Brune
It aligns the names in the datasheet with the one in the code. It also removes and adds some. Resource: Document 57254 Chapter 15.3.5 TODO it may very well be that I don't have the full truth, because most of these register just have a different name and some of these names like ESPI seem more recent that for example LPC. Change-Id: Iad848ff400ef80777d0cbb2b582b9b5fa8bf11f3 Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84383 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-09-30soc/amd/glinda: Remove non-exisiting I2C definitionsMaximilian Brune
Glinda doesn't contain I2C4 and I2C5 like Mendocino it was copied from. Remove their definitions. Reference: Document 57254 Change-Id: I676e76aa2309d9ab82d63b48a2dec3c100241131 Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84382 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-09-26soc/amd/glinda/chipset.cb: Add missing devicesMaximilian Brune
Source: Document 57254 Change-Id: I9675d45eba257e52d9a870a4cc153b925267f840 Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84377 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-09-26soc/amd/glinda/chipset.cb: Update for glindaSatya SreenivasL
This also updates the mainboards depending on it. Change-Id: I1138f27bfd47f6fa70a0c2afcc65a5553a609d57 Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84376 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-09-25vc/amd/opensil: Move openSIL interface declarations to common headerNicolas Kochlowski
The declarations describing interface functions between SoCs and openSIL glue code are common for the stub and Genoa POC, and likely with future SoC openSIL implementations. Therefore, move these out of SoC-specific header files and into vc/amd/opensil/opensil.h. This change facilitates swapping out the stub for the actual openSIL glue code. Change-Id: Icc8783ddb868f9f0c4cd357245604313eadfe531 Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84428 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-09-09soc/amd/cezanne: Add an option to enable A/B recovery schemeZheng Bao
Extracted from NDA spec #56995: "The A/B recovery scheme formally separates the SPI flash space into different partitions; a primary, “A” and secondary, “B”, which hold the same set of system firmware. Under this scheme, the partitions A and B can hold identical contents initially, but each partition can be updated individually. Normally the system boots from partition A, but if the A partition is found to be corrupted, the system will switch to partition B and boot. The OEM BIOS can then choose to continue the boot from partition B, or repair partition A using contents from partition B." The Cezanne platform supports both A/B recovery and no recovery method. It needs this flag passed to amdfwtool to enable the A/B recovery layout. Change-Id: Id1c8028faee9c544628d65fd77be2a378ed7eab6 Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/84195 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-08-27soc/amd/stoneyridge/smihandler: add PSP SMI handlerFelix Held
Now that the PSP SMI handler for flash access is also implemented for the PSP generation 1, the PSP SMI handler can be added to the Stoneyridge code too. The actual PSP SMI handler code will only be added to the build when SOC_AMD_COMMON_BLOCK_PSP_SMI is selected which isn't the default case, so this patch doesn't change the current behavior unless that option is also selected. This SMI handler mainly added for completeness since the PSP firmware blobs released for Stoneyridge are probably lacking the corresponding PSP-side code to send the PSP SMI to the host. At least if I remember correctly the PSP bootloader release for Stoneyridge has the ability to load the secure OS removed and since the secure OS is the runtime component, some part of that is probably what's sending those SMIs to the host. If there are some other PSP bootloader builds that support loading the secure OS, this patch might still be useful for those. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I78944e2de86bc1e8e277d22a7a8da517622f49a1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/84077 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-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-09soc/amd/*: pass PSP RPMC NVRAM base and size to amdfwtoolFelix Held
Pass the PSP NVRAM base and size to amdfwtool for all SoCs except Genoa and Stoneyridge which don't use/support this. If a mainboard has an section named 'PSP_RPMC_NVRAM' in its FMAP file, the start and length of it in the flash will be passed to amdfwtool which then adds the base and length to the corresponding type 0x54 PSP directory table entry. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id9f8a7eec68a5222be63e46173132f1c4a461b4f Reviewed-on: https://review.coreboot.org/c/coreboot/+/83815 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-08soc/amd/*: pass PSP NVRAM base and size to amdfwtoolFelix Held
Pass the PSP NVRAM base and size to amdfwtool for all SoCs except Genoa which doesn't use/support this. This was previously only implemented for Picasso, but not for the SoCs that support this, so add the support to those other SoCs as well. If a mainboard has an section named 'PSP_NVRAM' in its FMAP file, the start and length of it in the flash will be passed to amdfwtool which then adds the base and length to the corresponding type 0x04 PSP directory table entry. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I785ede8eb0df2473a4390b2c305add20f38d7ede Reviewed-on: https://review.coreboot.org/c/coreboot/+/83814 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-08-08soc/amd/picasso/Makefile: move PSP_NVRAM_[BASE,SIZE]Felix Held
Move PSP_NVRAM_BASE and PSP_NVRAM_SIZE from the BIOS directory table items to the PSP Directory Table items, since the corresponding region will be referenced by the PSP directory table and not the BIOS directory table. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iff7568ea05c701ecd346cc7590cf93b091ff31a2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83813 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-08-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: add SoC-specific root_complex.c to SMMFelix Held
The PSP code introduced in a following patch needs both SoC-specific functions get_iohc_info and get_iohc_non_pci_mmio_regs to also be available in SMM, so add those compilation units to the corresponding target. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4e32084b45f07131c80b642bc73d865fc57688a8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83445 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2024-07-25soc/amd/*/root_complex: introduce and use domain_iohc_info structFelix Held
Instead of implementing the functions get_iohc_misc_smn_base and get_iohc_fabric_id in the SoC code, move those functions to the common AMD code, and implement get_iohc_info in the SoC code that returns a pointer to and the size of a SoC-specific array of domain_iohc_info structs that contains the info needed by the common code instead. This allows to iterate over the domain_iohc_info structs which will be used in a later patch to find the PSP MMIO base address in both ramstage and smm. TEST=Mandolin still boots and all non-PCI MIO resources are still reported to the resource allocator Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifce3d2b540d14ba3cba36f7cbf248fb7c63483fe Reviewed-on: https://review.coreboot.org/c/coreboot/+/83443 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2024-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-15soc/amd/phoenix/include/gpio: update GPIO HID to AMDI0030Felix Held
The UEFI reference firmware uses AMDI0030 instead of AMD0030 as HID for the GPIO controller. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4a6fa1acdca0ee5b6e1358b6279b7c501d3dfd16 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83439 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-07-15soc/amd/glinda/include/gpio: update GPIO HID to AMDI0030Felix Held
The UEFI reference firmware uses AMDI0030 instead of AMD0030 as HID for the GPIO controller. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8dd48d7d9cf3f6d75853bb825e5ddc32bba430b8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83438 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-07-15soc/amd/glinda/include/gpio: update to match hardwareFelix Held
The table "IOMUX Functional Table" in PPR #57254 rev. 1.60 was used as a reference. This should fix the ESPI_ALERT_D1 IOMUX setting for the boards using the Glinda SoC which previously didn't match the hardware. Compared to Phoenix, Glinda has two more chip select outputs for the SPI2 controller and an additional ZST_STUTTER_RAIL IOMUX function. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id9adfbe0c7aee90d6fe990f239d82a1d013e7f5f Reviewed-on: https://review.coreboot.org/c/coreboot/+/83437 Reviewed-by: Anand Vaikar <a.vaikar2021@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2024-07-11soc/amd/phoenix: Fix APOB NV size/base for non-vboot buildsMatt DeVillier
The APOB NV size/base are embedded into the amdfw binary and read by the PSP. These need to be synchronized with the FMAP region used by coreboot to store the APOB data. soc_update_apob_cache() will only use RECOVERY_MRC_CACHE if supported and if vboot is enabled, so the NV base passed to the PSP needs to reflect that as well. This fixes the issue of RAM training running on every boot on non-vboot builds for Myst boards. TEST=untested, but same change as made for Mendocino Change-Id: Ib4a78a39badf0a067e22eebe5869e5ea51723f35 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83401 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>
2024-07-11soc/amd/mendocino: Fix APOB NV size/base for non-vboot buildsMatt DeVillier
The APOB NV size/base are embedded into the amdfw binary and read by the PSP. These need to be synchronized with the FMAP region used by coreboot to store the APOB data. soc_update_apob_cache() will only use RECOVERY_MRC_CACHE if supported and if vboot is enabled, so the NV base passed to the PSP needs to reflect that as well. This fixes the issue of RAM training running on every boot on non-vboot builds for Skyrim boards. TEST=build/boot Skyrim (Frostflow), verify RAM training only run on first boot after flashing. Change-Id: I9be1699d675331b46ee9c42570700c2b72588025 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83400 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
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-06-18soc/amd/cezanne: Add AMD Renoir SOC supportAnand Vaikar
Add AMD SOC Family 17h Renoir CPUIDs per PPR doc #55922 Renoir is similar to Cezanne with only differences in CCX count. Cezanne has one Zen3 CCX with 8 cores per CCX compared to the two Zen2 CCX with 4 cores per CCX. Hence, coreboot side Cezanne SOC code should be mostly compatible with Renoir and can be leveraged. Change-Id: I6b43eb782527351c79b835d094a5b61103cd6642 Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83099 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-06-11soc/amd/genoa_poc: Prefer include <soc/gpio.h> via <gpio.h>Elyes Haouas
Change-Id: I0e5fba7db7d97835001934cb140f4c76bdc46d3e Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82889 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-05-29tree: Remove unused <stddef.h>Elyes Haouas
Change-Id: I7d7ad562eeff7247b7377b6570d489faee0aeda0 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82669 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yidi Lin <yidilin@google.com>
2024-05-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-23device: drop unnecessary CHECK_REV_IN_OPROM_NAME optionFelix Held
The CHECK_REV_IN_OPROM_NAME Kconfig option was introduced to solve the problem of the PCI VID/DID combination of the Picasso iGPU not being sufficient information to know which VGA BIOS file to run, so a new function that additionally checks the PCI revision of that device was introduced. Later it turned out that there might be a case where even that isn't sufficient, so the soc_is_raven2() function is used in the remap function to always use the correct VBIOS file. Picasso is the only SoC that selected the CHECK_REV_IN_OPROM_NAME Kconfig option, so all other SoCs are unaffected by this change. Now that we use the VBIOS images with only the PCI VID and DID in the CBFS file name for Picasso, SeaBIOS will find the VBIOS with the same ID as the iGPU in CBFS and we don't need the workaround to add a third VBIOS image via VGA_BIOS_DGPU_* that has the name that SeaBIOS expects. This will result in SeaBIOS now running the VBIOS that has the same PCI VID/DID as the hardware which will be the wrong one in the RV2 silicon showing the PCO silicon PCI VID/DID, but that was also the case with the VGA_BIOS_DGPU_* workaround where the board's Kconfig just selected one of the two possible images during build time and hoped that it was the correct one for that actual hardware. The only board where this patch might cause a regression compared to the old behavior is the AMD Cereme reference board with Pollock APU, but I'm not even sure if any coreboot developer still has one of those boards, so I'm willing to accept that. To properly solve the problem with SeaBIOS using the correct VBIOS file in all cases, we'd need to generate that info during coreboot runtime and somehow pass it to SeaBIOS, but that's out of scope for this patch. TEST=On Mandolin with PCO silicon, the display output in both SeaBIOS and Ubuntu still works. Booting Windows 10 via the pre-built EDK2 payload that I'm using also resulted in the display output working. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia6de533c536044698d85404427719b8f534870fa Reviewed-on: https://review.coreboot.org/c/coreboot/+/82598 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-23soc/amd/phoenix/chip_opensil.h: add missing include guardsFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iba17d44772333ed59e3fdde1443a1862bae8e32f Reviewed-on: https://review.coreboot.org/c/coreboot/+/82606 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2024-05-22soc/amd/phoenix/chip.h: add USB PHY configuration for openSILFelix Held
Add the USB PHY configuration structs for the openSIL case, so that those can be configured in the devicetree like in the FSP case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ied25e90859c4b1bc9b876bed3f3c46358ca36d32 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82584 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-22soc/amd/phoenix/chip.h: add DDI configuration for openSILFelix Held
In the FSP case, the DDI descriptors aren't part of the devicetree and are instead retrieved in romstage by calling the mainboard's mainboard_get_dxio_ddi_descriptors function which allows updating the descriptors during romstage where the devicetree is static. In the openSIL case, the DDI configuration is first needed in ramstage, so we can put this info into the devicetree and update it if needed in ramstage. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3de12ff6af42e38751a3016efa313613677fa87a Reviewed-on: https://review.coreboot.org/c/coreboot/+/82580 Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-05-22soc/amd/phoenix/chipset_*.cb: remove TODOFelix Held
Remove the TODO to update the chipset devicetree for Phoenix, since this has already been done. When re-checking the chipset devicetree, I found conflicting information about the existence of the PCI bridge to an external PCIe port on bus 0 device 1 function 5, but after looking into this, I'm reasonably certain that it either doesn't exist or at least wouldn't be usable, so I won't add that one to the chipset devicetree. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8f0e1540ed45408e86186253d3982a7ba0065ac6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82578 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>
2024-05-15mb/amd/birman/devicetree_phoenix_opensil: add stub MPIO chipsFelix Held
Add the stub MPIO chips that contain the PCIe engine configuration for the external PCIe interfaces to the devicetree. Birman's port_descriptors_phoenix.c was used as a reference. The static configuration in the devicetree assumes that the default WLAN0_WWAN0 is selected; for the other cases we'll still need to fix up things accordingly in the mutable devicetree. The WLAN01 and WWAN01 cases still need to be handled in a follow-up patch. Since openSIL currently doesn't use the info from the gpio_group struct element, but deasserts both PCIe reset pins GPIO 26 and 27, the gpio_group isn't specified in the chip configuration in the devicetree. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Icabe60322d46c1195284dd77ec39f9d143e3d2cb Reviewed-on: https://review.coreboot.org/c/coreboot/+/81101 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
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-05-12vc/amd/opensil: introduce common mpio/chip.h header fileFelix Held
The chip drivers in the devicetree use the path where the corresponding chip.h file resides both to include this chip.h file in the static.c generated by util/sconfig from the devicetree and also for the names of the chip config and chip ops struct. To be able to build a SoC using either the MPIO chip driver from the openSIL stub or from the actual openSIL glue code without needing different devicetree files for the different cases, introduce a common MPIO chip.h file that then includes the correct MPIO header file. The chip config and ops structures also need to be renamed to take this change into account. Thanks to Matt for pointing out how to make the path to the actual MPIO chip.h file configurable via a Kconfig setting. This allows overriding this path from site-local without the need to have any reference to site-local in the upstream code. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iead97d1727569ec0d23a2b9c4fd96daff4bebcf6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82262 Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-06soc/amd/phoenix/include/platform_descriptor: remove TODOFelix Held
There's nothing in this header file that needs to be updated for the Phoenix SoC, so remove the 'Update for Phoenix' TODO. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9d7b5e8d8d6c8c22c2fae8e89d073481d21d8bdc Reviewed-on: https://review.coreboot.org/c/coreboot/+/82150 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-26soc/amd/genoa_poc/chip.h: remove empty newline before '}'Felix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I7f18f2d754f24bfcc9cbf95a98fa6fe40aaf3b02 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82091 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
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-22soc/amd/phoenix/acpi: call acpi_add_opensil_tables in openSIL caseFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifdfdbf193bd96a6dda72a2f23d51925fd369aa01 Reviewed-on: https://review.coreboot.org/c/coreboot/+/82013 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-19soc/amd/glinda: Add support for A0 and B0 steppingsAnand Vaikar
Update the A0 and B0 stepping IDs in CPU table per the PPR document 57254 Rev 1.56 and 1.69 Change-Id: I0072f25f981ac7d5df2522594c8788bfabcbf24c Signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81887 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-04-15soc/amd/picasso: Mark eMMC as non-removable for Windows 10/11 installCoolStar
Mark eMMC as non-removable to allow Windows 10/11 to install now that edk2 can boot from it. Change-Id: If0e14106521f99cb97d1bf421f4d82d1234c2f15 Signed-off-by: CoolStar <coolstarorganization@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2024-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 <elog.h>Elyes Haouas
Change-Id: I40e2e5a786499abbe2fce63d6e0f1ac1e780ab51 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81816 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Eric Lai <ericllai@google.com>
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-04-07soc/amd/genoa_poc: Allow using UART with DEBUG_SMI=yBenjamin Doron
When DEBUG_SMI is selected, common code may use these helpers to handle addressing and initialising the SoC-specific UART. Therefore, add uart.c to be compiled into SMM. Change-Id: If7c6f2346d5f9ffb371d51d1de6f0b695acedf10 Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81072 Reviewed-by: Marvin Drees <marvin.drees@9elements.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2024-04-06lib: Refactor bmp_load_logo() implementationSubrata Banik
This refactoring ensures bmp_load_logo() takes logo_size as an argument, returning a valid logo_ptr only if logo_size is non-zero. This prevents potential errors from mismatched size assumption. BUG=b:242829490 TEST=google/rex0 builds successfully. Change-Id: I14bc54670a67980ec93bc366b274832d1f959e50 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81618 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Dinesh Gehlot <digehlot@google.com> Reviewed-by: Julius Werner <jwerner@chromium.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/Kconfig: Mark 64bit support as stableArthur Heymans
With SMM holding page tables itself, we can consider SMM support stable and safe enough for general use. Also update the respective documentation. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 01:56:35 +0000