summaryrefslogtreecommitdiffstats
path: root/src/soc/intel/xeon_sp/skx
Commit message (Collapse)AuthorAgeFilesLines
* soc/intel/xeon_sp/uncore: Read VtdBarPatrick Rudolph2024-02-231-0/+1
| | | | | | | | | | | | | | Read the VtdBar and add it to the resources of the host bridge PCI device. The BAR is already marked as PciResourceMem32 in the parent PCI domain. This allows easy probing for VTD devices with enabled VtdBars in the next commit, without the need to look up the stack HOB. Change-Id: Id579a94e653473f3dd0dccea6e33dc64f792d028 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80550 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
* soc/intel/xeon_sp/smihandler: Lock SMM_FEATURE_CONTROL on all socketsPatrick Rudolph2024-02-063-15/+2
| | | | | | | | | | | | | | | | | Remove hardcoded B:D:F numbers for the first socket and pass the PCI addresses to be locked within SMM by using the smm_pci_resource_store. This allows to lock down SMM on all sockets without knowing the actual bus topology or PCI segment group at compile time where the UBOX devices reside on. Tested: SMM is locked on all 4 sockets instead of just one. Change-Id: Ica694911384005681662d3d7bed354a60bf08911 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80247 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp: Attach UBOX stacksPatrick Rudolph2024-01-311-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | Attach UBOX stacks on newer generation Xeon-SP. In order to use PCI drivers for UBOX devices, locating UBOX devices by vendor and device IDs and replacing device access by specifying S:B:D:F numbers, add a PCI domain for the UBOX stacks and let the PCI enumerator index all devices. Since there are no PCI BARs on the UBOX bus the PCI locator doesn't have to assign resources on those buses. Once all PCI devices on the UBOX stack can be located without knowing their UBOX bus number and PCI segment the Xeon-SP code can fully enable the multi PCI segment group support. Test: ibm/sbp1 (4S) is able to find all PCU devices by PCI ID. Change-Id: I8f9d52dd117364a42de1c73d39cc86dafeaf2678 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80091 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* device/device.h: Rename busses for clarityArthur Heymans2024-01-311-1/+1
| | | | | | | | | | This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* include/device/device.h: Remove CHIP_NAME() macroNicholas Sudsgaard2024-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Macros can be confusing on their own; hiding commas make things worse. This can sometimes be downright misleading. A "good" example would be the code in soc/intel/xeon_sp/spr/chip.c: CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev, This appears as CHIP_NAME() being some struct when in fact these are defining 2 separate members of the same struct. It was decided to remove this macro altogether, as it does not do anything special and incurs a maintenance burden. Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0 Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239 Reviewed-by: Yidi Lin <yidilin@google.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Jakub Czapiga <czapiga@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
* soc/intel: Rename Makefiles from .inc to .mkMartin Roth2024-01-241-0/+0
| | | | | | | | | | | | | | | | | | The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ib479b93b7d0b2e790d0495b6a6b4b4298a515d9a Reviewed-on: https://review.coreboot.org/c/coreboot/+/80073 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp: Add IIO resources via SSDTArthur Heymans2024-01-221-6/+9
| | | | | | | | | | | | | | | There is no need to inject this code in DSDT. Just generating a _CRS Name in SSDT containing a resource template works well and reduces the need to sync up on names being used to return _CRS names in DSDT. TEST=intel/archercity CRB Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I691d7497dceb89619652e5523a29ea30a7b0fab8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* soc/intel/xeon_sp: Scan and allocate resources on all stacksArthur Heymans2024-01-221-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The code can now deal with stacks that have no resources so just hook them all up. Intel XEON-SP FSP reports all report the state of its stacks, which comprise of PCI root bridges and their respective resources, like PCI busses, IO and MEM resources, via HOB. Parsing all of those into native coreboot structures makes it possible to handle those in a more native fashion like use PCI drivers, native helper functions, ... As opposed parsing those structures again out of the HOB each time. This makes code reuse across the tree more feasible. An additional advantage is that Linux does not need to redo resource allocation since the one done by coreboot will be valid, which potentially decreases boot time. TEST=intel/archercity CRB Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Shuo Liu <shuo.liu@intel.com> Change-Id: Id72c6e4499e99df3b7ca821ab2893cbcc869dbcd Reviewed-on: https://review.coreboot.org/c/coreboot/+/78332 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* Reland "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi2024-01-171-4/+0
| | | | | | | | | | | | | | | | | This reverts commit acbc4912375085a099c2427def464d6e481f2a90. Reason for revert: CB:79525 fixes the issue that led to the revert by not maintaining the heap in the SMM-stored copy of ramstage at all. Change-Id: I3c8ef785486d275c9341859d34fce12253bd2bb9 Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80023 Reviewed-by: Sean Rhodes <sean@starlabs.systems> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp: Redesign resource allocationArthur Heymans2024-01-152-4/+9
| | | | | | | | | | | | | | | | | | | | | The xeon_sp code worked around the coreboot allocator rather than using it. Now the allocator is able to deal with the multiple IIOs so this is not necessary anymore. Instead do the following: - Parse the FSP HOB information about IIO into coreboot PCI domains - Use existing scan_bus and read_resource - Handle IOAT stacks with multiple domains in soc-specific code TEST=intel/archercity CRB Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Nico Huber <nico.h@gmx.de> Signed-off-by: Shuo Liu <shuo.liu@intel.com> Change-Id: Idb29c24b71a18e2e092f9d4953d106e6ca0a5fe1 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78327 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* Revert "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi2023-11-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 44a48ce7a46c36df69f7b2cf3552bf10fa5f61b6. Reason for revert: It breaks wakeup from suspend on a bunch of boards. While this approach of eyeballing "correct" values by chipset _should_ be fixed, it should also be accompanied by compile time verification that the memory map works out. Since nobody seems to care enough, let's just revert this, instead of keeping the tree broken for a bunch of configurations. Change-Id: I3cd73b6ce8b15f06d3480a03ab472dcd444d7ccc Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78850 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Subrata Banik <subratabanik@google.com>
* Kconfig: Bring HEAP_SIZE to a common, large valuePatrick Georgi2023-10-111-4/+0
| | | | | | | | | | | | | | | | | | We have a tiny HEAP_SIZE by default, except when we don't, and mainboards that override it, or not. Since memory isn't exactly at a premium these days, and unused heap doesn't cost anything extra, just crank it up to the highest value we have in the tree by default and remove all overrides. Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020 Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp/*/Kconfig: Refactor out and remove SOC_SPECIFIC_OPTIONSElyes Haouas2023-08-121-0/+8
| | | | | | | | | | | Move specific selections to {cpx,skx,spr} and remove dummy SOC_SPECIFIC_OPTIONS Change-Id: I71e41deb0478bf4d04395c88fc7b68df1ea83ac0 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* ACPI: Add helper fill_fadt_extended_pm_io()Kyösti Mälkki2023-08-081-16/+2
| | | | | | | | | | | | | Once platform code has filled in the (legacy) ACPI PM register map, added function will fill in the extended entries in FADT. TEST=samsung/lumpy and amd/mandolin FADT stays unchanged. Change-Id: I90925fce35458cf5480bfefc7cdddebd41b42058 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74913 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* soc/intel/xeon_sp: use VGA_MMIO_* defines from arch/vga.hFelix Held2023-07-201-3/+3
| | | | | | | | | | | Now that we have x86 architecture specific VGA_MMIO_* defines in arch/vga.h, use those instead of having SoC-specific defines for this. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I77b914d563bdc83e7fad7d7fccd5cf7777cb4918 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75669 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
* soc/intel/xeon_sp: Skip empty socketsPatrick Rudolph2023-07-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | The current Sapphire Rapids code assumes that all sockets have working CPUs. On multi-socket platforms a CPU might be missing or was disabled due to an error. The variable PlatformData.numofIIO and the variable SystemStatus.numCpus reflect the working CPUs, but not the actual socket count. Update the code to iterate over sockets until PlatformData.numofIIO IIOs have been found. This is required as FSP doesn't sort IIOs by working/non working status. This resolves invalid ACPI table generation and it fixes a crash as commands were sent to a disabled CPU. TEST: Disabled Socket1 on IBM/SBP1. Change-Id: I237b6392764bbdb3b96013f577a10a4394ba9c6e Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76559 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp: Print HOB for all socketsPatrick Rudolph2023-07-181-1/+1
| | | | | | | | | | | | | | | Use the FSP define to iterate over all sockets as the runtime value of numofIIO is the detected number of sockets, not the highest working socket. This fixes printing the HOB on multi-socket platforms where a CPU has been removed or has been disabled (4S system running as 3S). Change-Id: Ieed67cd48d26c7634636c0aae6a56f3b6fbdf640 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76492 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* sb,soc/amd,intel: Sync FADT entries visuallyKyösti Mälkki2023-05-101-2/+2
| | | | | | | | Change-Id: I20a66dce1612ab4394c26f9b0943dac14bcdcfc4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74912 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
* ACPI: Make FADT entries for RTC/CMOS architecturalKyösti Mälkki2023-04-291-2/+0
| | | | | | | | | | | | | | | | For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY that points to same offset. Since the century field inside RTC falls within the NVRAM space, and could interfere with OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY. There were no reference for the use of offset 0x48 for century. Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* soc/intel/xeon_sp: Don't sort struct device cpus for numaArthur Heymans2023-04-141-5/+3
| | | | | | | | | | | | | | | | | | Currently the xeon_sp code reassigns struct devices apic_id so that srat entries can be added in a certain order. This is not a good idea as it breaks thread local storage which contains a pointer to its struct device cpu. This moves the sorting of the lapic_ids to the srat table generation and adds the numa node id in each core init entry. Now it is done in parallel too as a bonus. Change-Id: I372bcea1932d28e9bf712cc712f19a76fe3199b1 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68912 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp/uncore_acpi.c: Add SPR-SP supportTim Chu2023-03-251-0/+1
| | | | | | | | | | | | | | Add support for Intel SPR-SP to uncore_acpi.c. Signed-off-by: Tim Chu <Tim.Chu@quantatw.com> Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com> Signed-off-by: Shelly Chang <Shelly_Chang@wiwynn.com> Change-Id: I4c436a60743bee21b3b6e4060d7874a6cdc75ecf Reviewed-on: https://review.coreboot.org/c/coreboot/+/71958 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* soc/intel/xeon_sp/smihandler.c: enable support for spr-spTim Chu2023-03-243-0/+11
| | | | | | | | | | | | For SPR-SP, the SMM_FEATURE_CONTROL register is in UBOX_URACU_FUNC instead of UBOX_DEV_PMON. Signed-off-by: Tim Chu <Tim.Chu@quantatw.com> Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com> Change-Id: Ide46c5f9cdf65b7e05552449b08ad4d7246664cc Reviewed-on: https://review.coreboot.org/c/coreboot/+/71962 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* soc/intel/xeon_sp: Split SKX/CPX MSRs into separate headersJonathan Zhang2023-03-191-0/+35
| | | | | | | | | Signed-off-by: Jonathan Zhang <jonzhang@meta.com> Signed-off-by: David Hendricks <ddaveh@amazon.com> Change-Id: I2ecfebdde453a48b7b0e6f21b3c4394411eed671 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73171 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
* soc/intel/xeon_sp: use get_socket_ubox_busno() to hide soc specificsJonathan Zhang2023-03-092-0/+21
| | | | | | | | | | | Intel SPR-SP has its specific way to get the bus number of ubox. Move the current implementations to CPX-SP and SKX-SP folders. Change-Id: I2b69be74d140115f9f78bc991fb690e3c90c88db Signed-off-by: Jonathan Zhang <jonzhang@meta.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72403 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* soc/intel/xeon_sp: Drop unused cpu.h headerArthur Heymans2023-02-264-18/+3
| | | | | | | | | Change-Id: I42856424d3b55107f1758fb05f7ddbee3550d8b2 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73200 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
* soc/intel: Use common codeflow for MP initArthur Heymans2023-02-232-4/+4
| | | | | | | | | | | | | | | This fixes MP init on xeon_sp SoCs which was broken by 69cd729 (mb/*: Remove lapic from devicetree). Alderlake cpu code was linked in romstage but unused so drop it. Change-Id: Ia822468a6f15565b97e57612a294a0b80b45b932 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72604 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sean Rhodes <sean@starlabs.systems> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* arch/x86/include/cpu: introduce CPU_TABLE_END CPU table terminatorFelix Held2023-02-091-1/+1
| | | | | | | | | | | | | | | | | | 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>
* arch/x86/cpu: introduce and use device_match_maskFelix Held2023-02-081-4/+4
| | | | | | | | | | | | | | | | | | | | | 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>
* soc/intel/xeon_sp: Use common gpio.h includeDinesh Gehlot2023-01-182-3/+3
| | | | | | | | | | | | | | | | | Replace the intelblocks/gpio.h, soc/gpio.h and soc/gpio_defs.h includes with the common gpio.h which includes soc/gpio.h which includes intelblocks/gpio.h which includes soc/gpio_defs.h. This patch also fixes alphabetic ordering of included headers. BUG=b:261778357 TEST=Able to build and boot. Signed-off-by: Dinesh Gehlot <digehlot@google.com> Change-Id: I8135dc918cb04c854dc003966b7657806a42bad9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72042 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
* soc/intel/xeon_sp/skx: Remove nested check for ACPI supportMarc Jones2023-01-091-2/+0
| | | | | | | | | | Remove redundant nested check for ACPI support. Change-Id: Ie4b40382d304028135bcdd7851e2f48333570421 Signed-off-by: Marc Jones <marcj303@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66698 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
* soc/intel/xeon_sp: Move codes to support new PCHTim Chu2022-12-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Different PCHs have different definitions for registers. Here create a lbg folder and move lbg specific codes to this folder so that we can add new PCH code under xeon_sp folder. * Create lbg folder and move lbg specific codes from pch.c to soc_pch.c under lbg folder. * Rename lewisburg_pch_gpio_defs.h to gpio_soc_defs.h and move to lbg folder. * Rename gpio.c to soc_gpio.c and move to lbg folder. * Move pcr_ids.h to lbg folder. * Move lbg specific codes from pmutil.c to soc_pmutil.c under lbg folder. * Create and revise makefile for files under lbg folder. TEST=Can boot into OS on OCP Delta Lake. Signed-off-by: Tim Chu <Tim.Chu@quantatw.com> Change-Id: I06555ed6612c632ea2ce1938d81781cd9348017a Reviewed-on: https://review.coreboot.org/c/coreboot/+/70009 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* soc/intel/xeon_sp: Read ioapic configuration from hardwareArthur Heymans2022-12-061-4/+0
| | | | | | | | | | | This is more robust than hardcoding whathever FSP has set up and is a lot less code. Change-Id: I6423ddc139d742879d791b054ea082768749c0a7 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70265 Reviewed-by: Jonathan Zhang <jonzhang@fb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Revert "src/arch/x86: Use core apic id to get cpu_index()"Arthur Heymans2022-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | This reverts commit 095c931cf12924da9011b47aa64f4a6f11d89f13. Previously cpu_info() was implemented with a struct on top of an aligned stack. As FSP changed the stack value cpu_info() could not be used in FSP context (which PPI is). Now cpu_info() uses GDT segments, which FSP does not touch so it can be used. This also exports cpu_infos from cpu.c as it's a convenient way to get the struct device * for a certain index. TESTED on aldrvp: FSP-S works and is able to run code on APs. Change-Id: I3a40156ba275b572d7d1913d8c17c24b4c8f6d78 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69509 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* drivers/intel/fsp2_0: add log level parameter to fsp_print_guidFelix Held2022-11-161-1/+1
| | | | | | | | | | | | | | | Not all functions that call fsp_print_guid print their output with the BIOS_SPEW log level, so introduce a new log level parameter so that the caller of fsp_print_guid can specify which log level fsp_print_guid should use for printing the GUID. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I3b37afe703f506d4913f95a954368c0eec0f862d Reviewed-on: https://review.coreboot.org/c/coreboot/+/69599 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/xeon_sp: accomodate xeon_sp FSPX_CONFIG definitionsJonathan Zhang2022-11-081-2/+2
| | | | | | | | | | | | | | | | | | | Intel FSPs of XEON server platforms define FSPX_CONFIG instead of FSP_X_CONFIG, which is expected by coreboot. Re-define in the common code. Update coreboot code to use FSP_X_CONFIG consistently. Tested=On OCP Delta Lake, boot up OS successfully. Signed-off-by: Jonathan Zhang <jonzhang@fb.com> Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com> Change-Id: Ifa0e1efa1618fbec84f1e1f23d9e49f3b1057b32 Reviewed-on: https://review.coreboot.org/c/coreboot/+/69090 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* soc/intel/xeon_sp: Remove unused madt setup functionArthur Heymans2022-10-281-16/+0
| | | | | | | | Change-Id: I248974c5a88768ee12f63fa77f3fa67a72ea510e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68907 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
* treewide: Use 'pm2_cnt_len' for 'x_pm2_cnt_blk.bit_width'Elyes Haouas2022-10-121-1/+1
| | | | | | | | Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I040ddab8845cc2191c6ca5af7f132ec8a504bccf Reviewed-on: https://review.coreboot.org/c/coreboot/+/68274 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* treewide: Use 'fadt->pm_tmr_len' for 'x_pm_tmr_blk.bit_width'Elyes Haouas2022-10-121-1/+1
| | | | | | | | Change-Id: Id4e2939b74ec93f50a4bedd0069090f0775b0556 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* treewide: use is_enabled_cpu() on cycles over device listFabio Aiuto2022-09-291-5/+1
| | | | | | | | | | | | | | | use is_enabled_cpu() on cycles over device list to check whether the current device is enabled cpu. TEST: compile test and qemu run successfully with coreinfo payload Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797 Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* soc/intel/xeon_sp: Use "if (!ptr)" in preference to "if (ptr == NULL)"Elyes Haouas2022-09-154-6/+6
| | | | | | | | Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Change-Id: I664f5b7d354b0d9a7144c25604ae4efbdd9ba9a9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67593 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
* soc/intel/xeon_sp: Make gsi_bases platform independentChristian Walter2022-07-151-0/+8
| | | | | | | | | | | | This commit makes gsi_bases platform independent. It introduces two new Kconfigs which set if there are IIO APICs on other devices than the PCH or not, and where they do start. Change-Id: I40db4a8fd90572757687f35bbd8eebd7229fc75a Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65531 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* soc/intel/common/cpu: Use SoC overrides to set CPU privilege levelSubrata Banik2022-06-021-0/+5
| | | | | | | | | | | | | | | | This patch implements a SoC overrides to set CPU privilege level as the MSR is not consistent across platforms. For example: On APL/GLK/DNV, it's MSR 0x120 and CNL onwards it's MSR 0x151. BUG=b:233199592 TEST=Build and boot google/taeko to ChromeOS. Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: I4584516102560e6bb2a4ae8c0d036be40ed96990 Reviewed-on: https://review.coreboot.org/c/coreboot/+/64806 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
* soc/intel/xeon_sp/skx: Use correct formatted print for size_tArthur Heymans2022-05-131-1/+1
| | | | | | | | | Change-Id: I2acad0763d19b50c02472dfdd33084acbafe4c84 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64241 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
* soc/intel/common/cpu: Use SoC overrides to get CPU privilege levelSubrata Banik2022-01-191-0/+6
| | | | | | | | | | | | | | | | This patch implements a SoC overrides to check CPU privilege level as the MSR is not consistent across platforms. For example: On APL/GLK/DNV, it's MSR 0x120 and CNL onwards it's MSR 0x151. BUG=b:211573253, b:211950520 Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: I515f0a3548bc5d6250e30f963d46f28f3c1b90b3 Reviewed-on: https://review.coreboot.org/c/coreboot/+/60900 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* pci_mmio_cfg: Always use pci_s_* functionsNico Huber2021-11-092-12/+12
| | | | | | | | | | | | | | When MMIO functions are available, the pci_s_* functions do exactly the same thing. Drop the redundant pci_mmio_* versions. Change-Id: I1043cbb9a1823ef94bcbb42169cb7edf282f560b Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58333 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shelley Chen <shchen@google.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* cpu/x86/Kconfig: Remove unused CPU_ADDR_BITSArthur Heymans2021-11-031-4/+0
| | | | | | | | | Change-Id: I88f62c18b814ac0ddd356944359e727d6e3bba5a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/58688 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
* cpu/x86: Introduce and use `CPU_X86_LAPIC`Felix Held2021-10-261-1/+0
| | | | | | | | | | | | | | | | | | | | | With using a Kconfig option to add the x86 LAPIC support code to the build, there's no need for adding the corresponding directory to subdirs in the CPU/SoC Makefile. Comparing which CPU/SoC Makefiles added (cpu/)x86/mtrr and (cpu/)x86/lapic before this and the corresponding MTRR code selection patch and having verified that all platforms added the MTRR code on that patch shows that soc/example/min86 and soc/intel/quark are the only platforms that don't end up selecting the LAPIC code. So for now the default value of CPU_X86_LAPIC is chosen as y which gets overridden to n in the Kconfig of the two SoCs mentioned above. Change-Id: I6f683ea7ba92c91117017ebc6ad063ec54902b0a Signed-off-by: Angel Pons <th3fanbus@gmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44228 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
* soc/*/Makefile: don't add cpu/x86/cacheFelix Held2021-10-261-1/+0
| | | | | | | | | | | | | No SoC uses the ramstage-only x86_enable_cache helper function to call enable_cache with some added port 0x80 and console output. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I7c5039e1341fd4089078ad7ffb2fe6584a94045c Reviewed-on: https://review.coreboot.org/c/coreboot/+/58547 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
* cpu,soc/x86: always include cpu/x86/mtrr on x86 CPUs/SoCsFelix Held2021-10-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | All x86-based CPUs and SoCs in the coreboot tree end up including the Makefile in cpu/x86/mtrr, so include this directly in the Makefile in cpu/x86 to add it for all x86 CPUs/SoCs. In the unlikely case that a new x86 CPU/SoC will be added, a CPU_X86_MTRR Kconfig option that is selected be default could be added and the new CPU/SoC without MTRR support can override this option that then will be used in the Makefile to guard adding the Makefile from the cpu/x86/mtrr sub-directory. In cpu/intel all models except model 2065X and 206AX are selcted by a socket and rely on the socket's Makefile.inc to add x86/mtrr to the subdirs, so those models don't add x86/mtrr themselves. The Intel Broadwell SoC selects CPU_INTEL_HASWELL and which added x86/mtrr to the subdirs. The Intel Xeon SP SoC directory contains two sub-folders for different versions or generations which both add x86/mtrr to the subdirs in their Makefiles. Change-Id: I743eaac99a85a5c712241ba48a320243c5a51f76 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44230 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
* cpu/x86/mp_init: move printing of failure message into mp_init_with_smmFelix Held2021-10-221-2/+2
| | | | | | | | | | | | | | | | | | | | 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>