summaryrefslogtreecommitdiff
path: root/src/cpu
AgeCommit message (Collapse)Author
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>
2023-04-28treewide: Add missing include guards to chip.hJan Samek
Some of the chip.h files in the tree are missing the include guards. This patch adds them in order to avoid potential redefinions of symbols contained in these headers, when they are included multiple times in static.c generated by sconfig. Change-Id: I550a514e72a8dd4db602e7ceffccd81aa36446e3 Signed-off-by: Jan Samek <jan.samek@siemens.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74749 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2023-04-26cpu/intel/speedstep: Separate single SSDT CPU entryKyösti Mälkki
Change-Id: Ibe5d84c8fbff79cc73b01eee0980cbed71ceb506 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74400 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-22cpu/amd/pi/00730F01: rename fixme.c to cpu_io_init.cFelix Held
Now that the code is in a much better shape and uses native coreboot functionality to perform the initialization, rename the file from fixme.c to cpu_io_init.c to be more descriptive of what it does. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I97d1ac2b12c624210c570f189f825409bd64f318 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74659 Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-21cpu/amd/pi/00730F01/fixme: replace some magic numbersFelix Held
TEST=Timeless build for pcengines/apu2 results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: If96f4655a3b4dc621ef77c4d97d2927565d634ec Reviewed-on: https://review.coreboot.org/c/coreboot/+/74617 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-21cpu/amd/pi/00730F01/fixme: use coreboot's PCI access functionsFelix Held
Use coreboot's native PCI access functions instead of using the vendorcode's PCI access functions to set up the CPU IO routing in function 1 of the HT PCI device. This file still has room for improvement, but at least it's now using coreboot-native functionality. Stoneyridge has a nicer implementation, but looking into possibly unifying those is out of scope for this patch. TEST=None Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ieecc0e5f6576a838d79220b061de81e21b5d976c Reviewed-on: https://review.coreboot.org/c/coreboot/+/74616 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-21include/cpu/amd/mtrr: rename functions to get top of memory regionsFelix Held
Rename amd_topmem and amd_topmem2 to get_top_of_mem_below_4gb and get_top_of_mem_above_4g to make it clearer what those functions return. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ic6e98d94c731af74aea0ce276a9a7e4867e3986f Reviewed-on: https://review.coreboot.org/c/coreboot/+/74589 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2023-04-18src/cpu/power9: move part of scom.h to scom.cSergii Dmytruk
Reset function, constants and include are not used outside of scom.c and not going to be. Change-Id: Iff4e98ae52c7099954f0c20fcb639eb87af15534 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/67055 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
2023-04-17cpu,soc/intel: Separate single SSDT CPU entryKyösti Mälkki
Change-Id: Ic75e8907de9730c6fdb06dbe799a7644fa90f904 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74399 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
2023-04-14cpu,soc/intel: Sync ACPI CPU object implementationsKyösti Mälkki
Take variable names from soc/intel and adjust counter to start from zero. Change-Id: I14e1120e74e1bd92acd782a53104fabfb266c3b5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74396 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-14cpu,soc/intel: Use acpigen_write_processor_device()Elyes Haouas
Use acpigen_write_processor_device() instead of deprecated acpigen_write_processor(). Change-Id: I1448e0a8845b3a1beee0a3ed744358944faf66d8 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72488 Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-14cpu/intel/speedstep: Refactor P-state coordinationKyösti Mälkki
Change-Id: I12462f271821d3d8fe3324d84a65c2341729591e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74398 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-14intel/i82371eb,speedstep: Use dev_count_cpu()Kyösti Mälkki
Change-Id: I8582d401c72ad44137f117315c5c6869654c3e99 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74397 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-04-13cpu/x86/mp_init.c: Set topology on BSPArthur Heymans
The BSP might have non-zero lapicid so set the topology accordingly, without assuming it is 0. This fixes a cpu exception on at least Intel Meteorlake. This was caused by FSP CPU PPI being giving incorrect information about the BSP topology. This problem was introduced by 8b8400a "drivers/fsp2_0/mp_service_ppi: Use struct device to fill in buffer" which sets the PPI struct based on struct device. TESTED on google/rex Change-Id: I3fae5efa86d8efc474c129b48bdfa1d1e2306acf Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/74374 Reviewed-by: Subrata Banik <subratabanik@google.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Reviewed-by: Tarun Tuli <taruntuli@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/x86/topology: Add code to fill in topology on struct pathArthur Heymans
This is needed to generate MADT and SRAT where lapicid for threads need to be added last. When CPUID leaf '0xB' is not present assume some defaults that would result in identical ACPI code generation. Change-Id: I2210eb9b663dd90941a64132aa7154440dc7e5a9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69222 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/mp_init.c: Only enable CPUs once they execute codeArthur Heymans
On some systems the BSP cannot know how many CPUs are present in the system. A typical use case is a multi socket system. Setting the enable flag only on CPUs that actually exist makes it more flexible. Change-Id: I6c8042b4d6127239175924f996f735bf9c83c6e8 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68892 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/smm_module_loader.c: Fix up CPU index locallyArthur Heymans
Don't pass the stub params to the mp_init code. Change-Id: I070bc00ae5e5bceb6c5b90ea833cc057dd41f6cc Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64802 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/x86/mp_init.c: Generate a C header to get start32 offsetArthur Heymans
In the current design the relocatable parameters are used to know the offset of the 32bit startpoint. This requires back and forward interaction between the stub, the loader and the mp init code. This makes the code hard to read. This is static information known at buildtime, so a better way to deal with this is to generate a header that contains this offset. Change-Id: Ic01badd2af11a6e1dbc27c8e928916fedf104b5b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64625 Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-06cpu/x86/mp_init.c: Keep track of initial lapic ID inside device_pathArthur Heymans
It's quite confusing to keep track of lapic ID inside the device struct and initial lapic ID inside an array. Change-Id: I4d9f8d23c0b0e5c142f6907593428d8509e4e7bb Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64342 Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-04cpu/x86/64bit/Makefile: use all_x86 make targetFelix Held
Use the newly introduced 'all_x86' make target to add the mode_switch.S compilation unit to all stages that run on the x86 cores, but not to verstage on PSP. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I8950375d31557d9a38169869c1d250417261c31c Reviewed-on: https://review.coreboot.org/c/coreboot/+/74197 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2023-04-04cpu/x86/64bit/Makefile: use verstage_x86 make targetFelix Held
Use the 'verstage_x86' make target for the mode_switch.S compilation unit instead of making adding it to the 'verstage' target depending on VBOOT_STARTS_BEFORE_BOOTBLOCK not being selected. The only case where VBOOT_STARTS_BEFORE_BOOTBLOCK is selected is the verstage on PSP case, so I find using the 'verstage_x86' target here a bit easier to understand. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Iab618d4b9e325b07a648b91fcdce99c63644fbfc Reviewed-on: https://review.coreboot.org/c/coreboot/+/74196 Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-04-04cpu/x86/lapic,pae,tsc/Makefile: use all_x86 targetFelix Held
Use the newly introduced 'all_x86' make target to add the compilation unit to all stages that run on the x86 cores, but not to verstage on PSP. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I181c3207bb1ebe9c5080ef3a3cdda8146ed05822 Reviewed-on: https://review.coreboot.org/c/coreboot/+/74152 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-03-13cpu/x86/cache: CLFLUSH programs to memory before runningArthur Heymans
When cbmem is initialized in romstage and postcar placed in the stage cache + cbmem where it is run, the assumption is made that these are all in UC memory such that calling INVD in postcar is OK. For performance reasons (e.g. postcar decompression) it is desirable to cache cbmem and the stage cache during romstage. Another reason is that AGESA sets up MTRR during romstage to cache all dram, which is currently worked around by using additional MTRR's to make that UC. TESTED on asus/p5ql-em, up/squared on both regular and S3 resume bootpath. Sometimes there are minimal performance improvements when cbmem is cached (few ms). Change-Id: I7ff2a57aee620908b71829457ea0f5a0c410ec5b Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37196 Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com> Reviewed-by: Kapil Porwal <kapilporwal@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-03-10mp_init: Wait longer for APs to check inPatrick Rudolph
On IBM/SBP1 with 384 cores it takes a while for all APs to check in. Use linear scaling instead of hardcoding an arbitrary limit for the timeout. Change-Id: If020a3fa985bfc7fd2f0aa836dc04e6647a1a450 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73369 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shuo Liu <shuo.liu@intel.com> Reviewed-by: TangYiwei Reviewed-by: Naresh <naresh.solanki.2011@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2023-03-08cpu/x86,amd: drop unused LOGICAL_CPUS Kconfig symbolFelix Held
The LOGICAL_CPUS Kconfig option is always true and also not user- configurable, so it can be dropped. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: Ie4866de003058ec0f99495b405e26dfd7ba1fa28 Reviewed-on: https://review.coreboot.org/c/coreboot/+/73553 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-03-05cpu/x86/smm: Add PCI resource store functionalityRobert Zieba
In certain cases data within protected memmory areas like SMRAM could be leaked or modified if an attacker remaps PCI BARs to point within that area. Add support to the existing SMM runtime to allow storing PCI resources in SMRAM and then later retrieving them. BRANCH=guybrush BUG=b:186792595 TEST=builds Signed-off-by: Robert Zieba <robertzieba@google.com> Change-Id: I23fb1e935dd1b89f1cc5c834cc2025f0fe5fda37 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67931 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
2023-02-27tree: Move 'asmlinkage' before type 'void'Elyes Haouas
Move 'asmlinkage' before the function type for consistency. Change-Id: I293590ef917b78c6ed3d151cd0080e42d0f10651 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/73259 Reviewed-by: Felix Singer <felixsinger@posteo.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-17cpu/amd/pi/00730F01/model_16_init: use CPUID_FROM_FMS macroFelix Held
Replace the magic number with the CPUID_FROM_FMS macro to make it easier to read. TEST=Resulting image of timeless build for pcengines/apu2 is identical Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I15480dc883b65b5ffaf0cd38cf4e1f7b2222022e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73069 Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-17cpu/amd/pi/00730F01/model_16_init: use CPUID_ALL_STEPPINGS_MASKFelix Held
Instead of having two entries for two different steppings of the same family and model combination using the CPUID_EXACT_MATCH_MASK, just have one entry that uses CPUID_ALL_STEPPINGS_MASK to cover all steppings. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0118bb9b4b0be4d954a657d50789addca08a784e Reviewed-on: https://review.coreboot.org/c/coreboot/+/73068 Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-02-15cpu/x86/smm: Enable setting SMM console log level from mainboardJohnny Lin
Add a Kconfig RUNTIME_CONFIGURABLE_SMM_LOGLEVEL that enables mainboard to override mainboard_set_smm_log_level for SMM log level. This can let SMM have different log level than other stages for more flexibility. Another reason is that getting certain data that requires searching from flash VPD or CMOS is not very ideal to be done in SMM, so in this change the value can be passed via the member variable in struct smm_runtime and be referenced directly in SMM. One example is that mainboard can get the desired SMM log level from VPD/CMOS, and pass SMM console log level via the variable and in SMM it can be referenced in get_console_loglevel() override function directly. Tested=On OCP Delta Lake, verified SMM log level can be overridden. Change-Id: I81722a4f1bf75ec942cc06e403ad702dfe938e71 Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/49460 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
2023-02-09arch/x86/include/cpu: introduce CPU_TABLE_END CPU table terminatorFelix Held
Instead of having a magic entry in the CPU device ID table list to tell find_cpu_driver that it has reached the end of the list, introduce and use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID instead of the 0 in the CPU_TABLE_END definition. TEST=Timeless build for Mandolin results in identical image. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Suggested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
2023-02-08cpu/intel/model_206ax/model_206ax_init: use CPUID_ALL_STEPPINGS_MASKFelix Held
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry per family & model combination and not one per stepping. TEST=Thinkpad x230 with Ivy Bridge stepping 9 CPU still boots with this patch applied. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I46020d5b1b1fba8449c3823fac1369e5670d91c0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72854 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>
2023-02-08arch/x86/cpu: introduce and use device_match_maskFelix Held
Instead of always doing exact matches between the CPUID read in identify_cpu and the device entries of the CPU device ID table, offer the possibility to use a bit mask in the CPUID matching. This allows covering all steppings of a CPU family/model with one entry and avoids that case of a missing new stepping causing the CPUs not being properly initialized. Some of the CPU device ID tables can now be deduplicated using the CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this patch. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0540b514ca42591c0d3468307a82b5612585f614 Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2023-02-08mb/samsung: Enable VBOOT_VBNV_FLASHYu-Ping Wu
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with VBOOT_VBNV_FLASH for samsung boards lumpy and stumpy. 0x8000 unused flash space is allocated for RW_NVRAM. Previously BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES was selected for CPU_INTEL_HASWELL, CPU_INTEL_MODEL_{2065X,206AX} and others (see [2]). However, there seems to be no particular reason on those platforms. We've dropped the config for haswell. Now drop it for CPU_INTEL_MODEL_{2065X,206AX}, so that VBOOT_VBNV_FLASH can be enabled. [1] https://web.archive.org/web/20230115020833/https://issuetracker.google.com/issues/235293589?pli=1 [2] commit 6c2568f4f58b9a1b209c9af36d7f980fde784f08 ("drivers/spi: Add BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES config") BUG=b:235293589 TEST=./util/abuild/abuild -a -t SAMSUNG_LUMPY -x Change-Id: I833edd4f7a328b21e81c971ba8a9aec0aad7d3d3 Signed-off-by: Yu-Ping Wu <yupingso@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70296 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Yidi Lin <yidilin@google.com>
2023-02-07src: Move POST_BOOTBLOCK_CAR to common postcodes and use itMartin Roth
This moves the definition for POST_BOOTBLOCK_CAR from the intel-specific postcodes into the common postcode list, and uses it for the cache-as-RAM init as needed. Because POST_BOOTBLOCK_CAR was set to 0x20 in some spots and 0x21 in most of the others, the values were consolidated into 0x21. This will change the value on some platforms. Any conflicts should get sorted out later in the conversion process. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: I8527334e679a23006b77a5645f919aea76dd4926 Reviewed-on: https://review.coreboot.org/c/coreboot/+/71596 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
2023-02-07tree: Drop repeated wordsAlexander Goncharov
Found-by: linter Change-Id: I7c6d0887a45fdb4b6de294770a7fdd5545a9479b Signed-off-by: Alexander Goncharov <chat@joursoir.net> Reviewed-on: https://review.coreboot.org/c/coreboot/+/72795 Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2023-01-09treewide: Remove unused <cpu/amd/msr.h>Elyes Haouas
Change-Id: Id24a7c7db24f49672df9d5ceefec5b7596f23e09 Signed-off-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/64939 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-12-23cpu/x86: Set up a separate stack for APsArthur Heymans
APs use a lot less stack, so set up a separate stack for those in .bss. Now that CPU_INFO_V2 is the only code path that is used, there is no need to align stacks in c_start.S. Change-Id: I7a681a2e3003da0400843daa5d6d6180d952abf5 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69123 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2022-12-17Add option to use Ada code in romstageJeremy Compostella
If selected, libgnat is linked into romstage. In addition, a call to romstage_adainit() is added to support Ada program data initialization. BUG=b:252792591 BRANCH=firmware-brya-14505.B TEST=Ada code compiles for romstage and loads successfully Change-Id: I74f0460f6b14fde2b4bd6391e1782b2e5b217707 Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/70274 Reviewed-by: Tarun Tuli <taruntuli@google.com> Reviewed-by: Nick Vaccaro <nvaccaro@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2022-12-16cpu/intel: Fix clearing MTRR for clang 64bitArthur Heymans
Clang generates R_X86_64_32S symbols that get truncated. TESTED: - prodrive/hermes boots with GCC and clang - MTRR are properly cleared (tested by filling in both MTRR_FIX_64K_00000 and MTRR_FIX_4K_F8000 before clearing) Change-Id: I6a5139f7029b6f35b44377f105dded06f6d9cbf9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/69388 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2022-12-16cpu/x86/mtrr: rename local cpu_idx variable and make it constFelix Held
After the previous patch this local variable is no longer the mpinit CPU index, but the LAPIC ID, so rename it. Since it will only be set once, it can also be marked as const. Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I4fad4e1095478213727bee8586852f9d5a7d18e9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70798 Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
2022-12-15cpu/x86/mtrr: use lapicid instead of cpu_index callsFelix Held
The cpu_index function can't be used before mpinit, so use lapicid calls instead. This fixes the regression introduced by commit 4c3749884d71 ("cpu/x86/mtrr: Print cpu index number when set up MTRRs for BSP/APs") and also reverts also commit b3261661c703 ("cpu/x86/mtrr/mtrr: fix printk format strings"), since lapicid returns an unsigned int while cpu_index returns an unsigned long. TEST=Mandolin boots again and doesn't fail when it first tries to print the MTRR configuration Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Change-Id: I0d226704051ab171891775a618ce7897b74fde16 Reviewed-on: https://review.coreboot.org/c/coreboot/+/70797 Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com> Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 08:35:26 +0000