Match the definition and use of these variable with haswell, such that
DCACHE_RAM_MRC_VAR_SIZE is not included in DCACHE_RAM_SIZE.
Change-Id: I5af20f63cd0cb631d39f7c7fe0e2a99ebd3ce986
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15761
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363384
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Not all are matched, but this makes it easier to backport
MTRR changes from haswell.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ida5943b1469fc0089a31ff3b18131fb82b0941c6
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15760
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362686
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since the socket layer is implemented with this CPU model, there
could potentially be multiple CPU models included. There can be
only one cache_as_ram include, so select it directly within
the socket directory.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia52bb152276eddfd1fb33ddb7f5d153ab8e8163c
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15757
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362683
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355006
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reference to CACHE_AS_RAM was from the days we had
romcc boards using socket_mPGA605.
Change-Id: If397db83a01adeda4dd18d8b4c6e89bf0984264a
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15224
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
(cherry-picked from commit 831a7ef541)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354185
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15190
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry-picked from commit a969ed34db)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354182
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There used to be a need for an empty smm_init() function
because initialize_cpus() called it even though nothing
called initialize_cpus(). However, garbage collection at
link time is implemented so there's no reason to provide an
empty function to satisfy a symbol that is completely culled
during link. Remove it.
Change-Id: Ic13c85f1d3d57e38e7132e4289a98a95829f765a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14605
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I80b5b94b62bdd001581eb56513a0d532fffb64e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14596
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
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>
The BSP and AP callback declarations both had an optional argument
that could be passed. In practice that functionality was never used
so drop it.
Change-Id: I47fa814a593b6c2ee164c88d255178d3fb71e8ce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14556
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i440BX boards in the chipset.
Change-Id: I411191927f3fba1d0749edcf79378e8013fb195a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
For all the chipsets which were performing the following sequence:
x86_setup_fixed_mtrrs();
x86_setup_var_mtrrs(cpuid_eax(0x80000008) & 0xff, 2);
Replace that with x86_setup_mtrrs_with_detect() since it is equivalent.
Change-Id: I9f362dbf38942d675f615d22b9e5770ce65e5a08
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13936
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
The previous usage of the intel microcode support supported using
the library under ROMCC and ramstage. Allow for microcode support
to be used in normal C-based romstage as well by:
1. Only using walkcbfs when ROMCC is defined.
2. Only using spinlocks if !__PRE_RAM__
The header file now unconditionally exposes the declarations
of the supporting functions.
Change-Id: I903578bcb4422b4c050903c53b60372b64b79af1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In coreboot, bool, hex, and int type symbols are ALWAYS defined.
Change-Id: I58a36b37075988bb5ff67ac692c7d93c145b0dbc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The microcode for the Rangeley chip is supplied as .h files in the
Rangeley FSP POSTGOLD4 package.
When the rangeley microcode gets put into the blobs directory, this
can be reverted and the binary file put into the makefile.
Change-Id: I30e7436f26a247bc9431f249becfa5fe8c581be7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12335
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
These are no longer needed.
Test: Booted minnowmax.
Change-Id: Ie77040f3506464c614760bd4d30280c8113373bd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12468
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Load microcode to APs when performing model_406dx_init. The updated
fsp1_0 driver calls TempRamInit API with a dummy microcode, so FSP
will not handle the microcode load.
Change-Id: Ib75f860a34c84bf13c0c6c31ebed13e5787f365e
Signed-off-by: David Guckian <david.guckian@intel.com>
Reviewed-on: http://review.coreboot.org/12436
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Load microcode to BSP in bootblock so later on the FSP TempRamInit call
will return with success. The updated fsp1_0 driver calls TempRamInit
API with dummy microcode, so FSP will not handle the microcode load. If
BSP is not loaded with microcode before calling TempRamInit API, the
call will fail with error No Valid Microcode Was Found.
Change-Id: I9c55acaf3353a759bb0119f0a5402a704ffb2c4a
Signed-off-by: David Guckian <david.guckian@intel.com>
Reviewed-on: http://review.coreboot.org/12367
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: York Yang <york.yang@intel.com>
Add an additional Sandy(Ivy)bridge processor socket.
Change-Id: I7eff7183d0c003e61fdda5350579f4d3dec7504d
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/12168
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: York Yang <york.yang@intel.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Disable the parallel CPU initialization for model_206ax, that is Sandy
Bridge and Ivy Bridge processors. We never did it the way that Intel
recommends and it became unreliable with the introduction of SMM_MODULES
in commit a3e41c0 Migrate 206ax to SMM_MODULES.
Tested by booting kontron/ktqm77 2.6k times into Linux user space. No
issues so far.
Change-Id: Idffc352341419f22a36bf772534a5e11e711edf1
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12266
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Intel's FSP 1.0 platforms are moving back to loading microcode in
coreboot instead of in the FSP. Update the Ivy Bridge chips to
be compatible.
Change-Id: I4af155dea51e89ab9595b922c95ceade29a2dc52
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12196
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 24813c14 (i945: Consolidate acpi/platform.asl) creates the file
in the directory `src/cpu/intel/model_6dx/acpi`, although the devices
can also use different Intel CPU models like, for example,
`intel/model_6ex` on the Lenovo T60.
Therefore move the file to the directory `src/cpu/intel/common/acpi` so
that other devices, like Intel GM45 based devices, can also include it.
Change-Id: I90126b66a4d70468923622a8e3aebadeafcbf96f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Please don't remove chipsets and mainboards without discussion and input
from the owners. Someone was asking about cougar canyon 2 just a couple
of weeks ago - there's obviously still interest.
This reverts commit fb50124d22.
Change-Id: Icd7dcea21fa4a7808b25bb8727020701aeebffc9
Signed-off-by: Martin Roth <martinroth@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/12128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
