summaryrefslogtreecommitdiff
path: root/src/soc/amd/cezanne/cpu.c
AgeCommit message (Collapse)Author
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>
2023-09-21soc/amd/*/cpu: factor out common noncar mp_init_cpusFelix Held
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation, factor it out and move it to a common location. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-06-23commonlib/console/post_code.h: Change post code prefix to POSTCODElilacious
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \ src/commonlib/include/commonlib/console/post_codes.h; myArray=`grep -e "^#define POSTCODE_" \ src/commonlib/include/commonlib/console/post_codes.h | \ grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`; for str in ${myArray[@]}; do splitstr=`echo $str | cut -d '_' -f2-` grep -r POST_$splitstr src | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; grep -r "POST_$splitstr" util/cbfstool | \ cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g"; done Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8 Signed-off-by: lilacious <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com>
2023-06-02soc/amd/common/block/cpu: Refactor ucode allocationGrzegorz Bernacki
Move microcode load/unload to pre_mp_init and post_mp_init callbacks. It allows to make sure that ucode is freed only if all APs updated microcode. BUG=b:278264488 TEST=Build and run with additional debug prints added to confirm that data are correctly unmapped Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a Signed-off-by: Grzegorz Bernacki <bernacki@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-02-09arch/x86/include/cpu: introduce CPU_TABLE_END CPU table terminatorFelix Held
Instead of having a magic entry in the CPU device ID table list to tell find_cpu_driver that it has reached the end of the list, introduce and use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID instead of the 0 in the CPU_TABLE_END definition. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08soc/amd/cezanne: use CPUID_ALL_STEPPINGS_MASK to support all steppingsFelix Held
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Cezanne steppings. This adds support for Cezanne stepping A1 and possible future steppings. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idb020052685d9369109f391797fdd8f8790a91d1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72849 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-08arch/x86/cpu: introduce and use device_match_maskFelix Held
Instead of always doing exact matches between the CPUID read in identify_cpu and the device entries of the CPU device ID table, offer the possibility to use a bit mask in the CPUID matching. This allows covering all steppings of a CPU family/model with one entry and avoids that case of a missing new stepping causing the CPUs not being properly initialized. Some of the CPU device ID tables can now be deduplicated using the CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0540b514ca42591c0d3468307a82b5612585f614 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-12-20src/soc: Remove unneeded <assert.h>Elyes Haouas
As _Static_assert() is a compiler built-in, <assert.h> is not needed. Change-Id: I578b4bf286538d0606569d19ec760a1846c8145b Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70904 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2022-09-14cpu/amd/smm: Move MP & SMM init in a common placeArthur Heymans
Change-Id: I7c457ab69581f8c29f2d79c054ca3bc7e58a896e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64870 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-08-25soc/amd: rework SPI flash MMIO region handlingFelix Held
Only 16 MByte of the SPI flash can be mapped right below the 4 GB boundary. In case of a larger SPI flash size, still only the 16 MByte region starting at 0xff000000 can be configured as WRPROT and be reserved for the MMIO mapped SPI flash region. The next 16 MByte MMIO region starting at address 0xfe000000 contain for example the LAPIC MMIO region, the ACPIMMIO region and the UART/I2C controller MMIO regions which shouldn't be configured as WRPROT. Reserving this region for the MMIO mapped SPI flash would also result in an overlap with the MMIO resources mentioned above. In the case of a smaller SPI flash, reserving the full 16 MByte flash MMIO region makes sure that the resource allocator won't try to put anything else in the lower parts of the 16 MByte SPI mapping region. To avoid the issues described above, always reserve/cache the maximum amount of 16 MBytes of flash that can be mapped below 4 GB. TEST=On boards with 16 MByte SPI flash chips, the resulting image of a timeless build doesn't change with this patch. Verified this on Chausie (Mendocino), Majolica (Cezanne), Cereme (Picasso) and Google/Careena (Stoneyridge). On Mandolin (Picasso) with an 8 MByte flash, the resulting image of a timeless build is different, but neither the coreboot console output nor the Linux dmesg output shows any errors that might be related to this change. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie12bd48e48e267a84dc494f67e8e0c7a4a01a320 Reviewed-on: https://review.coreboot.org/c/coreboot/+/66700 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-07-14soc/amd/*: Move apm call out of MP init codeArthur Heymans
This makes it easier to have common code for MP init on AMD systems. Change-Id: Icb6808edf96a17ec0b3073ba2486b3345a4a66ea Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64867 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-06-20soc/amd/*: Make mtrr decision based on syscfgArthur Heymans
The syscfg has to option to automatically mark the range between 4G and TOM2, which contains DRAM, as WB. Making it generally not necessary to allocate MTRRs for memory above 4G if no PCI BARs are placed up there. Change-Id: Ifbacae28e272ab2f39f268ad034354a9c590d035 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64868 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2022-03-25soc/amd/cezanne/cpu.c: Skip SMMINFO init in S3 resumeFred Reitberger
SMMINFO is already set up in S5, so it should be skipped in S3 resume BUG=b:194990818 TEST=Build guybrush Change-Id: I30ee6d7006ddac4dbdae9825bd4fa6eac7fd48cb Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/63025 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-02-05cpu/x86/lapic: Move LAPIC configuration to MP initKyösti Mälkki
Implementation for setup_lapic() did two things -- call enable_lapic() and virtual_wire_mode_init(). In PARALLEL_MP case enable_lapic() was redundant as it was already executed prior to initialize_cpu() call. For the !PARALLEL_MP case enable_lapic() is added to AP CPUs. Change-Id: I5caf94315776a499e9cf8f007251b61f51292dc5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58387 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2021-11-03soc/amd/*/cpu: handle mp_init_with_smm failureFelix Held
When the mp_init_with_smm call returns a failure, coreboot can't just continue with the initialization and boot process due to the system being in a bad state. Ignoring the failure here would just cause the boot process failing elsewhere where it may not be obvious that the failed multi-processor initialization step was the root cause of that. I'm not 100% sure if calling do_cold_reset or calling die_with_post_code is the better option here. Calling do_cold_reset likely here would likely result in a boot-failure loop, so I call die_with_post_code here. BUG=b:193809448 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ifeadffb3bae749c4bbd7ad2f3f395201e67d9e28 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58859 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-22cpu/x86/mp_init: move printing of failure message into mp_init_with_smmFelix Held
Each CPU/SoC checks the return value of the mp_init_with_smm and prints the same error message if it wasn't successful, so move this check and printk to mp_init_with_smm. For this the original mp_init_with_smm function gets renamed to do_mp_init_with_smm and a new mp_init_with_smm function is created which then calls do_mp_init_with_smm, prints the error if it didn't return CB_SUCCESS and passes the return value of do_mp_init_with_smm to its caller. Since no CPU/SoC code handles a mp_init_with_smm failure apart from printing a message, also add a comment at the mp_init_with_smm call sites that the code might want to handle a failure. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I181602723c204f3e43eb43302921adf7a88c81ed Reviewed-on: https://review.coreboot.org/c/coreboot/+/58498 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-10-21cpu/x86/mp_init: use cb_err as mp_init_with_smm return typeFelix Held
Using cb_err as return type clarifies the meaning of the different return values. This patch also adds the types.h include that provides the definition of the cb_err enum and checks the return value of mp_init_with_smm against the enum values instead of either checking if it's non-zero or less than zero to handle the error case. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ibcd4a9a63cc87fe176ba885ced0f00832587d492 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58491 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-07-14soc/amd: move check_mca prototype to soc/amd/common/blocks/includeFelix Held
Change-Id: Ia489dbfba59c334cf29f96a4000cef73b9b797d4 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56279 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-14soc/amd/cezanne: add basic MCA supportFelix Held
Currently the MCA support for Cezanne only clears the MCA status registers. The MCA error handling and BERT table generation will be added in subsequent patches. Change-Id: Ib9b5174186c28c8c82f57ffd8936c8dad4e63c5b Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56262 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Raul Rangel <rrangel@chromium.org>
2021-06-11soc/amd/cezanne: remove warm reset flag codeFelix Held
The warm reset bit in the NCP_ERR register doesn't behave as the PPR [1] suggested; no matter if something was written to the register, the NCP_WARM_BOOT bit never got set and the NCP_ERR register in I/O-space always reads back as 0x7f. [1] checked with PPR for AMD Family 19h Model 51h A1 (CZN) #56569 Rev 3.01 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I569372db9f36ec7bbc741f4d7312ade312daa70b Reviewed-on: https://review.coreboot.org/c/coreboot/+/55101 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-04-23soc/amd/cezanne/cpu: make sure that MAX_CPUS isn't overriddenFelix Held
Trying to limit the number of available cores by setting the MAX_CPUS Kconfig option to a lower value than the SoC's default might result in cores being enabled in the FSP-S, but not fully initialized in coreboot which will cause some malfunction. Add a static assert to make sure that this option isn't changed from the default. To limit the maximum number of cores, use the downcore_mode and disable_smt devicetree settings instead. BUG=b:184162768 TEST=Build fails if MAX_CPUS isn't the expected default. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Idd6aa1d99128b17218a8e910c33415218a58578f Reviewed-on: https://review.coreboot.org/c/coreboot/+/52606 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-11soc/amd: move warm reset flag function prototypes to common codeFelix Held
Even though the implementation is different on Stoneyridge compared to Picasso and Cezanne, the function prototypes are identical, so move them to the AMD SoC common reset header file. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8d3a3a9ea568ea18658c49612efabdbe36d5f957 Reviewed-on: https://review.coreboot.org/c/coreboot/+/51395 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2021-02-19soc/amd/cezanne: add MP init and SMM initializationFelix Held
Change-Id: I38d52394b5f6ffb837fa753fc9e82c0450c6aae3 Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50505 Reviewed-by: Raul Rangel <rrangel@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-14soc/amd/cezanne: Enable uCode updateRaul E Rangel
TEST=Boot majolica and see microcode update CBFS: Found 'cpu_microcode_blob.bin' @0x6900 size 0x15c0 in mcache @0xcf7fe9d8 microcode: patch id to apply = 0x0a50000b microcode: being updated to patch id = 0x0a50000b succeeded Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: If50b1d8b3ebf4b3e6f8a9dd3ab96073e0cb92424 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50616 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2021-02-11soc/amd/cezanne: add empty mp_init_cpusFelix Held
Change-Id: I845a7e2cfea58ca08cd2a6f0d884dbbbe1a7bdef Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/50483 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-11soc/amd/cezanne/cpu: add basic zen_2_3_init functionalityFelix Held
The MCA MSRs aren't getting cleared and no microcode update gets applied for now. Both will be added later. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I38ce5d11787ffefdd0183c5540ae2683158cbee8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50482 Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-02-09soc/amd/cezanne: add empty CPU driverFelix Held
Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I54299cadae4cb562e04a16c3b8e051c9c454db79 Reviewed-on: https://review.coreboot.org/c/coreboot/+/50404 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 20:04:46 +0000