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>
Fix regression introduced by:
3660c0fc65
"northbridge/intel/sandybridge: Enable PEG clock-gating on demand"
Issue observed:
GNU/Linux kernel crashes in earlyinit on systems without PEG devices.
The crash occurs on every boot in different functions.
There's no problem on systems with PEG enabled.
Test system:
* Lenovo T530
* Intel Core i5-3320M CPU
* Fedora GNU/Linux 4.1
* PEG disabled in devicetree
Problem description:
Tests shows that modifing PEG chicken bit or device enable bits
after setting BIOS_RESET_CPL causes random crashes in GNU/Linux.
Problem solution:
Disable PEG devices before setting BIOS_RESET_CPL.
Final testing results:
No more random kernel crashes.
Change-Id: I4a967c2d00d7d1e4426cf5abdd5f616c21557da7
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/12112
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Issue observed:
Coreboot stops at: "Not enough MTRRs available!"
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* ATI Radeon HD4780
Problem description:
In case the IGD does not claim VGA decode, the code path taken results
in an integer overflow as uma_memory_base isn't initialized.
The MTRR assignment will fail, because of invalid memory regions.
Problem solution:
Properly initialize uma_memory_base to prevent possible integer overflow.
Final testing results:
The system boots again with IGD not claiming VGA decode.
Change-Id: I025be23b1defb6155469a3eee66569e49a695e7f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Issue observed:
Intel raminit works in about 50% of all test-cases on lenovo x220.
Problem solution:
Prefer a smaller valid value over the measured one for
initial timB timings.
Final testing result:
Tests on x220 shows that the issue was resolved.
The test system booted successfully ten times in a row.
Tests on Gigabyte GA-B75M-D3H revealed no regressions.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMM: "Crucial 2GB 256Mx64 CT2566aBA160BJ"
Change-Id: I1a115a45d5febf351d89721ece79eaf43f7ee8a0
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11248
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The existing MCT support code did not perform any of the requisite
configuration to support registered or x4 DIMMs. Add the needed
configuration per the BKDG for Family 15h.
Change-Id: I9ee0bb7346aa35f564fe535cdd337ec7f6148f2b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12019
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Sufficient support has been added to allow booting with registered
DIMMs on the KGPE-D16 in certain slots. ECC support needs additional
work; the ECC data lanes appear to cause boot failures in some slots.
Change-Id: Ieaf4cbf351908e5a89760be49a6667dc55dbc575
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12017
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The current code did not define the number of DIMM slots on the
mainboard, which lead to incorrect configuration values and
occassional training failure.
Add preliminary support for DIMM slot count configuration.
Change-Id: I488511d6262ffa8207c442d133314aed0f75acfb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12016
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
CAR space on certain platforms is nearly full. This prevents the
addition of necessary RAM initialization features such as x4 DIMM
support. As the DIMM SPD cache uses a sizeable amount of CAR RAM,
reducing it would free up a significant amount of CAR RAM.
DDR3-based AMD platforms only support up to 3 physical DIMMs on
each channel (6 per node). Reduce the maximum number of DIMMs
on a node from 8 to 6 accordingly.
Change-Id: I38def86da76fc622785318c825670209b2ac9017
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12107
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the course of adding full Family 15h MCT support some Family
15h specific settings were inadvertently applied to Family 10h
processors.
Only apply Family15h specific settings to Family 15h processors.
Change-Id: I5dcb333d3a5a49318fe7bddd4c386642205c343e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12013
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When both DCTs of a node are in use the DRAM clocks should be skewed
with respect to one another in order to reduce cross-channel interference.
Set the clock skew bit according to the BKDG recommendations.
Change-Id: Ibcce54fc53b79beba2f790994bcf87cc0354213a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12011
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing code did not set Rtt timing parameters when registered
DIMMs were used with Family 15h processors. Set the Rtt values
according to the BKDG recommendations.
Change-Id: I80cd7f8aec12951611d802f33e5e167a41dd532e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12010
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
AMD Opteron processors contain a very fragile phy phase detection circuit.
Additionally, the algorithm given in the BKDG does not function as intended;
this was verified both on real hardware via execution trace and on paper
with values read back from multiple CPUs and DIMMs.
As a result, the phy training algorithm given in the BKDG has been
replaced with a phy training algorithm developed at Raptor Engineering.
This particular patch is the first part of that algorithm; the code
is updated in future patches but this should exist in the historical
record in case something breaks down in the later sections of code.
Change-Id: Ic7a19d24954f47c922126e3da7be1f7e85f7396f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12007
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
AMD's automatic phy phase detection hardware is very fragile and often
produces incorrect results. Attempt to recover from obvious phase
locking errors by retrying phy training on the failing link.
Change-Id: Ia2c3022534c9ad44714eef6e118869f054bd9f6b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12006
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing MCT code did not properly set up the On Die Termination
(ODT) or timing values for registered DIMMs. Use the BKDG recommended
values when registered DIMMs are installed.
Change-Id: Ia9ee770d9f9c22e18c12e38b5bb4a7bae0a99062
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12005
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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>
The existing ECC initialization algorithm contained several bugs on both
Family 10h and Family 15h processors, including activation of ECC scrub
before DRAM setup was completed, in violation of both BKDG and errata
recommendations.
Change-Id: I09a8ea83024186b7ece7d78a4bef1201ab34ff8a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12002
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing prefetcher configuration was incorrect; use the correct
values from the AMD Family 10h and Family 15h BKDGs as appropriate.
Change-Id: I287ffa6345e1f4d232d4b2ea4251650ada3fda92
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12417
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing code enabled ECC before clearing memory. As the
AMD CPUs will generate MCEs on any invalid check bits, this
resulted in random lockups during memory training due to the
uniniailized check bits.
Initialize ECC check bits before enabling ECC hardware.
Change-Id: I992e7040520570893ba6a213138dd57bfa14733b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11996
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Certain DIMMs, for example DIMMs on which the EEPROM has been modified
by the end user, may not contain a valid SPD checksum. While this is
not a normal condition, it may be useful to allow a checksum override
while memory timing parameters are being altered, e.g. in the course
of overclocking or underclocking, or when recovering from a bad SPD
write.
This is an advanced level feature primarily useful for debugging
and development.
Change-Id: Ia743a13348d0a6e5e4dfffa04ed9582e0f7f3dad
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11987
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Under specific circumstances, for instance in low power or fanless
machines, it may be useful to cap the maximum P-state of the CPU.
Allow the maximum CPU P-state to be set via an NVRAM option.
Change-Id: Ifdbb1ad11a856f855c59702ae0ee99e95b08520e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11985
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
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>
A wrong function name made an #ifdef'd code path not compile. Fix that,
and also use IS_ENABLED() to make sure that such issues won't come up
again there.
Change-Id: Iccb98842dde498cce32cd86a770e22a506ad4cc2
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/12296
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DRAM training accounts for most of the romstage startup time, yet
if the hardware configuration has not changed from the previous boot
the previously discovered training values are still valid. Use them
if the DIMM configuration has not changed since the last boot.
The SPD values of all installed DIMMs are hashed and stored in the S3
resume data area of the main system Flash device. If a DIMM is changed
the hash will almost certainly change as well, forcing retraining on next
boot.
Change-Id: I37ed277b16476d38e4af76c6ae827a575c6b017d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11976
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Upon bootup the hardware reads at minimum 256 * 16 bytes (4Kb, or 32KB) over
I2C on a system with all DIMM slots populated. If even one of those reads
has a single flipped bit in it (due to EMI, cross coupling with another trace,
or just poor margins on some cheap DIMM) the system will hang and require a
hard reset. In practice I've seen failure rates as high as 1 failed boot in
50 due to this issue, granted with cheap DIMMs, but even so retrying the read
resolves the corruption issue.
I2C is not designed for continuous data transmission with high reliability, and
there is no hardware error checking, therefore a single retry when transferring
this amount of data makes sense.
Change-Id: Ifab63eca2233c63a6a42ab8b7e742f8e47fb2a09
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11975
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Intel northbridge must be paired with a southbridge. Add
the ii89xx southbridge header based on the config setting.
Change-Id: Ied708006310efaba31afe6977ab7e57fe4e5ceec
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/12167
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The RDK amd/db-ft3b-lc board will use this for on-board DDR3.
Change-Id: I2ffd38e7e949d3a60487e91188ddaab04b03d4b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12358
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
This cast only hides errors in matching the API properly.
Change-Id: I9b878ab997b8ff087a7209f94522646b10b94bf6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12271
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This cast only hides errors in matching the API properly.
Change-Id: Ic396dfb572a50ac5ce5c1c83424e1f17f15bad1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The plugged devices on PCIe should use IOAPIC2 instead of standard
IOAPIC1. The entries in IOAPIC2 count from the end of IOAPIC1.
The unchanged code worked because the OS uses MSI instead APIC.
To test that, boot linux with parameter pci=nomsi and see if the devices
like NIC work well as they do without the booting parameter.
Change-Id: I893e73f2aab3227381e44406fa285613e4ba2904
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11374
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The touched workaround for Sandy Bridge reserves two memory regions that
could cause graphics corruption if mapped by the integrated graphics
device. To the best of our knowledge, the workaround is not needed for
Ivy Bridge revisions.
Tested on kontron/ktqm77 (Ivy Bridge): Booted Linux and checked the
memory regions are not reserved. Couldn't test on Sandy Bridge, due to
lack of hardware.
Change-Id: I4273d1d804b490cf93c23426782eb1ffaf29f7d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12326
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
Most AMD hardware requires at minimum two warm resets
when booting from S5 (power off). This is uncomfortably
close to the maximum bootblock execution count, and has resulted
in unstable normal/fallback operation on some machines.
Increase the default max bootblock execution count before fallback
to 6. This translates to roughly 2 - 3 failed boots before fallback
mode will engage, with an absolute worst case of pushing the reset
button 5 times to engage fallback mode in the absence of a dedicated
recovery jumper.
Change-Id: I1911f1b77f168835b516e6a915d5b6949f47219a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12317
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Timothy Pearson