GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/cpu/x86/Kconfig

162 lines
3.7 KiB
Text
Raw Normal View History

cpu/x86: Sort some Kconfig options Change-Id: I25ea327ed151e18ccb5d13626d44925d2a253d08 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/10012 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-04-27 22:40:16 +02:00
# TODO These two options look too similar
Replace SERIAL_CPU_INIT with PARALLEL_CPU_INIT Lines with 'select SERIAL_CPU_INIT' where redundant with the default being yes. Since there is no 'unselect SERIAL_CPU_INIT' possibility, invert the default and rename option. This squelches Kconfig warnings about unmet dependencies. Change-Id: Iae546c56006278489ebae10f2daa627af48abe94 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5700 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-05-08 14:27:15 +02:00
config PARALLEL_CPU_INIT
Revert "remove CONFIG_SERIAL_CPU_INIT" This reverts commit 78efc4c36c68b51b3e73acdb721a12ec23ed0369. The broadcast patch was reverted, so this commit should also be reverted. The reason for reverting the broadcast patch: It turned out that sending IPIs via broadcast doesn't work on Sandybridge. We tried to come up with a solution, but didn't found any so far. So revert the code for now until we have a working solution. Change-Id: I05c27dec55fa681f455215be56dcbc5f22808193 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/1380 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-29 17:42:52 +02:00
bool
Replace SERIAL_CPU_INIT with PARALLEL_CPU_INIT Lines with 'select SERIAL_CPU_INIT' where redundant with the default being yes. Since there is no 'unselect SERIAL_CPU_INIT' possibility, invert the default and rename option. This squelches Kconfig warnings about unmet dependencies. Change-Id: Iae546c56006278489ebae10f2daa627af48abe94 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5700 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-05-08 14:27:15 +02:00
default n
Revert "remove CONFIG_SERIAL_CPU_INIT" This reverts commit 78efc4c36c68b51b3e73acdb721a12ec23ed0369. The broadcast patch was reverted, so this commit should also be reverted. The reason for reverting the broadcast patch: It turned out that sending IPIs via broadcast doesn't work on Sandybridge. We tried to come up with a solution, but didn't found any so far. So revert the code for now until we have a working solution. Change-Id: I05c27dec55fa681f455215be56dcbc5f22808193 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/1380 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-29 17:42:52 +02:00
cpu/x86: Sort some Kconfig options Change-Id: I25ea327ed151e18ccb5d13626d44925d2a253d08 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/10012 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-04-27 22:40:16 +02:00
config PARALLEL_MP
def_bool n
help
This option uses common MP infrastructure for bringing up APs
in parallel. It additionally provides a more flexible mechanism
for sequencing the steps of bringing up the APs.
cpu/x86: allow AP callbacks after MP init There are circumstances where the APs need to run a piece of code later in the boot flow. The current MP init just parks the APs after MP init is completed so there's not an opportunity to target running a piece of code on all the APs at a later time. Therefore, provide an option, PARALLEL_MP_AP_WORK, that allows the APs to perform callbacks. BUG=chrome-os-partner:60657 BRANCH=reef Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17745 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
2016-12-07 07:32:19 +01:00
config PARALLEL_MP_AP_WORK
def_bool n
depends on PARALLEL_MP
help
Allow APs to do other work after initialization instead of going
to sleep.
cpu/x86: Sort some Kconfig options Change-Id: I25ea327ed151e18ccb5d13626d44925d2a253d08 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/10012 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-04-27 22:40:16 +02:00
Various fixes to Kconfig: All kconfig-boards should have a complete set of variables now, though they might still have the wrong values. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4728 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-06 22:48:07 +02:00
config UDELAY_IO
bool
cpu/x86: don't utilize UDELAY_IO if GENERIC_UDELAY If GENERIC_UDELAY is selected don't try to use UDELAY_IO as there will be a udelay() conflict at link time. BUG=b:72378235,b:72170796 Change-Id: I9e01c9daddd0629ecc38a809889b39a505c0e203 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/23422 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2018-01-25 01:20:11 +01:00
default y if !UDELAY_LAPIC && !UDELAY_TSC && !UDELAY_TIMER2 && !GENERIC_UDELAY
Various fixes to Kconfig: All kconfig-boards should have a complete set of variables now, though they might still have the wrong values. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4728 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-06 22:48:07 +02:00
default n
config UDELAY_LAPIC
bool
default n
lapic: monotonic time implementation Implement the timer_monotonic_get() functionality based off of the local apic timer. Change-Id: I1aa1ff64d15a3056d6abd1372be13da682c5ee2e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3154 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30 00:18:49 +02:00
config LAPIC_MONOTONIC_TIMER
def_bool n
depends on UDELAY_LAPIC
select HAVE_MONOTONIC_TIMER
help
src/cpu: Capitalize CPU, APIC and IOAPIC typo fix Change-Id: I82e0736dc6b44cfcc57cdfdc786c85c4b6882260 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16276 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker
2016-08-21 10:12:15 +02:00
Expose monotonic time using the local APIC.
lapic: monotonic time implementation Implement the timer_monotonic_get() functionality based off of the local apic timer. Change-Id: I1aa1ff64d15a3056d6abd1372be13da682c5ee2e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3154 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30 00:18:49 +02:00
Remove AMD special case for LAPIC based udelay() - Optionally override FSB clock detection in generic LAPIC code with constant value. - Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz - compile LAPIC code for romstage, too - Remove #include ".../apic_timer.c" in AMD based mainboards - Remove custom udelay implementation from intel northbridges' romstages Future work: - remove the compile time special case (requires some cpuid based switching) - drop northbridge udelay implementations (i945, i5000) if not required anymore (eg. can SMM use the LAPIC timer?) Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/1618 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-20 11:53:47 +01:00
config UDELAY_LAPIC_FIXED_FSB
int
File I missed committing. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4619 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-29 05:00:51 +02:00
config UDELAY_TSC
bool
default n
x86: add TSC_CONSTANT_RATE option Some boards use the local apic for udelay(), but they also provide their own implementation of udelay() for SMM. The reason for using the local apic for udelay() in ramstage is to not have to pay the penalty of calibrating the TSC frequency. Therefore provide a TSC_CONSTANT_RATE option to indicate that TSC calibration is not needed. Instead rely on the presence of a tsc_freq_mhz() function provided by the cpu/board. Additionally, assume that if TSC_CONSTANT_RATE is selected the udelay() function in SMM will be the tsc. Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3168 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01 22:27:09 +02:00
config TSC_CONSTANT_RATE
def_bool n
depends on UDELAY_TSC
help
This option asserts that the TSC ticks at a known constant rate.
Therefore, no TSC calibration is required.
tsc: provide monotonic timer Implement the timer_monotonic_get() using the TSC. Change-Id: I5118da6fb9bccc75d2ce012317612e0ab20a2cac Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3155 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30 05:22:55 +02:00
config TSC_MONOTONIC_TIMER
def_bool n
depends on UDELAY_TSC
select HAVE_MONOTONIC_TIMER
help
Expose monotonic time using the TSC.
cpu/x86: Sort some Kconfig options Change-Id: I25ea327ed151e18ccb5d13626d44925d2a253d08 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/10012 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-04-27 22:40:16 +02:00
# This option is used in code but never selected.
config UDELAY_TIMER2
File I missed committing. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4619 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-29 05:00:51 +02:00
bool
default n
Synchronize rdtsc instructions The CPU can arbitrarily reorder calls to rdtsc, significantly reducing the precision of timing using the CPUs time stamp counter. Unfortunately the method of synchronizing rdtsc is different on AMD and Intel CPUs. There is a generic method, using the cpuid instruction, but that uses up a lot of registers, and is very slow. Hence, use the correct lfence/mfence instructions (for CPUs that we know support it) Change-Id: I17ecb48d283f38f23148c13159aceda704c64ea5 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1422 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2012-08-07 23:44:51 +02:00
config TSC_SYNC_LFENCE
bool
default n
help
The CPU driver should select this if the CPU needs
to execute an lfence instruction in order to synchronize
rdtsc. This is true for all modern AMD CPUs.
config TSC_SYNC_MFENCE
bool
default n
help
The CPU driver should select this if the CPU needs
to execute an mfence instruction in order to synchronize
rdtsc. This is true for all modern Intel CPUs.
cpu/x86: don't treat all chipsets the same regarding XIP_ROM_SIZE Previously, the XIP_ROM_SIZE Kconfig variable is used globally on x86 platforms with the assumption that all chipsets utilize this value. For the chipsets which do not use the variable it can lead to unnecessary alignment constraints in cbfs for romstage. Therefore, allow those chipsets a path to not be burdened by not passing '-P $(XIP_ROM_SIZE)' to cbfstool when adding romstage. Change-Id: Id8692df5ecec116a72b8e5886d86648ca959c78b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14625 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-05 17:34:22 +02:00
config NO_FIXED_XIP_ROM_SIZE
bool
default n
help
The XIP_ROM_SIZE Kconfig variable is used globally on x86
with the assumption that all chipsets utilize this value.
For the chipsets which do not use the variable it can lead
to unnecessary alignment constraints in cbfs for romstage.
Therefore, allow those chipsets a path to not be burdened.
Fix copy-paste error in src/cpu/x86/Kconfig. That file defines XIP_ROM_BASE twice, but the latter definition should be XIP_ROM_SIZE (not *_BASE). These exact two definitions are listed in src/Kconfig already, though, so maybe one of the two locations should remove them? Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4571 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-25 14:19:28 +02:00
config XIP_ROM_SIZE
Kconfig! Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:00:51 +02:00
hex
cpu/x86: don't treat all chipsets the same regarding XIP_ROM_SIZE Previously, the XIP_ROM_SIZE Kconfig variable is used globally on x86 platforms with the assumption that all chipsets utilize this value. For the chipsets which do not use the variable it can lead to unnecessary alignment constraints in cbfs for romstage. Therefore, allow those chipsets a path to not be burdened by not passing '-P $(XIP_ROM_SIZE)' to cbfstool when adding romstage. Change-Id: Id8692df5ecec116a72b8e5886d86648ca959c78b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14625 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-05 17:34:22 +02:00
depends on !NO_FIXED_XIP_ROM_SIZE
ROMCC boards have no XIP limit So set their XIP configuration to ROM_SIZE. Change-Id: I6c1abccec3b1d7389c85df55343ff0fc68a61eec Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/797 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2012-03-16 21:16:55 +01:00
default ROM_SIZE if ROMCC
- move the XIP_ROM_* flags to src/cpu/x86/Kconfig exclusively - set them to span the last 64k, instead of the last 128k by default - fixes via CAR for tiny bootblock - enabled tiny bootblock for via/vt8454c Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5409 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-12 11:50:53 +02:00
default 0x10000
- Fix shortcoming in Kconfig when handling multiple "choice"s - move some variables where they belong Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6186 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-17 00:37:17 +01:00
config CPU_ADDR_BITS
int
default 36
config LOGICAL_CPUS
bool
default y
Add Kconfig options to enable TSEG and set a size Future CPUs will require TSEG use for SMM Change-Id: I1432569ece4371d6e12c997e90d66c175fa54c5c Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/766 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-01-10 07:11:25 +01:00
config SMM_TSEG
bool
default n
x86: SMM Module Support Add support for SMM modules by leveraging the RMODULE lib. This allows for easier dynamic SMM handler placement. The SMM module support consists of a common stub which puts the executing CPU into protected mode and calls into a pre-defined handler. This stub can then be used for SMM relocation as well as the real SMM handler. For the relocation one can call back into coreboot ramstage code to perform relocation in C code. The handler is essentially a copy of smihandler.c, but it drops the TSEG differences. It also doesn't rely on the SMM revision as the cpu code should know what processor it is supported. Ideally the CONFIG_SMM_TSEG option could be removed once the existing users of that option transitioned away from tseg_relocate() and smi_get_tseg_base(). The generic SMI callbacks are now not marked as weak in the declaration so that there aren't unlinked references. The handler has default implementations of the generic SMI callbacks which are marked as weak. If an external compilation module has a strong symbol the linker will use that instead of the link one. Additionally, the parameters to the generic callbacks are dropped as they don't seem to be used directly. The SMM runtime can provide the necessary support if needed. Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2693 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-04 00:38:47 +01:00
select RELOCATABLE_MODULES
config SMM_MODULE_HEAP_SIZE
hex
default 0x4000
smm: Merge configs SMM_MODULES and SMM_TSEG SMM_TSEG now implies SMM_MODULES and SMM_MODULES can't be used without SMM_TSEG Remove some newly dead code while on it. Change-Id: I2e1818245170b1e0abbd853bedf856cec83b92f2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10355 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-28 21:09:31 +02:00
depends on SMM_TSEG
x86: SMM Module Support Add support for SMM modules by leveraging the RMODULE lib. This allows for easier dynamic SMM handler placement. The SMM module support consists of a common stub which puts the executing CPU into protected mode and calls into a pre-defined handler. This stub can then be used for SMM relocation as well as the real SMM handler. For the relocation one can call back into coreboot ramstage code to perform relocation in C code. The handler is essentially a copy of smihandler.c, but it drops the TSEG differences. It also doesn't rely on the SMM revision as the cpu code should know what processor it is supported. Ideally the CONFIG_SMM_TSEG option could be removed once the existing users of that option transitioned away from tseg_relocate() and smi_get_tseg_base(). The generic SMI callbacks are now not marked as weak in the declaration so that there aren't unlinked references. The handler has default implementations of the generic SMI callbacks which are marked as weak. If an external compilation module has a strong symbol the linker will use that instead of the link one. Additionally, the parameters to the generic callbacks are dropped as they don't seem to be used directly. The SMM runtime can provide the necessary support if needed. Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2693 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-04 00:38:47 +01:00
help
This option determines the size of the heap within the SMM handler
modules.
x86: unify amd and non-amd MTRR routines The amd_mtrr.c file contains a copy of the fixed MTRR algorithm. However, the AMD code needs to handle the RdMem and WrMem attribute bits in the fixed MTRR MSRs. Instead of duplicating the code with the one slight change introduce a Kconfig option, X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields need to be handled for writeback fixed MTRR ranges. The order of how the AMD MTRR setup routine is maintained by providing a x86_setup_fixed_mtrrs_no_enable() function which does not enable the fixed MTRRs after setting them up. All Kconfig files which had a Makefile that included amd/mtrr in the subdirs-y now have a default X86_AMD_FIXED_MTRRS selection. There may be some overlap with the agesa and socket code, but I didn't know the best way to tease out the interdependency. Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2866 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-20 21:50:59 +01:00
smmhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG This mitigates the Memory Sinkhole issue (described on https://github.com/xoreaxeaxeax/sinkhole) by checking for the issue and crashing the system explicitly if LAPIC overlaps ASEG. This needs to happen without a data access (only code fetches) because data accesses could be tampered with. Don't try to recover because, if somebody tried to do shenanigans like these, we have to expect more. Sandybridge is safe because it does the same test in hardware, and crashes. Newer chipsets presumably do the same. This needs to be extended to deal with overlapping TSEG as well. Change-Id: I508c0b10ab88779da81d18a94b08dcfeca6f5a6f Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/11519 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-09-05 20:21:24 +02:00
config SMM_LAPIC_REMAP_MITIGATION
bool
default y if NORTHBRIDGE_INTEL_I945
default y if NORTHBRIDGE_INTEL_GM45
default y if NORTHBRIDGE_INTEL_NEHALEM
default n
x86/smm: Initialize SMM on some CPUs one-by-one We currently race in SMM init on Atom 230 (and potentially other CPUs). At least on the 230, this leads to a hang on RSM, likely because both hyperthreads mess around with SMBASE and other SMM state variables in parallel without coordination. The same behaviour occurs with Atom D5xx. Change it so first APs are spun up and sent to sleep, then BSP initializes SMM, then every CPU, one after another. Only do this when SERIALIZE_SMM_INITIALIZATION is set. Set the flag for Atom CPUs. Change-Id: I1ae864e37546298ea222e81349c27cf774ed251f Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: https://review.coreboot.org/6311 Tested-by: build bot (Jenkins) Tested-by: BSI firmware lab <coreboot-labor@bsi.bund.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-28 11:27:05 +01:00
config SERIALIZED_SMM_INITIALIZATION
bool
default n
help
On some CPUs, there is a race condition in SMM.
This can occur when both hyperthreads change SMM state
variables in parallel without coordination.
Setting this option serializes the SMM initialization
to avoid an ugly hang in the boot process at the cost
of a slightly longer boot time.
x86: unify amd and non-amd MTRR routines The amd_mtrr.c file contains a copy of the fixed MTRR algorithm. However, the AMD code needs to handle the RdMem and WrMem attribute bits in the fixed MTRR MSRs. Instead of duplicating the code with the one slight change introduce a Kconfig option, X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields need to be handled for writeback fixed MTRR ranges. The order of how the AMD MTRR setup routine is maintained by providing a x86_setup_fixed_mtrrs_no_enable() function which does not enable the fixed MTRRs after setting them up. All Kconfig files which had a Makefile that included amd/mtrr in the subdirs-y now have a default X86_AMD_FIXED_MTRRS selection. There may be some overlap with the agesa and socket code, but I didn't know the best way to tease out the interdependency. Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2866 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-20 21:50:59 +01:00
config X86_AMD_FIXED_MTRRS
bool
default n
help
This option informs the MTRR code to use the RdMem and WrMem fields
in the fixed MTRR MSRs.
x86: parallel MP initialization Provide a common entry point for bringing up the APs in parallel. This work is based off of the Haswell one which can be moved over to this in the future. The APs are brought up and have the BSP's MTRRs duplicated in their own MTRRs. Additionally, Microcode is loaded before enabling caching. However, the current microcode loading support assumes Intel's mechanism. The infrastructure provides a notion of a flight plan for the BSP and APs. This allows for flexibility in the order of operations for a given architecture/chip without providing any specific policy. Therefore, the chipset caller can provide the order that is required. BUG=chrome-os-partner:22862 BRANCH=None TEST=Built and booted on rambi with baytrail specific patches. Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/173703 Reviewed-on: http://review.coreboot.org/4888 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-10-21 19:15:29 +02:00
fsp: Move fsp to fsp1_0 Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific directory. See follow-on patches for sharing of common code. Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/9970 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-23 07:16:31 +02:00
config PLATFORM_USES_FSP1_0
Intel FSP: add a shared set of functions for the FSP - Move the non chipset-specific fsp pieces out of the chipset into a shared area. This is used by northbridge / southbrige / SOC code. It pulls in pieces from Kconfig, Makefile and FSP specific code. - Enabled in the CPU code with a Kconfig "select PLATFORM_USES_FSP" Change-Id: I7ffa934c1df09b71d48a876a56e3b888685870b8 Signed-off-by: Martin Roth <gaumless@gmail.com> Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/5635 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-04-25 22:12:13 +02:00
bool
default n
help
Selected for Intel processors/platform combinations that use the
fsp: Move fsp to fsp1_0 Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific directory. See follow-on patches for sharing of common code. Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/9970 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-23 07:16:31 +02:00
Intel Firmware Support Package (FSP) 1.0 for initialization.
Intel FSP: add a shared set of functions for the FSP - Move the non chipset-specific fsp pieces out of the chipset into a shared area. This is used by northbridge / southbrige / SOC code. It pulls in pieces from Kconfig, Makefile and FSP specific code. - Enabled in the CPU code with a Kconfig "select PLATFORM_USES_FSP" Change-Id: I7ffa934c1df09b71d48a876a56e3b888685870b8 Signed-off-by: Martin Roth <gaumless@gmail.com> Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/5635 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-04-25 22:12:13 +02:00
x86: add MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING option Boot speeds can be sped up by mirroring the payload into main memory before doing the actual loading. Systems that would benefit from this are typically Intel ones whose SPI are memory mapped. Without the SPI being cached all accesses to the payload in SPI while being loaded result in uncacheable accesses. Instead take advantage of the on-board SPI controller which has an internal cache and prefetcher by copying 64-byte cachelines using 32-bit word copies. Change-Id: I4aac856b1b5130fa2d68a6c45a96cfeead472a52 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5305 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-02-26 03:36:56 +01:00
config MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING
def_bool n
help
On certain platforms a boot speed gain can be realized if mirroring
the payload data stored in non-volatile storage. On x86 systems the
payload would typically live in a memory-mapped SPI part. Copying
src/.../Kconfig: various small fixes to texts Fixed spelling and added empty lines to separate the help from the text automatically added during make menuconfig. Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7 Signed-off-by: Daniele Forsi <dforsi@gmail.com> Reviewed-on: http://review.coreboot.org/6313 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-22 18:00:56 +02:00
the SPI contents to RAM before performing the load can speed up
x86: add MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING option Boot speeds can be sped up by mirroring the payload into main memory before doing the actual loading. Systems that would benefit from this are typically Intel ones whose SPI are memory mapped. Without the SPI being cached all accesses to the payload in SPI while being loaded result in uncacheable accesses. Instead take advantage of the on-board SPI controller which has an internal cache and prefetcher by copying 64-byte cachelines using 32-bit word copies. Change-Id: I4aac856b1b5130fa2d68a6c45a96cfeead472a52 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5305 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-02-26 03:36:56 +01:00
the boot process.
x86: Set BOOT_MEDIA_SPI_BUS BOOT_MEDIA_SPI_BUS is a Kconfig variable used on some ARM-based platforms to set up CBFS media. It turns out it can also be helpful for setting up the eventlog which is intended to reside on the same SPI flash as CBFS. Setting it for x86 will allow us to remove an assumption about which SPI bus is used for this flash device. Long term this can go away as we come up with a better abstraction for the eventlog's backing store. This is only intended to help us get from here to there. BUG=none BRANCH=none TEST=built and booted on Link Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I1d84dc28592fbece33a70167be59e83bca9cd7bc Original-Reviewed-on: https://chromium-review.googlesource.com/191202 Original-Tested-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Gabe Black <gabeblack@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 200aa7c5b1b1f4c74412893cf7231a12e2702463) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: If988bcff5244ec6a82580203471b25fac49c45ef Reviewed-on: http://review.coreboot.org/7752 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-22 01:09:29 +01:00
cpu/x86: Support CPUs without rdmsr/wrmsr instructions Quark does not support the rdmsr and wrmsr instructions. In this case use a SOC specific routine to support the setting of the MTRRs. Migrate the code from FSP 1.1 to be x86 CPU common. Since all rdmsr/wrmsr accesses are being converted, fix the build failure for quark in lib/reg_script.c. Move the soc_msr_x routines and their depencies from romstage/mtrr.c to reg_access.c. TEST=Build and run on Galileo Gen2 Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15839 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-24 17:03:37 +02:00
config SOC_SETS_MSRS
bool
default n
help
The SoC requires different access methods for reading and writing
the MSRs. Use SoC specific routines to handle the MSR access.
Reference in a new issue Copy permalink