summaryrefslogtreecommitdiff
path: root/src/cpu/x86/Kconfig
AgeCommit message (Collapse)Author
2020-08-15cpu/x86/smm: Introduce SMM module loader version 2Rocky Phagura
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. Change-Id: I00a23a5f2a46110536c344254868390dbb71854c Signed-off-by: Rocky Phagura <rphagura@fb.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-06-15arch/x86: Remove NO_FIXED_XIP_ROM_SIZEKyösti Mälkki
The variable SETUP_XIP_CACHE provides us a working alternative. Change-Id: I6e3befedbbc7967b71409640dc81a0c2a9b3e511 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41821 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-06-15arch/x86: Remove XIP_ROM_SIZEKyösti Mälkki
When adding XIP stages on x86, the -P parameter was used to pass a page size that covers the entire file to add. The same can now be achieved with --pow2page and we no longer need to define a static Konfig for the purpose. TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and inspect the generated make.log files. The effective pagesize is reduced from 64kB to 16kB for asus/p2b giving more freedom for the stage placement inside CBFS. Pagesize remained at 64kB for lenovo/x60. Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Keith Hui <buurin@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2020-03-15nb/intel/nehalem: Rename to ironlakeAngel Pons
The code is for Arrandale CPUs, whose System Agent is Ironlake. This change simply replaces `nehalem` with `ironlake` and `NEHALEM` with `IRONLAKE`. The remaining `Nehalem` cases are handled later, as changing some of them would impact the resulting binary. Tested with BUILD_TIMELESS=1 without adding the configuration options into the binary, and packardbell/ms2290 does not change. Change-Id: I8eb96eeb5e69f49150d47793b33e87b650c64acc Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38941 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-11prog_loaders: Remove CONFIG_MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADINGJulius Werner
This option is not used on any platform and is not user-visible. It seems that it has not been used by anyone for a long time (maybe ever). Let's get rid of it to make future CBFS / program loader development simpler. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I2fa4d6d6f7c1d7a5ba552177b45e890b70008f36 Reviewed-on: https://review.coreboot.org/c/coreboot/+/39442 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-12-19arch/x86: Drop uses of ROMCC_BOOTBLOCKArthur Heymans
Change-Id: Ia0405fdd448cb31b3c6ca3b3d76e49e9f430bf74 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37339 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2019-11-25Kconfig: Drop the C_ENVIRONMENT_BOOTBLOCK symbolArthur Heymans
The romcc bootblock will be deprecated soon and most platforms use C_ENVIRONMENT_BOOTBLOCK already. This patch drops the CONFIG_C_ENVIRONMENT_BOOTBLOCK symbol and adds CONFIG_ROMCC_BOOTBLOCK where needed. Change-Id: I773a76aade623303b7cd95ebe9b0411e5a7ecbaf Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37154 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2019-11-03cpu/x86/tsc: Flip and rename TSC_CONSTANT_RATE to UNKNOWN_TSC_RATEKyösti Mälkki
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>
2019-11-02cpu/x86: Add a prog_run hook to set up caching of XIP stagesArthur Heymans
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>
2019-08-09cpu/x86 mp_init: Add option for AMD INIT SIPI sequenceMarshall Dawson
The common code adheres to the Intel requirement of bringing up the cores with INIT SIPI SIPI. This sequence is tolerated on some AMD AMD CPUs but fails on others. Add a way to skip the second SIPI. TEST=Mock up on grunt and verify no errors BUG=b:138919564 Change-Id: I201869003ddc7d04d332cd5734ac6d63979d89e0 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34759 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-07-09arch/x86: Flip HAVE_MONOTONIC_TIMER defaultKyösti Mälkki
Change-Id: Id56139a3d0840684b13179821a77bc8ae28e05ae Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34113 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-07-09cpu/x86: Flip SMM_TSEG defaultKyösti Mälkki
This is only a qualifier between TSEG and ASEG. Change-Id: I8051df92d9014e3574f6e7d5b6f1d6677fe77c82 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34135 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-07-09cpu/x86: Declare SMM_ASEGKyösti Mälkki
This is really an inverse of SMM_TSEG to flag platforms that should potentially move away from ASEG implementation. Change-Id: I3b9007c55c75a59a9e6acc0a0e701300f7d21f87 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34134 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-07-08drivers/pc80: Move UDELAY_IO and UDELAY_TIMER2Kyösti Mälkki
No longer fallback to UDELAY_IO as default. Since these are not cpu properties or features, move the Kconfig location. Change-Id: I9809cdc285c7bf741aa391ddb5755390bbfc2909 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34107 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-05-27src/drivers/intel/fsp1_0: Move PLATFORM_USES_FSP1_0Arthur Heymans
drivers/intel/fsp1_0/Kconfig is a better location than cpu/x86/Kconfig. Change-Id: Ic1c86c26a66c33760484bb6a86e9763c148a7c96 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/30791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2018-10-29x86/mp_init: Add configurable stack size for SMM relocateMarshall Dawson
A stack overrun has been observed on AMD64 CPUs during the SMM module relocation process. Change the assumed required size from equaling the save structure's size to a Kconfig symbol. A value of 0x400 doubles the size used by AMD64 systems and maintains the size used by EM64T. BUG=b:118420852 TEST=S3 on Grunt and verify 0x2f000-0x30000 uncorrupted Change-Id: Ib1d590ee4afb06ca649afd6ad253cdfd969ae777 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/29277 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-06-14cpu/x86: Make SMM stack size configurableRaul E Rangel
Stoneyridge is running into a stack overflow in the SMM handler. BUG=b:80539294 TEST=built on grunt Change-Id: I94e385497bd93c3638c69fb08d9b843c3bbb55ce Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-on: https://review.coreboot.org/27034 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-06-06arch/x86: Always select RELOCATABLE_MODULESKyösti Mälkki
All boards except those with NO_RELOCATABLE_RAMSTAGE or explicit select already had this feature built. Change-Id: I838e12141243ec49c2555c09269e07476eb0cfad Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26816 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-06arch/x86: Drop leftover ROMCC supportKyösti Mälkki
Remove the last bits of building romstage with romcc. Change-Id: I70bb1ed23a5aeb87bf7641e0b0bd604a4e622e61 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26807 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2018-01-25cpu/x86: don't utilize UDELAY_IO if GENERIC_UDELAYAaron Durbin
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>
2016-12-08cpu/x86: allow AP callbacks after MP initAaron Durbin
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-08-23src/cpu: Capitalize CPU, APIC and IOAPIC typo fixElyes HAOUAS
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-18Kconfig: rename BOOT_MEDIA_SPI_BUS to BOOT_DEVICE_SPI_FLASH_BUSAaron Durbin
Provide a default value of 0 in drivers/spi as there weren't default values aside from specific mainboards and arch/x86. Remove any default 0 values while noting to keep the option's default to 0. BUG=chrome-os-partner:56151 Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16192 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-27cpu/x86: Support CPUs without rdmsr/wrmsr instructionsLee Leahy
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-05-06cpu/x86: don't treat all chipsets the same regarding XIP_ROM_SIZEAaron Durbin
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-04cpu/x86: remove BACKUP_DEFAULT_SMM_REGION optionAaron Durbin
Unconditionally provide the backup default SMM area API. There's no reason to guard the symbols behind anything since linker garbage collection is implemented. A board or chipset is free to use the code or not without needing to select an option. Change-Id: I14cf1318136a17f48ba5ae119507918190e25387 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14561 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-04-11src/cpu/x86: remove TSC_CALIBRATE_WITH_IOAaron Durbin
It's not selected by any path so it's a dead option with associated dead code. Remove the config option as well as the code paths that were never used any longer. Change-Id: Ie536eee54e5c63bd90192f413c69e0dd2fea9171 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14299 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Myles Watson <mylesgw@gmail.com>
2016-03-08cpu/x86: Sort some Kconfig optionsStefan Reinauer
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-12-02x86/smm: Initialize SMM on some CPUs one-by-oneDamien Zammit
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-10-29smmhandler: on i945..nehalem, crash if LAPIC overlaps with ASEGPatrick Georgi
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-05-28smm: Merge configs SMM_MODULES and SMM_TSEGVladimir Serbinenko
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-04-24fsp: Move fsp to fsp1_0Marc Jones
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-07kconfig: drop intermittend forwarder filesStefan Reinauer
With kconfig understanding wildcards, we don't need Kconfig files that just include other Kconfig files anymore. Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9298 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-12-15x86: Set BOOT_MEDIA_SPI_BUSDavid Hendricks
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-07-23src/.../Kconfig: various small fixes to textsDaniele Forsi
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-05-10Replace SERIAL_CPU_INIT with PARALLEL_CPU_INITKyösti Mälkki
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-09Intel FSP: add a shared set of functions for the FSPMartin Roth
- 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-03-07x86: add MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING optionAaron Durbin
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-25Remove CACHE_ROM.Vladimir Serbinenko
With the recent improvement 3d6ffe76f8a505c2dff5d5c6146da3d63dad6e82, speedup by CACHE_ROM is reduced a lot. On the other hand this makes coreboot run out of MTRRs depending on system configuration, hence screwing up I/O access and cache coherency in worst cases. CACHE_ROM requires the user to sanity check their boot output because the feature is brittle. The working configuration is dependent on I/O hole size, ram size, and chipset. Because of this the current implementation can leave a system configured in an inconsistent state leading to unexpected results such as poor performance and/or inconsistent cache-coherency Remove this as a buggy feature until we figure out how to do it properly if necessary. Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/5146 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-02-16x86: provide infrastructure to backup default SMM regionAaron Durbin
Certain CPUs require the default SMM region to be backed up on resume after a suspend. The reason is that in order to relocate the SMM region the default SMM region has to be used. As coreboot is unaware of how that memory is used it needs to be backed up. Therefore provide a common method for doing this. Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5216 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-30x86: parallel MP initializationAaron Durbin
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-09-21CBMEM: Always select CAR_MIGRATIONKyösti Mälkki
If romstage does not make cbmem_initialize() call, linker should optimize the code for CAR migration away. This simplifies design of CBMEM console by a considerable amount. As console buffer is now migrated within cbmem_initialize() call there is no longer need for cbmemc_reinit() call made at end of romstage. Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3916 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-05-16x86: add cache-as-ram migration optionAaron Durbin
There are some boards that do a significant amount of work after cache-as-ram is torn down but before ramstage is loaded. For example, using vboot to verify the ramstage is one such operation. However, there are pieces of code that are executed that reference global variables that are linked in the cache-as-ram region. If those variables are referenced after cache-as-ram is torn down then the values observed will most likely be incorrect. Therefore provide a Kconfig option to select cache-as-ram migration to memory using cbmem. This option is named CAR_MIGRATION. When enabled, the address of cache-as-ram variables may be obtained dynamically. Additionally, when cache-as-ram migration occurs the cache-as-ram data region for global variables is copied into cbmem. There are also automatic callbacks for other modules to perform their own migration, if necessary. Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3232 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-07x86: add TSC_CONSTANT_RATE optionAaron Durbin
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-01tsc: provide monotonic timerAaron Durbin
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-05-01lapic: monotonic time implementationAaron Durbin
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-03-29x86: mtrr: add CONFIG_CACHE_ROM supportAaron Durbin
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR specifically for setting up write-protect cachine of the ROM. It is assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole area should be cached just under 4GiB. If enabled, the MTRR code will allocate but not enable rom caching. It is up to the callers of the MTRR code to explicitly enable (and disable afterwards) through the use of 2 new functions: - x86_mtrr_enable_rom_caching() - x86_mtrr_disable_rom_caching() Additionally, the CACHE_ROM option is exposed to the config menu so that it is not just selected by the chipset or board. The reasoning is that through a multitude of options CACHE_ROM may not be appropriate for enabling. Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2918 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: unify amd and non-amd MTRR routinesAaron Durbin
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-14x86: SMM Module SupportAaron Durbin
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>
2012-11-27Remove AMD special case for LAPIC based udelay()Patrick Georgi
- 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>