This patch centralizes the MSEG location calculation. In the current
implementation, the calculation happens in smm_module_loader and
mp_init. When smm_module_loaderv2 was added, this calculation became
broken as the original calculation made assumptions based on perm_smbase.
The calculation is now located in smm_subregion (tseg_region.c), as the
MSEG is located within the TSEG (or SMM);
These patches have been tested on a Purism librem-l1um server.
Change-Id: Ic17e1a505401c3b2a218826dffae6fe12a5c15c6
Signed-off-by: Eugene Myers <edmyers@tycho.nsa.gov>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55628
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Xeon-SP Skylake Scalable Processor can have 36 CPU threads (18 cores).
Current coreboot SMM is unable to handle more than ~32 CPU threads.
This patch introduces a version 2 of the SMM module loader which
addresses this problem. Having two versions of the SMM module loader
prevents any issues to current projects. Future Xeon-SP products will
be using this version of the SMM loader. Subsequent patches will
enable board specific functionality for Xeon-SP.
The reason for moving to version 2 is the state save area begins to
encroach upon the SMI handling code when more than 32 CPU threads are
in the system. This can cause system hangs, reboots, etc. The second
change is related to staggered entry points with simple near jumps. In
the current loader, near jumps will not work because the CPU is jumping
within the same code segment. In version 2, "far" address jumps are
necessary therefore protected mode must be enabled first. The SMM
layout and how the CPUs are staggered are documented in the code.
By making the modifications above, this allows the smm module loader to
expand easily as more CPU threads are added.
TEST=build for Tiogapass platform under OCP mainboard. Enable the
following in Kconfig.
select CPU_INTEL_COMMON_SMM
select SOC_INTEL_COMMON_BLOCK_SMM
select SMM_TSEG
select HAVE_SMI_HANDLER
select ACPI_INTEL_HARDWARE_SLEEP_VALUES
Debug console will show all 36 cores relocated. Further tested by
generating SMI's to port 0xb2 using XDP/ITP HW debugger and ensured all
cores entering and exiting SMM properly. In addition, booted to Linux
5.4 kernel and observed no issues during mp init.
Original-Change-Id: I00a23a5f2a46110536c344254868390dbb71854c
Original-Signed-off-by: Rocky Phagura <rphagura@fb.com>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
(cherry picked from commit afb7a81478)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I76bb506de56c816f6c0635bfd990125b789c5877
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Rocky Phagura
Suggested by Nico Huber in CB:38765.
This placement makes the address calculation simpler and
makes its location indepedent of the number of CPUs.
As part of the change in the BIOS resource list address
calculation, the `size` variable was factored out of the
conditional in line 361, thus eliminating the else.
Original-Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d
Original-Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
(cherry picked from commit 076605bc92)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: Ie62e2bdccd2d09084cc39a0f2fe32df236c08cd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
To mitigate against sinkhole in software which is required on
pre-sandybridge hardware, the smm entry point needs to check if the
LAPIC base is between smbase and smbase + smmsize. The size needs to
be available early so add them to the relocatable module parameters.
When the smmstub is used to relocate SMM the default SMM size 0x10000
is provided. On the permanent handler the size provided by
get_smm_info() is used.
Original-Change-Id: I0df6e51bcba284350f1c849ef3d012860757544b
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/37288
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
(cherry picked from commit a3eb3df01c)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I4948639a513b196382eb38616fe872b72bb7e59e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
This update is a combination of all four of the patches so that the
commit can be done without breaking parts of coreboot. This possible
breakage is because of the cross-dependencies between the original
separate patches would cause failure because of data structure changes.
security/intel/stm
This directory contains the functions that check and move the STM to the
MSEG, create its page tables, and create the BIOS resource list.
The STM page tables is a six page region located in the MSEG and are
pointed to by the CR3 Offset field in the MSEG header. The initial
page tables will identity map all memory between 0-4G. The STM starts
in IA32e mode, which requires page tables to exist at startup.
The BIOS resource list defines the resources that the SMI Handler is
allowed to access. This includes the SMM memory area where the SMI
handler resides and other resources such as I/O devices. The STM uses
the BIOS resource list to restrict the SMI handler's accesses.
The BIOS resource list is currently located in the same area as the
SMI handler. This location is shown in the comment section before
smm_load_module in smm_module_loader.c
Note: The files within security/intel/stm come directly from their
Tianocore counterparts. Unnecessary code has been removed and the
remaining code has been converted to meet coreboot coding requirements.
For more information see:
SMI Transfer Monitor (STM) User Guide, Intel Corp.,
August 2015, Rev 1.0, can be found at firmware.intel.com
include/cpu/x86:
Addtions to include/cpu/x86 for STM support.
cpu/x86:
STM Set up - The STM needs to be loaded into the MSEG during BIOS
initialization and the SMM Monitor Control MSR be set to indicate
that an STM is in the system.
cpu/x86/smm:
SMI module loader modifications needed to set up the
SMM descriptors used by the STM during its initialization
Original-Change-Id: If4adcd92c341162630ce1ec357ffcf8a135785ec
Original-Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/33234
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: ron minnich <rminnich@gmail.com>
(cherry picked from commit ae438be578)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: Ic0131fcada9f43c9817c8a0a942d0419c7023130
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is some overlap between romstage and bootblock.
LPC setup and BAR initialization is now done twice.
The rationale is that the romstage should not depend too
much on the bootblock, since it can reside in a RO fmap
region.
Enabling the console will be done in a followup patch.
Change-Id: I4d0ba29111a5df6f19033f5ce95adcc0d9adc1fd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There is some overlap between things done in bootblock
and romstage like setting BARs.
Change-Id: Icd1de34c3b5c0f36f2a5249116d1829ee3956f38
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36759
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Console init in bootblock will be done in a separate CL.
Change-Id: Ia2405013f262d904aa82be323e928223dbb4296c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36795
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is more in line with how linker symbol for regions are defined.
Change-Id: I0bd7ae59a27909ed0fd38e6f7193816cb57e76af
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix regression with commit 0a4457f
lib/stage_cache: Refactor Kconfig options
AGESA platforms fail to resume from S3 suspend with
CBMEM_STAGE_CACHE=n. For the time being the root cause
is unknown.
Change-Id: I11db0c883b6e39473d02e92b14cb3c6302aa728e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36708
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Not all Rangeley SKUs have a fixed 100MHz BCLK.
As per BIOS Writer's Guide, BCLK is available in MSR_FSB_FREQ 0xCD[1:0].
Using fixed BCLK was causing wrong values of core frequencies in _PSS table
for SKUs that do not have BCLK=100MHz.
Change-Id: Id8e0244fab0283b74870950cb00a95aab2a7201f
Signed-off-by: Hannah Williams <hannah.williams@dell.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35348
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Note that due to UNKNOWN_TSC_RATE, each stage will have
a slow run of calibrate_tsc_with_pit(). This is easy enough
to fix with followup implementation of tsc_freq_mhz() for
the cpu.
Change-Id: I0f5e16993e19342dfc4801663e0025bb4cee022a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36525
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for x86_64 bootblock on qemu.
Introduce a new approach to long mode support. The previous patch set
generated page tables at runtime and placed them in heap. The new
approach places the page tables in memory mapped ROM.
Introduce a new tool called pgtblgen that creates x86 long mode compatible
page tables and writes those to a file. The file is included into the CBFS
and placed at a predefined offset.
Add assembly code to load the page tables, based on a Kconfig symbol and
enter long in bootblock.
The code can be easily ported to real hardware bootblock.
Tested on qemu q35.
Change-Id: Iec92c6cea464c97c18a0811e2e91bc22133ace42
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
While commented as 10 ms + 250 us, those delay loops actually
accounted for a total of 840 ms. And they seem unnecessary
as followup code has potentially infinite retries when
polling for status changes.
Tested on aopen/dxplplusu, dual-socket P4 Xeon HT model_f2x.
Change-Id: Ib7d1d66ed29c62d97073872f0b7809d719ac2324
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This solution is very generic and can in principle be implemented on
all arch/soc.
Instead trying to figure out which files can be removed from stages
and which cbmem_top implementations need with preprocessor, rename all
cbmem_top implementation to cbmem_top_romstage.
Mechanisms set in place to pass on information from rom- to ram-stage
will be placed in a followup commit.
Change-Id: If31f0f1de17ffc92c9397f32b26db25aff4b7cab
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36145
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The x86 timers are a bit of a mess. Cases where different stages use
different counters and timestamps use different counters from udelays.
The original intention was to only flip TSC_CONSTANT_RATE Kconfig
to NOT_CONSTANT_TSC_RATE. The name would be incorrect though, those
counters do run with a constant rate but we just lack tsc_freq_mhz()
implementation for three platforms.
Note that for boards with UNKNOWN_TSC_RATE=y, each stage will have a
slow run of calibrate_tsc_with_pit(). This is easy enough to fix with
followup implementation of tsc_freq_mhz() for the platforms.
Implementations with LAPIC_MONOTONIC_TIMER typically will not have
tsc_freq_mhz() implemented and default to UNKNOWN_TSC_RATE. However,
as they don't use TSC for udelay() the slow calibrate_tsc_with_pit()
is avoided.
Because x86/tsc_delay.tsc was using two different guards and nb/via/vx900
claimed UDELAY_TSC, but pulled UDELAY_IO implementation, we also switch
that romstage to use UDELAY_TSC.
Change-Id: I1690cb80295d6b006b75ed69edea28899b674b68
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33928
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some platforms lack a non-eviction mode and therefore caching the
whole ROM to speed up XIP stages can be dangerous as it could result
in eviction if too much of the ROM is being accessed. The solution is
to only cache a region, about the size of the stage that the bootblock
is about to load: verstage and/or romstage.
TODO: now a limit of 256KiB is set for the total amount of cache that
can be used. This should fit most use cases for the time being.
Change-Id: I94d5771a57ffd74d53db3e35fe169d77d7fbb8cd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This adds a common cbmem_top implementation to all coreboot target.
In romstage a static variable will be used to cache the result of
cbmem_top_romstage.
In ramstage if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is set a global variable
needs to be populated by the stage entry with the value passed via the
calling arguments. if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is not set the
same implementation as will be used as in romstage.
Change-Id: Ie767542ee25483acc9a56785ce20a885e9a63098
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Haswell and model_2065 implement a static set_msr_bit helper which
should be publicly available instead. Move it to cpu/x86.
Change-Id: I68b314c917f15fc6e5351de1c539d5a3ae646df8
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36338
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As preparation for x86_64 clean the assembly code and introduce
arch/ram_segs.h similar to existing arch/rom_segs.h.
Replace open coded segment values with the defines from the new
header.
Change-Id: Ib006cd4df59951335506b8153e9347450ec3403e
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36321
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The i82801ix_early_init is now called both in the bootblock and
romstage. The rationale behind setting this up twice is to ensure
bootblock-romstage compatibility in the future if for instance VBOOT
is used.
This moves the console init to the bootblock.
The romstage now runs uncached. Adding a prog_run hooks to set up an
MTRR to cache the romstage will be done in a followup patch.
The default size of 64KiB is not modified for the bootblock as trying
to fit both EHCI and SPI flash debugging needs a more space and 64KiB
is the next power of 2 size that fits it.
TESTED on Thinkpad X200.
Change-Id: I8f59736cb54377973215f35e35d2cbcd1d82c374
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
With CONFIG_C_ENVIRONMENT_BOOTBLOCK it makes more sense to rely on the
size of the bootblock over CONFIG_XIP_ROM_SIZE. To make this work,
only powers of 2 are allowed as bootblock size.
Change-Id: Ic8104ca9c51e4d2eccdb277e4c2111d2da662f3e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Also:
add some missing includes spotted by Jenkins.
Including <types.h>, is supposed to provide stdint and stddef.
Change-Id: I7bd999b59d1c0bdfa5999bf5805576f94c9a2390
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Similar to VMX and SMX also enable all GetSec leaves for Intel TXT.
Change-Id: I89620c2a98cfceaa785b1a798fafbf35cc99a0b2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
AGESA and binaryPI set the whole CACHE_ROM_SIZE to WRPROT during the
romstage and do not reference the CONFIG_XIP_ROM_SIZE symbol.
Change-Id: I548b9c9066d825c2f03749353b9990b2efddfd9c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A few notable changes:
- Microcode init is done in assembly during the CAR init.
- The DCACHE_BSP_STACK_SIZE is set to 0x2000, which is the same size
against which the romstage stack guards protected.
- The romstage mainboard_lpc_init() hook is removed in favor of the
existing bootblock_mainboard_early_init().
Change-Id: Iccd7ceaa35db49e170bfb901bbff1c1a11223c63
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This codepath is never takes as it checks if the CPU is at least
ivybridge.
Change-Id: Id064385f0c8bb0b094714129df6d8ba36c87a307
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fix regression with commit d53fd70 intel/smm/gen1: Use smm_subregion().
The bitmask on SMRR register parameter was inverted for
selected models.
Change-Id: Ia572ca3bdd4da371985691b5d249f998382fbe48
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Make intel_ht_sibling() available on all platforms.
Will be used in MP init to only write "Core" MSRs from one thread
on HyperThreading enabled platforms, to prevent race conditions and
resulting #GP if MSRs are written twice or are already locked.
Change-Id: I5d000b34ba4c6536dc866fbaf106b78e905e3e35
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The typical do { } while (0) did not work, so
provide empty stub function instead.
Change-Id: Ieb0c33b082b4c4453d29d917f46561c0e672d09a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is only called in ramstage. Even if it was called in
romstage, execution flow is such that BSP and AP CPUs
should not be able to enter update_microcode() routine
concurrently.
Also the Kconfig guarding the spin_lock() calls are not
selected nor are the lock variables declared for these
platforms.
Change-Id: I1c2e106f10e8420e942b3ed082c677c0db95557c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35586
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The implementation of udelay() with LAPIC timers
existed first, as we did not have calculations
implemented for TSC frequency.
Change-Id: If510bcaadee67e3a5792b3fc7389353b672712f9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34200
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We can use intel/common implementation for tsc_freq_mhz().
Change-Id: I728732896ad61465fcf0f5b25a6bafd23bca235e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34199
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix regression from commit ecea916
cpu/intel/common: Extend FSB detection to cover TSC
MSR_EBC_FREQUENCY_ID (0x2c) was not defined for affected
CPU models and rdmsr() caused reset loops. Implementations
deviate from public documentation.
Change to IA32_PERF_STATUS (0x198) already used in i945/udelay.c
to detect FSB to TSC multiplier.
Change-Id: I7a91da221920a7e7bfccb98d76115b5c89e3b52e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Eugene Myers