| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I4cf6549234041c395a18a89332d95f20a596fc3e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12033
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I55cfc96a197514212b2a4c344d3513396ebc2ad4
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12032
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Looking at the coreboot console logs there are sometimes trailing
whitespaces in the output, for example, if writing `Done` was not
possible.
Adapt the code, that spaces are only added when needed.
Change-Id: Ia0af493ab62b6fab24e8a2629cf5fd67329e0af7
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/12357
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ieb1f1fb5653651c98764de79636669802578d5f9
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12028
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: Ifa1592d26ba7deb034046fd3f2a15149117d9a76
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12027
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The revision detection code for AMD Family 10h/15h was modified
to use a 64-bit value instead of 32-bit in order to accomodate
additional processor revisions. The FIDVID code was not updated
at that point, leading to incorrect revision use during FIDVID.
Change-Id: I7a881a94d62ed455415f9dfc887fd698ac919429
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12026
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
All modern Opteron processors support the HT probe filter,
which helps to increase coherent fabric performance by
reducing the number of HT transactions per cache probe.
AMD recommends that the probe filter be enabled on all
systems with more than two nodes, and it does not hurt
to enable it on systems with 2 nodes.
Change-Id: I00a27a828260be8685ae622cfa5a4995add95a8e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12021
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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>
|
|
The existing code did not set the northbridge throttle
values on Family 15h, leading to sporadic and random
deadlocks in the crossbar per AMD notes.
Properly set the northbridge throttle values on Family 15h.
Change-Id: I6304b63708c65fedb9c2d46b8c862b7f0adf1102
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12025
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The existing HyperTransport register configuration values were incorrect
in many spots. Apply the correct values from the BKDG on Family 10h and
Family 15h processors.
Change-Id: I009b6f478340e2dbfcda2b4534473d4397f9ecef
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12022
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The Intel cave creek chipset needs to have port 80 routing configured
before any post codes can be sent to port 80h. Sending post codes out
before the routing is done will hang the system.
This patch allows us to disable the first couple of post codes that go
out before the routing can be configured.
The Kconfig symbol is selected by the cave creek chipset (fsp_i89xx).
Change-Id: I9bf41669ec32744f87a1ed2de011d31c72ea38da
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12422
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: York Yang <york.yang@intel.com>
|
|
This fixes Family 15h multiple package support; the previous code
hung in CAR setup and romstage when more than one CPU package was
installed for a variety of loosely related reasons.
TEST: Booted ASUS KGPE-D16 with two Opteron 6328 processors
and several different RDIMM configurations.
Change-Id: I171197c90f72d3496a385465937b7666cbf7e308
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12020
Tested-by: build bot (Jenkins)
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>
|
|
On some multi-socket AMD platforms there are too many cores for all
APs to start up without stack collisions with either each other or
the BSP. On such platforms a larger amount of CAR memory is also
available.
Allow the maximum DCACHE size to be increased via a mainboard-
specific Kconfig flag.
Change-Id: I72ae8f7abeb9a83b57505469922818f9ec5bdf3f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12015
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Tested: Avoids crash with Sempron 2800+ on K8V-X.
Change-Id: I76196176635bb0f6ac284c8cb3b72212774fdfe4
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-on: http://review.coreboot.org/12336
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
|
|
There were numerous issues surrounding AMD ECC initialization on
Family 15h processors due to the incomplete derivation from Family
10h MCT code. Bring the Family 15h ECC initialization and supporting
setup code in line with the BKDG recommendations.
Change-Id: I7f009b655f8500aeb22981f7020f1db74cdd6925
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12003
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I03e43f38e0d2e51141208ebb169ad8deba77ab78
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11963
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch adds CC6 power save support to the AMD Family 15h
support code. As CC6 is a complex power saving state that
relies heavily on CPU, northbridge, and southbridge cooperation,
this patch alters significant amounts of code throughout the
tree simultaneously.
Allowing the CPU to enter CC6 allows the second level of turbo
boost to be reached, and also provides significant power savings
when the system is idle due to the complete core shutdown.
Change-Id: I44ce157cda97fb85f3e8f3d7262d4712b5410670
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11979
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
NOTE: This commit switches CacheBase in CAR to use the DCACHE_RAM_BASE
Kconfig variable. There should be no functional difference between
the existing code and the new code, however hardware verfication is
encouraged on lesser used architectures such as AMD Geode.
Change-Id: Ia2e8f99be9df388e492a633c49df21ca1c57ba13
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11970
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The build was changed to remove usage of microcode .h files when
all of the .h files were converted to binary. This is still
needed for some builds when microcode binaries aren't in the
blobs tree.
Change-Id: Ia323c90efe8aa0b8799fc5cce6197509e466a105
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12333
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
This is in AP code, fixed in preparation for copying
the same check to BSP.
Change-Id: I0750919d9fdb3d4e6666221ad82097e0c479cf14
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-on: http://review.coreboot.org/12359
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
The additional local data storage requirements of the full DDR3
DRAM training algorithm make a BSP stack overrun a distint
possibility. Increase the BSP stack size to compensate.
Change-Id: I51af31442f2b77cb64a4b788751ccc7186acb283
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11972
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: I019f94b99d2fc33e19567acecaaad93813ab6b04
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11968
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: I887f9eb890f1f1c6f88b7984f0520bd17be8b88b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12284
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Do not mix open-source AGESA and binaryPI includes.
Change-Id: I1e43334ba8d5a17d3580f81e023ca2c8caf86f7c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12283
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
There has been a concerted effort to clean up coreboot's microcode
handling that has included a move away from coreboot-specific
microcode file collections. As a result, the ability to specify
a single microcode file to be added to the image is of less utility
than before.
NOTE: This patch remove the built-in external microcode feature,
however the user can still specify no microcode during build and
manually add the correct microcode file(s) to the CBFS image after
the build is complete.
Change-Id: Ifea94c21e531a74953f5a0e2f489378c20ef3b5c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11903
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The K8 PowerNow! state generator does not generate _PSS objects
for nodes other than the first CPU package. This patch backports
the PowerNow! core count fixes for Family 10h to the K8 CPUs.
Change-Id: I7b411ab75155dfb4bf51ae04301aa16fb2ae89f3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12286
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
TEST: Booted ASUS KGPE-D16 with single Opteron 6380
* Unbuffered DDR3 DIMMs tested and working
* Suspend to RAM (S3) tested and working
Change-Id: Idffd2ce36ce183fbfa087e5ba69a9148f084b45e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11966
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I07e517f239807cbe76037308f0beff80c9a6f2ba
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12101
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I34501d3fc68b71db7781dad11d5b883868932a60
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11965
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.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>
|
|
Change-Id: I66ef081fa1a520f0199366587800783ea1ef8719
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11023
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I35dab4e66514948aafa912d993fb8d42c5a520a0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11089
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I0f3297dff47dfb44da034ac6f305dcf1981b9de1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11080
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This mirrors a similar commit made to Family 10h support
in changeset 11966 file model_10xxx_init.c
TEST: Booted ASS KFSN4-DRE with 1x Opteron 8222
Change-Id: I760ef27be00aed11c0ac21b9bd741189f4b05834
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12250
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The existing Kconfig option for FIDVID was permanently
set to "no" due to Kconfig stopping at the first matching
value set when parsing the file. This patch moves the
conditional set above the unconditional set, resolving
the issue.
Change-Id: Ic19f68f6b17943f9133ff32a9b6538f0bf942eca
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12224
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Backport a handful of debugging routines and the extended APIC
initialization code from Family 10h support to K8 support.
Change-Id: I08cc5c8bc65635ce09a69e32940dd7edd8d3be87
TEST: Booted ASUS KFSN4-DRE with 1x Opteron 8222
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The recommendation to set DisFillP during CAR initialization
on K8 NPT CPUs was ignored. The consequences of this are
largely unknown; fix up coreboot to follow the recommendations.
Change-Id: Ide512bbc1d9aa284179628e2aa598ef5475e8eeb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12249
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ifdb1d1f267af289d962effe1150c7bc0a39cb5d2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12233
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: If1df7f3ae9661fae49557c07def397b36b1d38f0
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12210
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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)
|
|
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>
|
|
Romstage handoff copied from cpu/intel/haswell/romstage.c
Change-Id: I1e1a67fa3c2c13cebcf8f0af318055b9d97d0a59
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11953
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Having an empty microcode file makes it more easy to debug
in comparison to a not existing file in cbfs. There are some
platforms (e.g. ep80579) which support microcode updates but
not having any microcode updates yet in our tree.
These platform hang the build because `cat` is called with no
parameters.
Change-Id: I2699bde0c62ae62ca888686f8b496e845c36d970
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/12109
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I02c1fba5c749d5adb33ec86777bde108e587caa6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12185
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: I5139ee222a0dca7f8e62612a39d30cad7976b505
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12184
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: Iccd034f32c26513edd52ca3a11a30f61c362682d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11940
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.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>
|
|
Change-Id: I6dff74b3857e1fb384aefc87b44e7679bd4aab07
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11948
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
|
|
Values based on correlation of brand strings, brand numbers and the TDP
listings on AMD's web site (Wikipedia for Athlon 64 FX-7x TDPs).
Change-Id: I7e6d12d0b6cc4fefc3f84076234c62c40e08304c
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10926
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
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 fb50124d22014742b6990a95df87a7a828e891b6.
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>
|
|
Change-Id: I208b012c6b612a94b3bbc8235d5a005028be8bcc
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11832
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I626a11c17c9d05c174c507d50684e498c8604cbc
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11905
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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 959478a763c16688d43752adbae2c76e7764da45.
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>
|
|
The existing microcode update system used custom, manually generated microcode
blob files. This made updates very difficult. Update parser to use stock
microcode update files as provided by AMD.
Change-Id: I772b264ad167f2a5d629dab5d64d9b0ccab3a053
Signed-off-by: Audrey Pearson <apearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11829
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Since we now have more freedom in the bootblock linking step it no
longer makes sense to use a monolithic bootblock.S. Code segments must
still be included as the order in bootblock.S determines code flow.
However, non-code flow related assembly stubs don't need to be directly
included in bootblock.S
Change-Id: I08e86e92d82bd2138194ed42652f268b0764aa54
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11792
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There is no other guard to prevent this from being picked up when
building for other architectures.
Change-Id: I2039a289a4dd9970d5dd0f90d43d5d5c2a6d0a0b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
Using a copiler to compile something that's already a binary is pretty
stupid. Now that Stefan converted most microcode in blobs to a plain
binary, use the binary version.
Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11607
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
While the romstage code flow is not consistent across all
mainboards/chipsets there is only one way of running ramstage
from romstage -- run_ramstage(). Move the
timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. TS_END_ROMSTAGE still present in
timestamp table.
Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Recently qemu stopped doing a basic lapic setup and expects the
firmware to handle this properly (like on real hardware). So
let's do that so coreboot works properly on qemu 2.4+.
Here is the qemu commit message for the change:
<quote>
commit b8eb5512fd8a115f164edbbe897cdf8884920ccb
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Mon Apr 13 02:32:08 2015 +0300
target-i386: disable LINT0 after reset
Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone
and therefore this hack is no longer needed. Since it violates the
specifications, it is removed.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Message-Id: <1428881529-29459-2-git-send-email-namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
</quote>
Change-Id: I022f3742475d3f3477fc838b1e2bce69287b6b8e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/11611
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The LAPIC_MONOTONIC_TIMER symbol doesn't do anything in the code
unless UDELAY_LAPIC is selected. Since this chip uses UDELAY_TSC,
LAPIC_MONOTONIC_TIMER generates a Kconfig warning and should be
removed.
Change-Id: I5caa60ca7ab9a24d25c184c85184f9492b453706
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11342
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
The build system was previously determining the flow
and linking scripts bootblock code by the order of files
added to the bootblock_inc bootblock-y variables.Those
files were then concatenated together and built by a myriad of
make rules.
Now bootblock.S and bootblock.ld is added so that bootblock
can be built and linked using the default build rules.
CHIPSET_BOOTBLOCK_INCLUDE is introduced in order to allow the
chipset code to place include files in the path of the bootblock
program -- a replacement for the chipset_bootblock_inc
make variable.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards.
Change-Id: Ida4571cbe6eed65e77ade98b8d9ad056353c53f9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11495
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There's no reason defining another class compiler which
overrides the first one. The microcode files are just
built into a binary and added to cbfs. There's no reason to
change compilers.
Change-Id: Icb47d509832e7433092a814bad020f8d66f2a299
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11596
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
|
|
Now that cbfstool supports file alignment, we can use the conveniently
available <filename>-align handler, and remove the need to have a
separate rule in src/Makefile.inc just for adding the microcode.
We can also get rid of the layering violation of having the
CONFIG_PLATFORM_USES_FSP1_0 symbol in a generic src/cpu/ makefile.
Note that we still have a layering violation by the use of the
CONFIG_CPU_MICROCODE_CBFS_LOC symbol, but this one is acceptable
for the time being.
Change-Id: Id2f8c15d250a0c75300d0a870284cac0c68a311b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11526
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Current code written in C is calling a function implemented
in assembly. However, the symbol's visibility is not set
for such usage. Of course this works because MAINBOARDDIR/romstage.c
is being processed into an assembly file currently.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built digitallogic/msm800sev while not changing romstage.c
into an assembly file.
Change-Id: I84c3af0026f3f98bc64af007aa7cc196429f4e5f
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11511
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The Kconfig symbol CACHE_MRC_BIN was getting forced enabled everywhere
it existed.
Remove the Kconfig symbol and get rid of the #if statements
surrounding the code.
This fixes the Kconfig warning for Haswell & Broadwell chips:
warning: (NORTHBRIDGE_INTEL_HASWELL &&
NORTHBRIDGE_INTEL_SANDYBRIDGE &&
NORTHBRIDGE_INTEL_SANDYBRIDGE_NATIVE &&
NORTHBRIDGE_INTEL_IVYBRIDGE &&
NORTHBRIDGE_INTEL_IVYBRIDGE_NATIVE &&
CPU_SPECIFIC_OPTIONS) selects CACHE_MRC_BIN
which has unmet direct dependencies
(CPU_INTEL_SOCKET_RPGA988B || CPU_INTEL_SOCKET_RPGA989)
Change-Id: Ie0f0726e3d6f217e2cb3be73034405081ce0735a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In the wake of the recent Intel "Memoy Sinkhole" exploit a code review
of the AMD SMM code was undertaken. While native Family 10h support
does not appear to be affected by the same SMM flaw, it also does not
require SMM to function. Therefore, the SMM memory range initialization
should only be executed if SMM will be used on the target platform.
Change-Id: I6531908a7724933e4ba5a2bbefeb89356197e8fd
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11211
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The sysinfo object within the k8 ram init is used
to communicate progess/status from all the nodes in the
system. However, the code was assuming where the sysinfo
object lived in cache-as-ram. The layout of cache-as-ram
is dynamic so one needs to do the lookup of the correct
address at runtime. The way the amd code is compiled
by #include'ing .c files makes the solution a little
more complex in that some cache-as-ram support code
needed to be refactored.
Change-Id: I6500fa7b005dc082c4c0b3382ee2c3a138d9ac31
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10961
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I5da2a9fc34d2108caa2f21c0883d209b03a6b872
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11132
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I1a772be9d72aa6d6552f5ba21c20b28e400677e9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11131
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: Ib053bdec185eca2b45c95bec713cf0fb6d16c0bc
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11130
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Some Intel SoCs which support SGX feature, report the
microcode patch revision one less than the actual revision.
This results in the same microcode patch getting loaded again.
Add a SoC specific check to avoid reloading the same patch.
BUG=chrome-os-partner:42046
BRANCH=None
TEST=Built for glados and tested on RVP3
CQ-DEPEND=CL:286054
Change-Id: Iab4c34c6c55119045947f598e89352867c67dcb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ab2ed73db3581cd432f9bc84acca47f5e53a0e9b
Original-Change-Id: I4f7bf9c841e5800668208c11b0afcf8dba48a775
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/287513
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11055
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Moves the K8 CPU_ADDR_BITS definition from socket to model.
Previously socket_F was not setting CPU_ADDR_BITS correctly.
Tested on Sun Ultra 40 M2 with two 2nd-gen Opterons w/ 2x4x2GiB DIMMs.
Most if not all K8-based chips support 40-bit physical addresses, with
possible exception of IA32-only K8-based Athlon XP-M chips.
Probably irrelevant, unless your machine has enough memory (at least 60 to
64GiB before MMIO hoisting) to exceed the CPU_ADDR_BITS default of 36 from
src/cpu/x86/Kconfig.
Change-Id: I01a2a59fa902280171840c36ca2e631476d3d603
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10963
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I8644b04f4b57db5fc95ec155d3f78d53c63c9831
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10579
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Change-Id: I2821aaed1bc6324e671f68e4e4effb9dd006dcd9
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10922
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The BROKEN_CAR_MIGRATE symbol was removed in commit a6371940 -
x86 cache-as-ram: Remove BROKEN_CAR_MIGRATE option
The symbol DISABLE_SANDYBRIDGE_HYPERTHREADING is from Sage, and was
never added to the coreboot.org codebase.
Change-Id: I953fe7c46106634a5a3fcdaff88b39e884f152e6
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10941
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Relevant for systems having processors that only have two (the minimum
and maximum) P-states, such as the Opteron 2210 at 1.0 and 1.8GHz.
Change-Id: Ic66fe6d10ce495c1bf21796cb7e1eb4e11e85283
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10910
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead
check to make sure they're defined and not zero. In some cases, zero
might be a valid value, but it didn't look like zero was valid in these
cases.
Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10886
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Kconfigs symbols of type bool are always defined, and can be tested with
the IS_ENABLED() macro.
symbol type except string.
Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The prior ACPI _PSD generator committed in ef33db01 incorrectly assumed the active
link count of each processor was identical. Detect the link count on each node
when generating the _PSD objects.
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf9b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10158
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Caching SPD data during startup requires additional CAR space.
There was a large chunk of free space between the AP stack top and
the BSP stack bottom; moving the AP stacks below the BSP stack
allows this space to be utilized.
TEST: Booted ASUS KGPE-D16 with dual Opteron 6129 processors (16 cores)
and 120k of CAR.
Change-Id: I370ff368affde7061d6547527bda058b9016e977
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This resolves issues with 4-node (32-core) systems not having
sufficient CAR memory available to boot.
TEST: Booted ASUS KGPE-D16 with dual Opteron 6129 processors (16 cores)
and 120k of CAR.
Change-Id: Ie884556edc5c85c2c908a8c6640eeec11594ba3a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10402
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When increasing the number of supported CPUs on AMD Family 10h/15h
systems there is a relatively high chance of causing a collision
between the CAR global variable region and the AP stack space.
Such collision was noted when increasing the number of supported
CPUs to 32 on the ASUS KGPE-D16.
Detect collision at runtime and print a warning if collision is
present.
Change-Id: Ib5c32f868b1dfffb3b840bb1b1df5f55b5a25f8d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This reverts commit a3aa8da2acec28670b724b7897ae054592746674.
Chrome OS builds require the monotonic timer API in SMM for ELOG_GSMI,
but sandy/ivy doesn't provide it. The commit tried to work around that
by using generic LAPIC code instead, but this leads to multiple
definition errors in other configurations (and it may be unreliable once
the OS reconfigured the APIC timers anyhow).
This fixes the situation for the non-ELOG_GSMI case (which is more or
less everybody but Chrome OS). ELOG_GSMI requires a separate fix.
Change-Id: If4d69a122b020e5b2d2316b8da225435f6b2bef0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10811
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This fixes an issue with using the flash driver in SMM for writing
the event log through an SMM call.
Change-Id: If18c77634cca4563f770f09b0f0797ece24308ce
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ib1c6732d3a338f6d898fadc19e5af59032343451
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10580
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
