summaryrefslogtreecommitdiff
path: root/src/cpu
AgeCommit message (Collapse)Author
2024-06-18cpu/x86: Rename paging structure variables for claritySubrata Banik
The following variables have been renamed: * PDPE_table -> PDPT (Page Directory Pointer Table) * PDE_tables -> PDT (Page Directory Table) This change improves the consistency and clarity of the code as per AMD Architecture Programmer's Manual document. PML4 -> PDPT -> PDT -> 2MB Physical Page TEST=Able to build and boot google/rex64. Change-Id: Ib57d1d54c2c1f4fcce2315b508ed7643251a20c5 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83101 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-06-18cpu/x86: Rename `PDE_table` to `PDPT` for 1 GiB page mappingsSubrata Banik
This commit fixes an incorrect variable name in the page table setup for 1 GiB pages. The label PDE_table was used when it should have been PDPT, as it represents a "Page Directory Pointer Table (PDPT)", not a "Page Directory Table (PDT) or PDE_Table". This change ensures correct nomenclature and consistency in the code. PML4 -> PDPT --------> 1GB Physical Page As per x86-64 specification, 1GB pages bypass the Page Directory Table (PDT) level of the page table hierarchy, mapping directly from the Page Directory Pointer (PDPT) Table to the physical page. Change-Id: I1e1064653a265215054f31f0e4e46bf8200ca471 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83100 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-06-11tree: Drop non-existent directories from subdirs-yElyes Haouas
Change-Id: Icb9e72edf3a982a095dceee4da19f90c53fcddd0 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/83021 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-06-09cpu/x86/Kconfig: Add SMM Kconfig helpMaximilian Brune
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Ia0a5c48c6314f53c4ed72958f5d6f839f0a5c2ca Reviewed-on: https://review.coreboot.org/c/coreboot/+/77973 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-06-05cpu/x86: Make 1GB paging the defaultJulius Werner
This patch flips the polarity of CONFIG_USE_1G_PAGES_TLB into CONFIG_NEED_SMALL_2MB_PAGE_TABLES which is off by default, meaning CPUs added in the future will automatically build the smaller 1GB pages. We can expect support for this feature to be available on all future CPU generations (with the possible exception of embedded edge cases), so this default setting should make mistakes less likely and keep maintenance effort lower. (Besides, enabling the support where it doesn't work fails fast, whereas keeping it disabled where it could work is an inefficiency that can easily go overlooked for a long time.) While this is technically a CPU feature, not a northbridge feature, we support a lot more individual CPUs than northbridges in the pre-SoC era, and they tend to be closely coupled anyway. So select the option at the northbridge level for older CPUs to keep things simpler. Change-Id: I2cf1237a7fb63b8904c2a3d57fead162c66bacde Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2024-05-29cpu/x86/pae/pgtbl.c: extract reusable code from memset_pae()Krystian Hebel
Code dealing with PAE can be used outside of memset_pae(). This change extracts creation of identity mapped pagetables to init_pae_pagetables() and mapping of single 2 MiB map to pae_map_2M_page(). Both functions are exported in include/cpu/x86/pae.h to allow use outside of pgtbl.c. MEMSET_PAE_* macros were renamed to PAE_* since they no longer apply only to memset_pae(). Change-Id: I8aa80eb246ff0e77e1f51d71933d3d00ab75aaeb Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82249 Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-29tree: Use <stdio.h> for snprintfElyes Haouas
<stdio.h> header is used for input/output operations (such as printf, scanf, fopen, etc.). Although some input/output functions can manipulate strings, they do not need to directly include <string.h> because they are declared independently. Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665 Reviewed-by: Yidi Lin <yidilin@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-23cpu/intel/model_206ax: Program Ivy Bridge defaults for MSR_PKGC_IRTLPatrick Rudolph
Ivy Bridge has lower latencies than Sandy Bridge has. Update MSRs MSR_PKGC_IRTL with values from BWG. Test: Lenovo X220 still boots. Change-Id: Ib307e3b191ba68e016cc348f82e2dccf1dc9ae16 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78609 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-05-15cpu/x86/pae/pgtbl.c: remove dead paging_identity_map_addr()Krystian Hebel
This function had roughly the same use (except PAT) as part of memset_pae(), however the latter is able to make use of PAE and map physical memory located above 4 GB. Remove paging_identity_map_addr() to avoid semi-duplicated code. The function has been unused since CB:26745. Change-Id: I7a4ebd84a6f5d222c3b2c6c6e3d26d6464cf01b8 Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82248 Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-05-13cpu/x86/pae/pgtbl.c: remove dead map_2M_page()Krystian Hebel
This function isn't used anywhere. It probably wouldn't work with current coreboot anyway, as it identity mapped lower 2GB of RAM, while ramstage is run from CBMEM, which is usually just below top of memory. It was last used in K8 code that is long gone. Change-Id: I97e2830f381181d7f21ab5f6d4c544066c15b08c Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82247 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
2024-04-22cpu/intel/model_206ax: Allow to configure VR settingsPatrick Rudolph
Allow to set board specific CPU voltage regulator settings. The VR12 compatible voltage regulator for the CPU can be configured by two MSRs. Currently a default value is applied, which mimics the Intel reference code and is what the BWG suggest. However most board vendors fill in the actual VR parameters to support OC or ULV board variants. When the mainboard design is too different from the Intel reference design, not updating the VR settings might result in: - unstable system behaviour - limited turbo performance - excessive battery drain - no over-clocking capability This patch adds support to set the board specific current limit for Icc and Igfx. It also allows to adjust PSI1, PSI2 and PSI3, which are powerstates used by the VR, that consume less energy when the system is idle. Test on Lenovo X220 with full CPU load after 1 minute, compared to previous code with default settings: - Limiting PP0 max current below Iccmax results in less CPU performance. RAPL readings show that less power is drawn over time. - Limiting PP0 max current to Iccmax results in equal CPU performance. RAPL readings show that the same power is drawn over time. - Setting the PP0 max current to a value >> Iccmax results in equal CPU performance. RAPL readings show that the same power is drawn over time. - Updating the MSR at runtime has no effect. Change-Id: I59edab47fc4fbe0240e1dd7d25647f7549b4def2 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81597 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2024-04-20payloads/edk2: Add Kconfig to use LAPIC timerJean Lucas
Core 2 platforms have issues with HPET. Enable support to use the LAPIC driver so those machines actually boot and don't hang. The LAPIC is actually closer to the CPU than the HPET (on the PCH), which reduces access latency, leading to higher resolution of the timer. Tested on a Lenovo X200 with a Core 2 Duo. Change-Id: I33144d6c1c120e7faa47b99e8262b0997c45c9b9 Signed-off-by: Jean Lucas <jean@4ray.co> Reviewed-on: https://review.coreboot.org/c/coreboot/+/82000 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2024-04-18cpu/intel/microcode: Defer microcode patching until after DRAM initSubrata Banik
Follows Intel SoC recommendation to avoid potential cache contention issues during early (pre-DRAM) microcode loading. Source: MTL_ARL_Processor_Family_BiosSpec_Rev1p0 Document Number: 729384 BUG=b:330536271 TEST=Able to boot to ChromeOS. w/o this patch: [DEBUG] microcode: sig=0xa06a4 pf=0x80 revision=0x19 [INFO ] CBFS: Found 'cpu_microcode_a06a4.bin' @0x1d9c0 size 0x21400 in mcache @0xfef89680 [INFO ] VB2:vb2_digest_init() 136192 bytes, hash algo 2, HW acceleration enabled [INFO ] microcode: load microcode patch [ERROR] microcode: Update failed w/ this patch: [ERROR] Microcode Error: Early microcode patching is not supported due to NEM limitation Change-Id: I1e433f5bede036800b27900b4b13a399b4f45d6f Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81954 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-12tree: Drop duplicated <stdarg.h> and <stdio.h>Elyes Haouas
<string.h> is supposed to provide <stdarg.h> and <stdio.h> Change-Id: I021ba535ba5ec683021c4dfc41ac18d9cebbcfd2 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81853 Reviewed-by: Eric Lai <ericllai@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-04-12tree: Drop duplicated <device/{path,resource}.h>Elyes Haouas
<device/device.h> is supposed to provide <device/{path,resource}.h> Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com>
2024-04-05smmstorev2: Load the communication buffer at SMM setupArthur Heymans
This removes the runtime SMI call to set up the communication buffer for SMMSTORE in favor of setting this buffer up during the installation of the smihandler. The reason is that it's less code in the handler and a time costly SMI is also avoided in ramstage. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I94dce77711f37f87033530f5ae48cb850a39341b Reviewed-on: https://review.coreboot.org/c/coreboot/+/79738 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-04-04tree: Remove duplicated <stdint.h>Elyes Haouas
<types.h> is supposed to provide <stdint.h>. Change-Id: Ia68a0dc8fba4a48401e213ebb8356e32f0a019ab Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81633 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-04-03cpu/x86/topology: Add node ID parserPatrick Rudolph
Currently the SRAT table only exposes one proximity group as it uses the LAPIC node_id, which is always initialized to 0. Use CPUID leaf 0x1f or 0xb to gather the node ID and fill it to make sure that at least one proximity group for every socket is advertised. For now the SNC config isn't taken into account. Change-Id: Ia3ed1e5923aa18ca7619b32cde491fdb4da0fa0d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81515 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shuo Liu <shuo.liu@intel.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
2024-03-28cpu/x86: Link page tables in stage if possibleArthur Heymans
When switching back and forth between 32 to 64 bit mode, for example to call a 32-bits FSP or to call the payload, new page tables in the respective stage will be linked. The advantages of this approach are: - No need to determine a good place for page tables in CBFS that does not overlap. - Works with non memory mapped flash (however all coreboot targets currently do support this) - If later stages can use their own page tables which fits better with the vboot RO/RW flow A disadvantage is that it increases the stage size. This could be improved upon by using 1G pages and generating the pages at runtime. Note: qemu cannot have the page tables in the RO boot medium and needs to relocate them at runtime. This is why keeping the existing code with page tables in CBFS is done for now. TEST: Booted to payload on google/vilbox and qemu/q35 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-03-21arch/x86: Fix typo for macro CPUID_FEATURE_HTTJincheng Li
Change-Id: I9b29233e75483cda6bf7723cf79632f6b04233b0 Signed-off-by: Jincheng Li <jincheng.li@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81260 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-03-20cpu/x86/smm: Pass full SMRAM region info to SMM runtimeBenjamin Doron
This data is used by smm_region_overlaps_handler(). Callers use this helper to determine if it's safe to read/write to memory buffers taken from untrusted input. coreboot SMI handlers must not be confused into writing over any SMRAM subregion, which includes the TSEG_STAGE_CACHE and chipset-specific area (sometimes, IED), not just the handlers. If stage cache writes were permitted, this could compromise the integrity of the S3 resume path. The consequences to overwriting the chipset-specific area are undefined. Change-Id: Ibd9ed34fcfd77a4236b5cf122747a6718ce9c91f Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80703 Reviewed-by: Shuo Liu <shuo.liu@intel.com> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-03-19cpu/x86: Use correct config flag for 1GiB page tableBora Guvendik
The commit below uses USE_1G_PAGETABLES config flag instead of the correct USE_1G_PAGES_TLB. "commit ecbc243a45de3b7894e2fe6c8e22b5d07172274b ("cpu/x86: Add 1GiB pages for memory access up to 512GiB")" Signed-off-by: Bora Guvendik <bora.guvendik@intel.com> Change-Id: Ic19812bc1f90cbe7d3739c42a0314b3650e0501d Reviewed-on: https://review.coreboot.org/c/coreboot/+/81343 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-03-19cpu/x86/mtrr: Error out caching limitation during NEMSubrata Banik
Improves user experience by highlighting a possibility of runtime hangs caused by unsupported WB caching during NEM. Recently we have encountered an issue on Intel platform and came to know about the NEM logical limitation where due to cache sets are not in power_on_two running into a runtime hang upon enabling WB caching. BUG=b:306677879 BRANCH=firmware-rex-15709.B TEST=Verified boot on google/ovis and google/rex (including Ovis with non-power-of-two cache configuration). Change-Id: Ic4fbef1fcc018856420428139683897634c9f85d Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81336 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-03-09cpu/x86/smm: Set up page tables in safe SMRAMArthur Heymans
Relying on page tables being in RO flash is not safe in every setup, therefore set up some page tables in SMRAM that the permanent smihandler can use. Tested on QEMU. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: Icb3086abd577b9abb9966dd910a264a873ace4ed Reviewed-on: https://review.coreboot.org/c/coreboot/+/80336 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-28cpu/x86/(sipi|smm): Pass on CR3 from ramstageArthur Heymans
To allow for more flexibility like generating page tables at runtime or page tables that are part of the ramstage, add a parameter to sipi_vector.S and smm_stub.S so that APs use the same page tables as the BSP during their initialization. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I1250ea6f63c65228178ee66e06d988dadfcc2a37 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80335 Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
2024-02-26lib: Remove heap from rmodulesArthur Heymans
No rmodule was using heap. Change-Id: I0bc049a5231dabbec1c962a99ef875eddcc4ac6e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80733 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2024-02-20treewide: Remove unused CHIPsArthur Heymans
No devicetree uses these anymore. Change-Id: Ia65a0a56a6668a13761bad35f6a44ed8f6a35a78 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72600 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-18arch to cpu: Add SPDX license headers to Kconfig filesMartin Roth
Change-Id: I7dd7b0b7c5fdb63fe32915b88e69313e3440b64a Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80587 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-08cpu/x86/64bit: Turn jumping to long mode into a macroArthur Heymans
This makes it easier to reuse, e.g. if you want to do it twice in one assembly file. Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-02-08cpu/qemu-x86/cache_as_ram: Move guardArthur Heymans
Although entry64.inc does guard against ENV_X86_64, it's more aesthetic to have it with the other 64bit code below a guard just like other platforms. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: If3ef19dd6654cd2fa0be3c68dee4a472e7a7935d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80354 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-02-08cpu/x86: Add 1GiB pages for memory access up to 512GiBAshish Kumar Mishra
Current pagetable implementation allows memory access up to 4GiB using 2MiB pages. If user wants to access more than 4GiB with a 2MiB page it will require more pagetable entries. By using a 1GiB page table, users can access more than 4GiB of memory while reducing the number of pagetable entries. This patch enables memory access up to 512GiB through 1GiB pages by selecting USE_1G_PAGES_TLB in Kconfig. TEST: Verified in 64bit mode boot and access above 4GiB Change-Id: Id569ae5b50abf5b72e4db33b5e4cd802399e76ec Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80088 Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-02-02cpu/x86/smm/pci_resource_store: Allow devices with no resourcesPatrick Rudolph
When a device with no resource is passed it will keep overwriting the current slot. Remove the conditional and allow a PCI device to not have any resources. This is particular useful for the next commits that makes use of the PCI resource store to pass UBOX devices to SMM that allow to lock-down SMM from within an SMI handler. Those devices do not have any resources and cannot be hardcoded in SMM as their PCI segment group and bus number varies depending on socket count, CPU discovery and configuration. Change-Id: I1a1b5944c97da5be6b9794c653b5159683f492e5 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80246 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
2024-01-31cpu/x86/smm/pci_resource_store: Store DEV/VEN IDPatrick Rudolph
Allow SMM to verify the list of provided PCI devices by comparing the device and vendor ID for each PCI device. Change-Id: I7086fa450fcb117ef8767c199c30462c1ab1e1b6 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80245 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-31device/device.h: Rename busses for clarityArthur Heymans
This renames bus to upstream and link_list to downstream. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2024-01-31include/device/device.h: Remove CHIP_NAME() macroNicholas Sudsgaard
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>
2024-01-24cpu: Rename Makefiles from .inc to .mkMartin Roth
The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I552d487978906f5ea74c3d0d85373fe5b2de3f38 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80068 Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
2024-01-17Reland "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi
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>
2024-01-14tree: Use accessor functions for struct region fieldsNico Huber
Always use the high-level API region_offset() and region_sz() functions. This excludes the internal `region.c` code as well as unit tests. FIT payload support was also skipped, as it seems it never tried to use the API and would need a bigger overhaul. Change-Id: Iaae116a1ab2da3b2ea2a5ebcd0c300b238582834 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79904 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2024-01-11cpu/x86/smi_trigger: use call_smmFelix Held
Use call_smm instead of writing the command number directly to the APMC SMI command IO port. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iefbdb3d17932d6db6a17b5771436ede220c714fb Reviewed-on: https://review.coreboot.org/c/coreboot/+/79828 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-10cpu/x86/smi_trigger: use enum cb_err as apm_control return typeFelix Held
Even though the return value from apm_control isn't checked at any of its call sites, using the cb_err enum instead of an integer as return type makes it clearer what the returned value means. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I07ced74cae915df52a9d439835b84237d51fdd11 Reviewed-on: https://review.coreboot.org/c/coreboot/+/79835 Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <ericllai@google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2024-01-08cpu/x86/smi_trigger: call pm_acpi_smi_cmd_port to get APMC SMI IO portFelix Held
Instead of hard-coding the APMC SMI command IO port in the FADT, call pm_acpi_smi_cmd_port() to get the APMC SMI command IO port. Also update the comment in apm_get_apmc to match what it's doing. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0f36b8a0e93a82b8c6d23c5c5d8fbebb1bc6b0bc Reviewed-on: https://review.coreboot.org/c/coreboot/+/79567 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
2024-01-05arch/x86/include/mode_switch: Add more wrapper functionsPatrick Rudolph
Add a protected mode wrapper function that takes three arguments. This is already supported by the called assembly code. Change-Id: Ia8c91eebae17e4ca27e391454c2d130a71c4c9f3 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79756 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-05northbridge/intel/sandybridge: Enable x86_64 for mrc.binPatrick Rudolph
Enable x86_64 support for MRC.bin: - Add a wrapper function for console printing that calls into long mode to call native do_putchar - Remove Kconfig guard for x86_64 when MRC is being used Tested: Booted Lenovo X220 using mrc.bin under x86_64 and MRC is able to print to the console. Change-Id: I21ffcb5f5d4bf155593e8111531bdf0ed7071dfc Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79754 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-05cpu/x86/64bit/mode_switch2: The reverse function to mode_switchPatrick Rudolph
Add another mode_switch assembly function to call x86_64 code from x86_32 code. This is particullary useful for BLOBs like mrc.bin or FSP that calls back into coreboot. The user must first wrap all functions that are to be called from x86_32 using the macro prot2lm_wrapper. Instead of using the original function the wrapped functions must be passed to the x86_32 BLOBs. The assembly code assume that 0-3 32bit arguments are passed to the wrapped function. Tested: - Called x86_64 code from x86_32 code in qemu. - Booted Lenovo X220 using x86_32 MRC using x86_64 console. Change-Id: Ib625233e5f673eae9f3dcb2d03004c06bb07b149 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79753 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2024-01-03cpu/x86/64bit/mode_switch: Simplify assembly codePatrick Rudolph
Drop the first argument specifying the number of arguments pushed to the stack. Instead always push the 3 arguments to stack and use the first one as function pointer to call while in protected mode. While on it add more comments and simplify register restore code. Tested: - On qemu can call x86_32 function and pass argument and return value. - Booted Lenovo X220 in x86_64 mode using x86_32 MRC. Change-Id: I30809453a1800ba3c0df60acd7eca778841c520f Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79752 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-12-22Revert "cpu/intel/common: Define build time physical address reserved bits"Jeremy Compostella
This reverts commit 6dff1fd7d5e419b2f947f516551dcab3f4ebe30a. BUG=b:314886709 Change-Id: Ic63c93cb15d2998e13d49a872f32d425237f528b Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79663 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-12-04cpu/intel/model_206ax: Use macro IS_IVY_CPUPatrick Rudolph
Use existing macro instead of open coding magic numbers. No functionality change. Change-Id: If45f7f3f2b4226cedde6ff91b9848b9875f45f9f Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/79148 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-11-20nb/intel/sandybridge: Use SA devid to identify PC typePatrick Rudolph
Instead of using MSR IA32_PLATFORM_ID read the SystemAgent device id to figure out the PC type. This follows the BWG which suggest to not use MSR IA32_PLATFORM_ID for system identification. Tested: Lenovo X220 still boots. Change-Id: Ibddf6c75d15ca7a99758c377ed956d483abe7ec1 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78826 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-11-20cpu/intel/model_206ax: Lock MSR_PP_CURRENT_CONFIGPatrick Rudolph
Now that those registers are only written once set the lock bit to protect it from runtime changes. TEST: Lenovo X220 still boots. Change-Id: I4c56a3cb322a0e75eb3dd366808068093928e10c Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78608 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-11-20cpu/intel/model_206ax: Write MSRs in scope package only oncePatrick Rudolph
Write MSRs that are in scope package only once by checking for the BSP bit. While this improves performance a bit it also has the benefit that registers can be safely locked down without the need for semaphores. TEST: Lenovo X220 still boots. Change-Id: I43f5d62d782466d2796c1df6015d43c0fbf9d031 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78607 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-11-14cpu/intel/model_2065x: Read CPU voltage for SMBIOSPatrick Rudolph
Report smbios_cpu_get_voltage() on Sandy Bridge as well. Change-Id: I13ea930a58eaedc24d69fa3790f1f2a151558a80 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78432 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-11-10cpu/x86/smm: Fix get_save_state calculationEugene D. Myers
When the SMI transfer monitor (STM) is configured, get_save_state returns an incorrect pointer to the cpu save state because the size (rounded up to 0x100) of the processor System Management Mode (SMM) descriptor needs to be subtracted out in this case. This patch addresses the issue identified in CB:76601, which means that SMMSTOREv2 now works with the STM. Thanks to Jeremy Compostella for suggesting this version of the patch. Resolves: https://ticket.coreboot.org/issues/511 Change-Id: I0233c6d13bdffb3853845ac6ef25c066deaab747 Signed-off-by: Eugene D. Myers <edmyers@cyberpackventures.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78889 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-11-09Allow to build romstage sources inside the bootblockArthur Heymans
Having a separate romstage is only desirable: - with advanced setups like vboot or normal/fallback - boot medium is slow at startup (some ARM SOCs) - bootblock is limited in size (Intel APL 32K) When this is not the case there is no need for the extra complexity that romstage brings. Including the romstage sources inside the bootblock substantially reduces the total code footprint. Often the resulting code is 10-20k smaller. This is controlled via a Kconfig option. TESTED: works on qemu x86, arm and aarch64 with and without VBOOT. Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-11-07Revert "Kconfig: Bring HEAP_SIZE to a common, large value"Patrick Georgi
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>
2023-10-20cpu/intel/common: Define build time physical address reserved bitsJeremy Compostella
According the Intel Software Developer Manual, CPUID.80000008H:EAX[15:8] reports the physical-address width supported by the processor. Unfortunately, it does not necessarily reflect the physical-address space the system can actulally use as some of those bits can be reserved for internal hardware use. It is critical for coreboot to know the actual physical address size. Overestimating this size can lead to device resource overlaps due to the hardware ignoring upper reserved bits. On rex for instance, it creates some reboot hangs due to an overlap between thunderbolt and Input Output Manager (IOM) address space. As some SoCs, such as Meteor Lake, have physical address reserved bits which cannot be probed at runtime, this commit introduces `CPU_INTEL_COMMON_RESERVED_PHYS_ADDR_BITS' Kconfig to set the number of physical address reserved bits at compilation time for those SoCs. A runtime detection by hardware probing will be attempted if the value is 0 (default). BUG=b:288978352 Change-Id: I8748fa3e5bdfd339e973d562c5a201d5616f813e Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78451 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kapil Porwal <kapilporwal@google.com>
2023-10-20x86: Add pre-memory stages CBFS cache scratchpad supportJeremy Compostella
Having a CBFS cache scratchpad offers a generic way to decompress CBFS files through the cbfs_map() function without having to reserve a per-file specific memory region. This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set the pre-memory stages CBFS cache size. A cache size of zero disables the CBFS cache feature. The default value is 16 KB which seems a reasonable minimal value enough to satisfy basic needs such as the decompression of a small configuration file. This setting can be adjusted depending on the platform needs and capabilities. We have set this size to zero for all the platforms without enough space in Cache-As-RAM to accommodate the default size. TEST=Decompression of vbt.bin in romstage on rex using cbfs_map() Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-10-11Kconfig: Bring HEAP_SIZE to a common, large valuePatrick Georgi
We have a tiny HEAP_SIZE by default, except when we don't, and mainboards that override it, or not. Since memory isn't exactly at a premium these days, and unused heap doesn't cost anything extra, just crank it up to the highest value we have in the tree by default and remove all overrides. Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020 Signed-off-by: Patrick Georgi <patrick@coreboot.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-06cpu/intel/model_206ax: Only use supported C-statesPatrick Rudolph
When advertising C-state using the ACPI _CST object, make sure to only advertise those that are supported by the CPU. Downgrade if it's not and make sure to not advertise duplicate states. Add debug prints for the finally selected mapping of ACPI C-state vs Intel CPU C-state. Test: Tested on Lenovo X220. All C-states are still advertised as all are supported. Change-Id: Iaaee050e0ce3c29c12e97f5819a29f485a7946c2 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78194 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-10-06cpu/intel/model_206ax: Use haswell cstate_mapPatrick Rudolph
Make the code look like on newer platforms. This doesn't change functionality. Test: Lenovo X220 still boots and advertises all C-states as before. Change-Id: Ie7076d11720d55a4ac11318cbbdab9f75d08e15e Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78193 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-10-06cpu/intel/model_206ax: Print supported C-statesPatrick Rudolph
According to the BWG C-states are processor specific and BIOS must check if a C-state is supported at all. Print the supported C-states in before ACPI _CNT generation. Test: Tested on Lenovo X220 using Intel i5-2540M. All C-states are reported as supported. Change-Id: I713712a1a104714cbf3091782e564e7e784cf21d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78133 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-10-05cpu/intel/socket_BGA956: Double DCACHE_RAM_SIZE to 64 kBArthur Heymans
This fixes building lenovo/x200 with VBOOT. All supported CPUs have enough L2 cache to support this. Change-Id: Ifd6a16ce36c86349955cd7b7ddb3f74a19c17c4d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/71905 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin L Roth <gaumless@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-09-29arch/x86/Kconfig: introduce RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORTFelix Held
Since also some AMD CPUs have reserved physical address bits that can't be used as normal address bits, introduce the RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets selected by CPU_INTEL_COMMON, and use the new common option to configure if the specific SoC/CPU code implements get_reserved_phys_addr_bits or if the default of this returning 0 is used instead. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-29*/include/cpu: use unsigned int for number of address bitsFelix Held
The number of physical address bits and reserved address bits shouldn't ever be negative, so change the return type of cpu_phys_address_size, get_reserved_phys_addr_bits, and get_tme_keyid_bits from int to unsigned int. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I9e67db6bf0c38f743b50e7273449cc028de13a8c Reviewed-on: https://review.coreboot.org/c/coreboot/+/78072 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
2023-09-20cpu/x86/mtrr/debug: rename variables in display_variable_mtrrFelix Held
Change the name of msr_a and msr_m to the more descriptive msr_base and msr_mask. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I6e0010f6d35ccf4288f4e0df8f51ea5f17c98b0f Reviewed-on: https://review.coreboot.org/c/coreboot/+/78007 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-20cpu/x86/mtrr/debug: use MTRR_PHYS_MASKFelix Held
Instead adding 1 to the result of MTRR_PHYS_BASE(index) to get the variable MTRR's mask MSR number, use the MTRR_PHYS_MASK macro. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ieecc57feb25afa83f3a53384e5a286f2e4e82093 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78006 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-20cpu/x86/mtrr/debug: use msr_t parameter in display_mtrr_fixed_typesFelix Held
Now that no local union definitions are used any more, pass the msr data to display_mtrr_fixed_types as an msr_t type parameter instead of a uint64_t parameter. Also rename the parameter from msr to msr_data to be more specific that this parameter is the MSR contents and not the MSR number. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iafde64129acc4bf9f01816de21c7793edfc1a799 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78005 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-20cpu/x86/mtrr/debug: make local MSR variables constFelix Held
In the functions the local MSR variables are only written once by rdmsr calls at the beginning of the function and then only read, so those can be made const. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I1be6a5158c0c06abe128e9394d6001c40a8d4cbb Reviewed-on: https://review.coreboot.org/c/coreboot/+/78004 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-09-20cpu/x86/mtrr/debug: drop unnecessary MSR unionFelix Held
Commit 407e00dca06e ("include/cpu/msr.h: transform into an union") changed the msr_t type to a union that allows accessing the full 64 bit via the raw element, so there's no need to wrap it again in another union for the full 64 bit access. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I750307297283802021fac19e2cdf5faa12ede196 Reviewed-on: https://review.coreboot.org/c/coreboot/+/78003 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
2023-09-14x86: Add .data section support for pre-memory stagesJeremy Compostella
x86 pre-memory stages do not support the `.data` section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of `.data` section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage for Raptor Lake has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some `.data` symbols in the `_bss` region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Other platforms do not have that limitation. Hence, resolving it would help to align code and reduce compilation based restriction (cf. the use of `ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot code). We identified three cases to consider: 1. eXecute-In-Place pre-memory stages - code is in SPINOR - data is also stored in SPINOR but must be linked in Cache-As-RAM and copied there at runtime 2. `bootblock` stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different 3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`). eXecute-In-Place pre-memory stages (#1) require the creation of a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) but to be stored right after the code (LMA). Here is the output `readelf --segments` on a `romstage.debug` ELF binary. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20 LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4 Section to Segment mapping: Segment Sections... 00 .text 01 .data Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they are totally different for the Segment 1 holding the `.data` section. Since we need the data section `VirtAddr` to be in the Cache-As-Ram and its `PhysAddr` right after the `.text` section, the use of a new segment is mandatory. `bootblock` (#2) also uses this new segment to store the data right after the code and load it to Cache-As-RAM at runtime. However, the code involved is different. Not eXecute-In-Place pre-memory stages (#3) do not really need any special work other than enabling a data section as the code and data VMA / LMA translation vector is the same. TEST=#1 and #2 verified on rex and qemu 32 and 64 bits: - The `bootblock.debug`, `romstage.debug` and `verstage.debug` all have data stored at the end of the `.text` section and code to copy the data content to the Cache-As-RAM. - The CBFS stages included in the final image has not improperly relocated any of the `.data` section symbol. - Test purposes global data symbols we added in bootblock, romstage and verstage are properly accessible at runtime #3: for "Intel Apollolake DDR3 RVP1" board, we verified that the generated romstage ELF includes a .data section similarly to a regular memory enabled stage. Change-Id: I030407fcc72776e59def476daa5b86ad0495debe Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-09-12arch/x86: Reduce max phys address size for Intel TME capable SoCsJeremy Compostella
On Intel SoCs, if TME is supported, TME key ID bits are reserved and should be subtracted from the maximum physical addresses available. BUG=288978352 TEST=Verified that DMAR ACPI table `Host Address Width` field on rex went from 45 to 41. Signed-off-by: Cliff Huang <cliff.huang@intel.com> Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Change-Id: I9504a489782ab6ef8950a8631c269ed39c63f34d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77613 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-09-12cpu/intel: Move is_tme_supported() from soc/intel to cpu/intelJeremy Compostella
It makes the detection of this feature accessible without the CONFIG_SOC_INTEL_COMMON_BLOCK_CPU dependency. BUG=288978352 TEST=compilation Change-Id: I005c4953648ac9a90af23818b251efbfd2c04043 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/77697 Reviewed-by: Bora Guvendik <bora.guvendik@intel.com> Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-09-08arch to drivers/intel: Fix misspellings & capitalization issuesMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic52f01d1d5d86334e0fd639b968b5eed43a35f1d Reviewed-on: https://review.coreboot.org/c/coreboot/+/77633 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-08-21cpu/x86/smm: Don't save EFERArthur Heymans
The EFER MSR is in the SMM save state and RSM properly restores it. Returning to 32bit mode was only done so that fxsave was done in the same mode as fxrstor, but this is no longer done. See commit 1efca4d570 (cpu/x86/smm: Drop fxsave/fxrstor logic) TESTED on qemu: the smihandler works fine. Change-Id: Ie0e9584afd1f08f51ca57da5c4350042699f130d Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68895 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-08-08cpu/amd/pi/00730F01: Use common code for mp_initArthur Heymans
TEST=APU2 still boots and doesn't show any new errors in dmesg. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ia9f0eb3df8fd2dfe395f616da981cc3a0cd3b29d Reviewed-on: https://review.coreboot.org/c/coreboot/+/64891 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-08-06cpu: Add SPDX license headers to MakefilesMartin Roth
To help identify the licenses of the various files contained in the coreboot source, we've added SPDX headers to the top of all of the .c and .h files. This extends that practice to Makefiles. Any file in the coreboot project without a specific license is bound to the license of the overall coreboot project, GPL Version 2. This patch adds the GPL V2 license identifier to the top of all makefiles in the cpu directory that don't already have an SPDX license line at the top. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I3033f2a9eebc75220f7666325857b3ddd60c8f75 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68979 Reviewed-by: Tim Crawford <tcrawford@system76.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2023-08-05src/*/post_code.h: Change post code prefix to POSTCODEYuchen He
The prefix POSTCODE makes it clear that the macro is a post code. Hence, replace related macros starting with POST to POSTCODE and also replace every instance the macros are invoked with the new name. The files was changed by running the following bash script from the top level directory. header="src/soc/amd/common/block/include/amdblocks/post_codes.h \ src/include/cpu/intel/post_codes.h \ src/soc/intel/common/block/include/intelblocks/post_codes.h" array=`grep -r "#define POST_" $header | \ tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2` for str in $array; do splitstr=`echo $str | cut -d '_' -f2-` grep -r $str src | cut -d ':' -f 1 | \ xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g" done Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad Signed-off-by: Yuchen He <yuchenhe126@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
2023-08-04cpu: Get rid of CPU_SPECIFIC_OPTIONSElyes Haouas
Remove dummy CPU_SPECIFIC_OPTIONS. Change-Id: I267b2a7c6dfc887b572e1b63b0f59fbfa4d20f0e Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76681 Reviewed-by: Martin L Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-12cpu/amd/mtrr: Use newer function for resource declarationArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I62f34a12bc5c4807638ddcb39fa5e450d99511fe Reviewed-on: https://review.coreboot.org/c/coreboot/+/76277 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-12cpu/intel/microcode: Drop unnecessary alignment for split microcodeSubrata Banik
This patch drops the unnecessary alignment of 64 bytes that was introduced when implementing the split Intel microcode packing logic into CBFS. - The 16-byte alignment that is already used for Intel microcode is sufficient. - Removes unnecessary alignment check of 64 bytes against an AMD platform specific config. TEST=Able to build and boot google/rex without any functional impact. Change-Id: Icc44e9511e321592de7ab8d1346103d0a9951c9b Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76397 Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-07-08cpu/x86/lapic: Fix regression with X2APIC_LATE_WORKAROUNDKyösti Mälkki
This patch fixes the boot hang due to commit 053a45bcdb3ccf8 ("cpu/x86/lapic: Fix X2APIC_ONLY regression") on platform which selects X2APIC_LATE_WORKAROUND config. [EMERG] Switching from X2APIC to XAPIC mode is not implemented. Without this patch: Boot gets stuck inside at BS_WRITE_TABLES when enable_lapic() gets called after X2APIC mode has been enabled. The fix is to change enable_lapic() to track when late enablement for X2APIC mode happens with X2APIC_LATE_WORKAROUND. TEST=Able to build and boot google/rex to chromeos. Change-Id: I41e72380e9cfb59721d0df607ad875d7b6546974 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76384 Reviewed-by: Subrata Banik <subratabanik@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-07-08cpu: Enable per-CPUID microcode loading in CBFSSubrata Banik
The current design of the `ucode-<variant>.bin` file combines all possible microcode per cpuid into a unified blob. This model increases the microcode loading time from RW CBFS due to higher CBFS verification time (the bigger the CBFS binary the longer the verification takes). This patch creates a provision to pack individual microcodes (per CPUID) into the CBFS (RO and RWs). Implementation logic introduces CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config which relies on converting Intel CPU microcode INC file into the binary file as per format specified as in `cpu_microcode_$(CPUID).bin`. For example: Intel CPU microcode `m506e3.inc` to convert into `cpu_microcode_506e3.bin` binary file for coreboot to integrate if CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config is enabled. Another config named CPU_INTEL_UCODE_SPLIT_BINARIES is used to specify the directory name (including path) that holds the split microcode binary files per CPUID for each coreboot variants. For example: if google/kunimitsu had built with Intel SkyLake processor with CPUID `506e3` and `506e4` then CPU_INTEL_UCODE_SPLIT_BINARIES refers to the directory path that holds the split microcode binary files aka cpu_microcode_506e3.bin and cpu_microcode_506e4.bin. Refer to the file representation below: |---3rdparty | |--- blobs | | |--- mainboard | | | |--- google | | | | |--- kunimitsu | | | | | |--- microcode_inputs | | | | | | |--- kunimitsu | | | | | | | |--- cpu_microcode_506e3.bin | | | | | | | |--- cpu_microcode_506e4.bin Users of this config option requires to manually place the microcode binary files per CPUIDs as per the given format (`cpu_microcode_$(CPUID).bin`) in a directory. Finally specify the microcode binary directory path using CPU_UCODE_SPLIT_BINARIES config. Additionally, modified the `find_cbfs_microcode()` logic to search microcode from CBFS by CPUID. This change will improve the microcode verification time from the CBFS, and will make it easier to update individual microcodes. BUG=b:242473942 TEST=emerge-rex sys-firmware/mtl-ucode-firmware-private coreboot-private-files-baseboard-rex coreboot Able to optimize ~10ms of boot time while loading microcode using below configuration. CONFIG_CPU_MICROCODE_CBFS_SPLIT_BINS=y CONFIG_CPU_UCODE_SPLIT_BINARIES="3rdparty/blobs/mainboard/ $(CONFIG_MAINBOARD_DIR)/microcode_inputs" Without this patch: 10:start of ramstage 1,005,139 (44) 971:loading FSP-S 1,026,619 (21,479) > RO/RW-A/RW-B CBFS contains unified cpu_microcode_blob.bin Name Offset Type Size Comp ... cpu_microcode_blob.bin 0x1f740 microcode 273408 none intel_fit 0x623c0 intel_fit 80 none ... ... bootblock 0x3ee200 bootblock 32192 none With this patch: 10:start of ramstage 997,495 (43) 971:loading FSP-S 1,010,148 (12,653) > RO/RW-A/B CBFS that stores split microcode files per CPUID FMAP REGION: FW_MAIN_A Name Offset Type Size Comp fallback/romstage 0x0 stage 127632 none cpu_microcode_a06a1.bin 0x1f340 microcode 137216 none cpu_microcode_a06a2.bin 0x40bc0 microcode 136192 none ... ... ecrw 0x181280 raw 327680 none fallback/payload 0x1d1300 simple elf 127443 none At reset, able to load the correct microcode using FIT table (RO CBFS) [NOTE ] coreboot-coreboot-unknown.9999.3ad3153 Sat May 20 12:29:19 UTC 2023 x86_32 bootblock starting (log level: 8)... [DEBUG] CPU: Genuine Intel(R) 0000 [DEBUG] CPU: ID a06a1, MeteorLake A0, ucode: 00000016 Able to find `cpu_microcode_a06a1.bin` on google/rex with ES1 CPU stepping (w/ CPUID 0xA06A1) (from RW CBFS) localhost ~ # cbmem -c -1 | grep microcode [DEBUG] microcode: sig=0xa06a1 pf=0x80 revision=0x16 [INFO ] CBFS: Found 'cpu_microcode_a06a1.bin' @0x407c0 size 0x21800 in mcache @0x75c0d0e0 [INFO ] microcode: Update skipped, already up-to-date Signed-off-by: Subrata Banik <subratabanik@google.com> Change-Id: Ic7db73335ffa25399869cfb0d59129ee118f1012 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75357 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-07-08cpu/intel/microcode: Avoid Pre-RAM microcode update if FIT enableSubrata Banik
This patch changes the default behaviour of the MICROCODE_UPDATE_PRE_RAM config for the platform with FIT (CPU_INTEL_FIRMWARE_INTERFACE_TABLE) enabled. If FIT is enabled then microcode update will be taken care of by FIT at pre-cpu reset hence, microcode update at pre-ram phase can be skipped. BUG=b:242473942 TEST=Able to build and boot google/rex with MICROCODE_UPDATE_PRE_RAM remains disabled. No functional impact. Without this patch: CONFIG_MICROCODE_UPDATE_PRE_RAM=y With this patch: CONFIG_MICROCODE_UPDATE_PRE_RAM is not set Change-Id: I603e064115869aba2bffa5589ffe47a44a90b848 Signed-off-by: Subrata Banik <subratabanik@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76234 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de>
2023-07-06cpu/x86: Add some notes about XAPIC/X2APICKyösti Mälkki
At the time of writing SMM runtime does not make register accesses to LAPIC registers, but such breakage has been reported. S3 resume failure, where OS switched back from X2APIC to XAPIC mode, can be reproduced with a sandybridge SKU that has VT-d disabled. Change-Id: I300ba87c3d8fde548dbaf95703bd7e2fe54cff57 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76196 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-07-06cpu/x86/lapic: Fix X2APIC_ONLY regressionKyösti Mälkki
Some ancient CPUs may have had LAPIC disabled at power-up, so semantically enable_lapic() should always come before attempting to access the register banks. With X2APIC_ONLY option it is necessary to ensure enable_lapic() is called prior to any other lapic register space accesses, since the XAPIC mode MMIO accessors are optimised away build-time and CPU's do not yet initialise for X2APIC mode at reset. Change-Id: I96eaa5c43108c802375e184e0c68b5091ca0198f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76195 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-07-03cpu/x86: Reduce scope of MTRR functions used locallyKyösti Mälkki
Change-Id: Ic00358ee5b05d011a95d85ec355adef71c39a529 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76193 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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-04cpu/x86/smm: Drop fxsave/fxrstor logicArthur Heymans
Since we now explicitly compile both ramstage and smihandler code without floating point operations and associated registers we don't need to save/restore floating point registers. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I180b9781bf5849111501ae8e9806554a7851c0da Reviewed-on: https://review.coreboot.org/c/coreboot/+/75317 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-05-31cpu/x86/mp_init: Use clflush to write SIPI data back to RAMJeremy Compostella
Improve boot time performances by replacing the wbinvd instruction with multiple clflush to ensure that the SIPI data is written back to RAM. According to some experimental measurements, the wbinvd execution takes between 1.6 up and 6 milliseconds to complete. In the case of the SIPI data, wbinvd unnecessarily flushes and invalidates the entire cache. Indeed, the SIPI module is quite small (about 400 bytes) and cflush'ing the associated cache lines is almost instantaneous, typically less than 100 microseconds. BUG=b/260455826 TEST=Successful boot on Skolas and Rex board Change-Id: I0e00db8eaa6a3cb41bec3422572c8f2a9bec4057 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Suggested-by: Erin Park <erin.park@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75391 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-05-27libpayload;arch,cpu/x86: drop USE_MARCH_586 Kconfig optionFelix Held
Only the Intel Quark SoC selected this option and that SoC was dropped in commit 531023285ea4 ("soc/intel/quark: Drop support"), so drop this Kconfig option too. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic4f1c7530cd8ac7a1945b1493a2d53a7904daa06 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75473 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-27cpu/intel/haswell: Add Broadwell Trad µcode updatesAngel Pons
Include µcode updates for Broadwell Trad(itional) CPUs. Tested on Asrock Z97 Extreme6 with an i5-5675C, µcode update loads: CPU id(40671) ucode:00000022 Intel(R) Core(TM) i5-5675C CPU @ 3.10GHz Change-Id: I54bb2e767f008b21dcf5d176f8b92a56dcabd129 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72894 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
2023-05-26cpu/x86/sse_enable.inc: Remove unused fileArthur Heymans
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I384d2f5148cd99ed4282acefaf19885e49d2e79d Reviewed-on: https://review.coreboot.org/c/coreboot/+/75319 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-25cpu/Kconfig: Remove MMX config optionArthur Heymans
Now -mno-mmx is statically set in arch/x86 so remove this option. Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Change-Id: I0da7f9f1afb0c8ecae728c45591897ca1d4dfb11 Reviewed-on: https://review.coreboot.org/c/coreboot/+/75318 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-05-23cpu/x86/smm_stub.S: Fix commentArthur Heymans
The comment got stale because a few elements from the struct got dropped. Change-Id: I83469e24dfab82b9182accb549960dd06d81e02f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68894 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-23cpu/x86/smm_stub.S: Update commentArthur Heymans
%ebp is used for the stack frame on which the fxrstor address is pushed. entry64.inc does not trash it so that's fine. Change-Id: If027437dccac9ad507ceb534c6aae77ea43bdfda Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68896 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-21Kconfig: Get rid of named choice LAPIC_ACCESS_MODEMartin Roth
The named choice isn't needed here, so get rid of it. This fixes the build notice: build/auto.conf:notice: override:reassigning to symbol LAPIC_ACCESS_MODE Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I70628007319a0ee2830dc4c9cb3b635d8190264b Reviewed-on: https://review.coreboot.org/c/coreboot/+/75133 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-18cpu/qemu-x86/cache_as_ram_bootblock: drop duplicated post codeAlexander Goncharov
Before the bootblock stage starts setting up the CAR mode, it sends `POST_BOOTBLOCK_CAR` POST code. However, before the definition for `POST_BOOTBLOCK_CAR` was introduced in the commit 0d34a50a360228138ade623e799b03eaba83b0a5 , the value `0x20` was used. At that point, `0x20` means "entry into CAR mode" and `0x21` means "the cache memory region is cleared". Right now we are sending the same POST code twice, which makes no sense. So we can do the following (todo: drop me after we decided which one is more appropriate): 1) Drop it (current patchset does exactly that) 2) Introduce POST code similar to POST_SOC_CLEARING_CAR and use it before the cache memory region is cleared. Change-Id: I5d9014c788abdf5a4338c9e199138d1e514450b3 Signed-off-by: Alexander Goncharov <chat@joursoir.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73744 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
2023-05-16cpu/amd/pi/00730f01/Kconfig: use hexadecimal CPU number in ACPIFelix Held
To match the rest of coreboot, also change this ACPI_CPU_STRING Kconfig setting to use hexadecimal CPU numbers for the ACPI CPU objects. Since this SoC has a maximum of 4 cores, this change will make no difference in the runtime behavior. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I58f9c4672f34de0defafc300d2d291f4ad6196ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/75251 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-05-13acpi/Kconfig: move \_SB scope out of ACPI_CPU_STRINGFelix Held
In ACPI 1.0 the processor objects were inside the \_PR scope, but since ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS compatibility, but apart from that the \_PR scope is deprecated. coreboot already uses the \_SB scope for the processor devices everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the format string inside the 3 snprintf statements that use the ACPI_CPU_STRING. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2023-05-13cpu,nb/amd/pi/00730F01: dynamically generate CPU devicesFelix Held
Instead of having the maximum number of possible CPU objects defined in the DSDT, dynamically generate the number of needed CPU devices in the SSDT like it's done on all other x86 platforms in coreboot. TEST=APU2 still boots and Linux doesn't show any ACPI errors with this patch applied and it prints "ACPI: \_SB_.P000: Found 2 idle states". Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Id6f057ad130a27b371722fa66ce0a982afc43c6c Reviewed-on: https://review.coreboot.org/c/coreboot/+/73073 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>