| Age | Commit message (Collapse) | Author |
|---|
|
Replace the use of the old device_t definition inside
northbridge/amd/agesa/family10.
Change-Id: I5723e217fc739ab576cbe3a1ee6d92023190267c
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17313
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Id0c62cebfceaf083f1bb39514b06b32c55128b85
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17172
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Carrizo (00660F01), Merlin Falcon (00660F01), and Stoney Ridge (00670F00)
locate the HD audio controller on the northbridge root complex at 9.2
instead of the FCH. This duplicates the existing ASL into the northbridge
directories and reports the correct address.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit f68206c2b42c90076efd968a99f4d3a49e403438)
Change-Id: I6d42bb40ad58c7f35e8c88ff27ebd327d656c021
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17216
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Adjust the names to match AMD's convention for family and model.
This patch is relevant for:
Trinity & Richland: Family 15h Models 00h-0Fh
Carrizo: Family 15h Models 60h-6Fh
Mullins & Steppe Eagle: Family 16h Models 30h-3Fh
Change-Id: I613b84ed438fb70269d789c9901f1928b5500757
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/17169
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Martin Roth <martinroth@google.com>
|
|
The Stoney device supports only a single channel of DRAM with
two DIMMs. Correct the dimmensions of the SPD lookup array.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: <marcj303@gmail.com>
(cherry picked from commit 54a5e4a7092b77cca90894e86387f719fa3aa2c8)
Change-Id: Ib776133e411d483bb5b7e3c070199befc631d209
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove the language associated with the Carrizo Gfx PCIe bridges.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
(cherry picked from commit cc32b09b0f0137c11d82f35274ca33e013f73748)
Change-Id: I8b67a646f98667d500fcee5da8389c10483488da
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17144
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Modify the new Stoney support files to match the APU's IDs and codename.
Original-Signed-off-by: Marc Jones <marcj303@gmail.com>
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
(cherry picked from commit de626730758def76e558294762a06d8ec9950cb9)
Change-Id: Idc914bc80a27ac13426fdf00fc3f578ce072086f
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17143
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Prepare for new 00670FF00 (StoneyRidge) support.
Original-Signed-off-by: Marc Jones <marcj303@gmail.com>
Original-Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Tested-by: Marshall Dawson <marshalldawson3rd@gmail.com>
(cherry picked from commit 037cf16883fafd329a15f903ddf97e24a879bcce)
Change-Id: I130d4f13beb2c1d71e4e4e9be5011f7993b34660
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17142
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: If372655700c18340d51368a39392560f664f4a45
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16896
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I04fe6b7a8798d0f3cb54130283ce5a50eb9ac5b4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16895
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ifd6aefa6c046d100a5388a24a7d23cbd77905a85
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16893
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I37c1674ee380936aba797e24897593fcca3b0269
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16891
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I930c761b9a2422590af3a0a5008b4ff2abe3fd96
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16890
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I2a52db28353f8575d11218af936b4a233fd05f77
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16889
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic22f8a00e6009e104df8c4374067369ebbf90ee2
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16888
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I5f45a4cd5661140f57aa37e86cc8a34622da3de5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16887
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I7966f996a4291cc6b97b53aba59b43358de94e45
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16886
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I63fee62253cb0488a041c9985a646102261b8c5e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16880
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ib06ecd083f00c74f1d227368811729d2944dd1ef
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16851
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Iea0352f85f4d5f47fc906edbe625e7bbf3f03afd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16863
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I1c2786dfb166904ff8b19a663c5e2e8156b7aedf
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16644
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: If87718b6c91d79212a9b045f5fda32d69ac4caee
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16643
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I80a2753f22d5211c8be4e17e2338402286a2cadc
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I86a252598666af635281eaa467020acb53d71c77
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16642
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: If700dc5fa9ae33649993557f71db0fe1eb76204b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16634
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ib1f9926ced1fd382c782f5098eb1ad98330cf655
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I296254d61fdc5c120e1e2abcbecb4677f3216d26
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Replace the use of the old device_t definition inside
northbridge/amd/amdht.
Change-Id: I7dfb8f001504c691aeddf1bfbc3be05cc7d31ce4
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16468
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Replace the use of the old device_t definition inside
northbridge/amd/amdk8.
Change-Id: I5209dd309f0685f83d8a468c50309d5fda77973a
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16467
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Replace the use of the old device_t definition inside
northbridge/amd/amdfam10.
Change-Id: I5037feb31c51d06ccc672b0771d5d6e8c0dac949
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16466
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Iffa058d9eb1e96a4d1587dc3f8a1740907ffbb32
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16414
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove an unusued function declaration that caused problems while
compiling the target.
Change-Id: Idfd73693e9b0e1777cafa4706113fde394e95795
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16435
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic85f725bbdf72fbac5a4d9482c61343c5eb35e25
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16305
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I6a533667c7c8ff5ec6ab9d4e1cfc51e993a90084
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16280
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
if (gart) { foo = gart?a:b; } never evaluates to foo=b.
Change-Id: Ibc7376687374065585b125a670dea5fe46bda97a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1347365
Reviewed-on: https://review.coreboot.org/16008
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
These non-ascii & unprintable characters aren't needed.
Change-Id: I129f729f66d6a692de729d76971f7deb7a19c254
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15977
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I7930d5cded290f2605d0c92a9c465a3f0c1291a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15974
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: I5aa27f06f82a8309afb6e06c9e462e5792aa9986
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15940
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ie120360fa79aa0f6f6d82606838404bb0b0d9681
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15466
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The declarations of CFG_ evaluate to correct values only when
included after the definitions of BLDCFG_ in buildOpts.c.
So we never have CFG_PLAT_NUM_IO_APICS defined here.
Change-Id: I94b3dee5a3207b37921eb24a0bcd73b5a217b2d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14887
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing DIMM size calculation for DDR3 was incorrect. Use
the recommended calculation from the DDR3 SPD specification.
Change-Id: Id6a39e2b38b5d9f483341ebef8f2960ae52bda6c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14739
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
While some stubs existed before this patch to handle non-ECC
memory initialization, there were a number of ECC detect unaware
sections of code. Add ECC support detection to those sections.
Change-Id: I56dad8a0f6833b2f42796212afb9777e9cc73d6d
Tested-On: ASUS KGPE-D16
Tested-With: 1x Opteron 6262
Tested-With: 1x SuperTalent 4G non-ECC DIMM in slot A2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14737
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
gcc 6.1 complains that SMM_OFFSET << 8 is larger than the register
it is assigned to (rightly so):
src/northbridge/amd/gx2/northbridgeinit.c:196:23: error: result of
'1077936128 << 8' requires 40 bits to represent, but 'int' only
has 32 bits [-Werror=shift-overflow=]
msr.lo = (SMM_OFFSET << 8) & 0xfff00000;
^~
Change-Id: Ib0d669268202d222574abee335a6a65c8a255cc7
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14617
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The ECC check bits of all ECC DIMMS were inadvertently initialized
twice in the same routine, significantly delaying startup. Part
of this was related to an obsolete MCA workaround that has been
fixed through multiple commits, therefore the workaround is no
longer needed.
Only initialize the ECC check bits once.
Change-Id: I90ac1147d9b006794d29b866a9cb5b7ead8f01e7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14503
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Idb948acd1a508379f600fbd2fd40fb26b7571d7c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14545
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
During receiver enable cycle training on Family 15h the entire range
of possible delays is searched, even though the single passing window
is often found nearly immediately. Skip the remainder of the delay
range after the passing window has been located.
Change-Id: If98217fa8e7de77366762d3c7bb01049a1dc080f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14544
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
During DQS receiver enable cycle training on Family 15h platforms the
read data timing registers were inadvertently set to zero on every
lane training attempt.
Ensure that the read data timing registers are correctly set after
each lane is trained in receiver enable cycle training. This allows
more than one RDIMM to function on a given DCT channel.
Change-Id: I87d732f0383e9785a73b57e6f48855f3e872f1f9
Tested-On: ASUS KGPE-D16
Tested-With: 1x Opteron 6262HE
Tested-With: 4x Crucial 36KSF1G72PZ-1G6M1 (slots A2 / A1 / B2 / B1)
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14543
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I1f5b024606093dc81de3f3d69b7a43e20141b709
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14542
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing Family 15h receiver enable training code stored
temporary delay values in the wrong variables, leading to
the requisite averaging of delays across nibbles not being
applied. This in turn made x4 DIMMs less stable than they
should have been.
Store temporary nibble delay values in a dedicated array.
Change-Id: Ic5da898af7d689db4110211f89b886ccdbb5f78f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14541
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
DIMM training can sporadically fail due to external influences or various
errata. In these cases, restarting to retry training is a more appropriate
response than halting the system and requiring manual intervention.
Change-Id: Id49f7419f56e0640a84448cc06ecbaf62bed145e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14529
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The wrong DIMM number was used in the initial non-target MRS
setup routines. This had no functional impact other than to
print the wrong DIMM number in the DDR3 verbose debug output.
Change-Id: I480118ed00e1786a06e641a56f0fb19cd87f92eb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14501
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing RDIMM RC control word send routines were a hodgepodge
of various AGESA chunks with different ways of handling the same
task. Unify the control word chip select setup, use precise timing
routines on Family 15h, fix a couple of incorrect masks, and add
additional debugging statements.
It is believed that this patch is cosmetic and does not significantly
alter existing functionality.
Change-Id: Ie4ec7b6a7be7fce09e89f9eec146cc98b15b6160
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14500
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When more than one DIMM is installed on a DCT, only the first DIMM
delay values are scaled to the new memory clock frequency after a
memory clock change during write leveling.
Store the previous memory clock of each DIMM during write leveling
to ensure that every DIMM has its delay values rescaled.
Change-Id: I56e816d3d3256925598219d92783246f5f4ab567
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14479
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
After substantial testing it has been determined that it is neither
required nor safe to disable the DRAM MCA during initial startup.
This (mostly) reverts commit c094d9961144871c472698c41ce634e58abb6a32.
The minor debugging enhancements from that commit were left in place.
Tested-On: ASUS KGPE-D16
Config-CPU: 1x Opteron 6262HE
Config-RAM: 4x Crucial 36KSF1G72PZ-1G6M1
Config-RAM: 1x Kingston 9965516-483.A00LF
Change-Id: I58fcc296b8c45ecaedf540951c365e4ce52baaf5
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14446
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I5056cf885b7063a97c095bfaaf01dd8da777a425
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14447
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain RDIMMs have inherently large write levelling delays,
in some cases exceeding 1.5 MEMCLK. When these DIMMs are
utilized, the phase recovery system requires special handling
due to the resultant offset exceeding the phase recovery reporting
capabilities.
Fix an old error where delays > 1.5 MEMCLK were not being programmed
(gross delay high bit was not in set range), and restore special
delay handling for delays greater than 1.5 MEMCLK.
Also enhance debugging for x4 DIMMs around the affected code.
Tested-On: ASUS KGPE-D16
Config-CPU: 1x Opteron 6262HE
Config-RAM: 4x Crucial 36KSF1G72PZ-1G6M1
Change-Id: I0fb5454c4d5a9f308cc735597607f095fe9188db
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14441
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The BKDG requires phy fences to be re-trained after a memory clock change.
Memory training on the ASUS KGPE-D16 and KCMA-D8 somehow "mostly" worked
-- without actually following this requirement -- !
Fix the single typo that caused several weeks of delay in putting
servers with Kingston RAM (and others) into production...
Tested-On: ASUS KGPE-D16
Config-CPU: 1x Opteron 6262HE
Config-RAM: 4x Crucial 36KSF1G72PZ-1G6M1
Change-Id: I197e6728d2b0ac8c1535740599459d080b17af33
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14445
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
We never define B1_IMAGE or B2_IMAGE. These are about building
CIMx as separate binary modules, while coreboot builds these into
same romstage or ramstage module.
Change-Id: I9cfa3f0bff8332aff4b661d56d0e7b340a992992
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kerry Sheh <shekairui@gmail.com>
|
|
gcc doesn't like these because they're undefined behavior, so use
zeroptr instead. For the loop that just does a number of writes (0..4),
use zeroptr + i.
Checked the disassembly (AMD_RUMBA and PCENGINES_ALIX2D) to not contain
ud2 anymore and to look reasonable where zeroptr was used.
Change-Id: I4a58220ec9a10c465909ca4ecbe5366d0a8cc0df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14345
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Trivial; Use tab over space for indent. Clean up some ASCII art
while here.
Change-Id: Id2478d140a98596c5eeefdf5b047c1ca23203909
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/8016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Two of the MCT data structures passed as substructures to ramstage were
not packed, and additionally no alignment was specified. On at least
SP5100-based platforms, specifying packed with no alignment caused boot
failure dependent on the exact compiled binary layout (LPC hang).
Specifying the alignment and packing the remaining structures appears to
have resolved the remaining LPC hang issues on the KGPE-D16. Note that
packing the remaining structures alone was not sufficient to eliminate
the hang, however removing the packed attribute entirely (during debugging)
did resolve the hang at the expense of potential problems in ramstage.
Change-Id: If3a7509ed438870d4d05caaaaa091e1c47bf9b97
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14303
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
The SPI controller needs to be set up on devices such as the SP5100
before it can be accessed to write MCT backup data. Move the backup
data write after PCI configuration has been completed.
Change-Id: Ibcf31755242ac058407a422ce8aa33d6b0b293c7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14305
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This reverts commit f961becc433bf23fc8744fdfd757f0cdb75c2c62.
On studying the BKDG more closely this is not the correct place
to enable DIMM parity. Further patches to clarify the parity
setup process on Family 15h are forthcoming.
Change-Id: I5a3a4f1621e3048f9dfc159709410be9de6ebecd
Reviewed-on: https://review.coreboot.org/14271
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The sync flood reset fix in Change-Id: I62d897010a8120aa14b4cb8d096bc4f2edc5f248
and related changes have made it possible to move the sync flood enable statements
back into romstage.
Change-Id: I5a3a4f1621e3048f9dfc159709410be9de6ebece
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14270
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When a fatal error and subsequent sync flood / reset occurs,
the MCA status registers may contain valuable information on
the cause of the fatal error. Add functions to report MCEs and
reset the MCA status registers early in the boot process.
Change-Id: Icde1051ac22f93688de1330f5e2c9ce28b14b59a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14265
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I42d901ae9445943a863fb3ba9bda5a915f255e02
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14264
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: Martin Roth <martinroth@google.com>
|
|
Certain AMD platforms, such as those using the SP5100 southbridge,
contain a very poorly documented bug related to LPC ROM access,
which is triggered by repeated (hundreds or more) rapid calls to
get_option(). This bug manifests as a complete system deadlock
in ramstage device configuration, requiring standby power to be
removed from the system to release the deadlock.
Cache the platform ECC status to avoid repeated calls to get_option()
in the lane count detection logic.
Change-Id: I8b48c523218ccc8c113319957d6eca2d15e1070f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14273
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The revision mask for all DR-* series processors was incorrectly
set to only include the DR-B revision mask. Include all DR-*
series prcessors in the DR_ALL revision mask.
Change-Id: Iceda96aa6267b24abcbf78d39f4848d2be8053b8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Found-by: Coverity, CID 1229627 (#1 of 1): Logically dead code (DEADCODE)
Reviewed-on: https://review.coreboot.org/14216
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Enabling sync flood on DRAM MCE directly after ECC clear can
lead to a system hang with no way to determine the offending
DRAM module. Clear MCEs after ECC setup, but do not enable
sync flood until NB setup in ramstage to allow time for any
MCEs to accumulate in the status registers. Before enabling
sync flood on MCE, determine if any MCEs were logged during
ramstage execution and display them on the serial console.
Also clear the DRAM ECC sync flood bits during DRAM training
and initial ramstage execution.
Change-Id: Ibd93801be2eed06d89c8d306c14aef5558dd5a15
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14192
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
During power on from cold (S5) state, numerous MCEs are generated
before DRAM training starts, e.g. during HT link training. Clear
these MCEs before DRAM training start, and report any MCEs generated
during DRAM training.
Change-Id: I7d047571242e5bd041e4aac22c1ec1d7d26ef0e6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14191
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
On Family 15h processors, with certain RDIMMs, MCEs are generated
as a normal part of DCT startup / DRAM training. Disable sync
flood on parity or UC data error until ECC has been enabled.
Change-Id: Ife54751ff127ffd59baaad35d3fea14ea01ef505
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14186
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This resolves a long-standing issue with RDIMM control word
configuration failure, likely due to random parity failure.
Change-Id: If8b8dc5b8b99f4c2fe29b3a133b064631e4693be
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14184
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I96d695ed10176276116fcf3a2b77605fb3f2d5db
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13710
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Replace open coded memset() functions with calls to the library function.
The new code also explicitly backs up and restores the data structures
that are preserved across calls to mct_ResetDataStruct_D(), and no longer
relies on structure member order to function correctly.
Change-Id: I6dd6377deda0087cd1b65f7555588978657d6516
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic5482dc13ab7b53ec4df408bbe32d20888ae2e12
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13725
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
During maximum read latency training on Family 15h processors,
the maximum read latency was incorrectly set from the NBP1
value instead of the correct NBP0 value.
Modify maximimum read latency training to explicitly operate
on the NBP0 value, and store the previously calculated NBP1
value for reference by other portions of the training algorithm.
Change-Id: I5d4a6c2def83df3e23f1a4c598314c31a0172cd7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14150
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
dqsTrainMaxRdLatency_SW_Fam15()
Change-Id: Ic3f636983cf6ba2796ee56e2a25b56513a4343c1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14148
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Under certain conditions (training abort) BlockRxDqsLock could
remain set in violation of the BKDG. Ensure BlockRxDqsLock is
reset to 0 after a lane training abort.
Change-Id: I1a49a24d02b2b7cacae074794ec274a424a9e66b
Reviewed-on: https://review.coreboot.org/14144
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Rebasing change I3be808db5d15ceec4c36d17582756b01425df09a
did not take into account the default UI setting introduced in
change I6ae88c891e92b21dc0ca3c47b8f3d269f83b3204 , causing DRAM
instability and occassional failure to boot.
Use the correct 1UI value for the modified function semantics.
Change-Id: I9fd24cf83e4c4083c6e467d49021c98e5f5f2c53
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14073
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: Martin Roth <martinroth@google.com>
|
|
read_dqs_read_data_timing_registers() and
read_read_dqs_timing_control_registers() served essentially
the same function but had slightly different semantics,
causing confusion and needlessly complex Family15h code.
Consolidate both into read_dqs_read_data_timing_registers()
and adjust surrounding code to match new semantics.
Change-Id: I3be808db5d15ceec4c36d17582756b01425df09a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13994
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ia26950a8297f0a7125c21e995c89a3fc68d9d8a9
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13932
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I4497b0be6ed6c90dbb31e89013feed8ff5ff9071
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13885
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The existing MCT code proceeded to the next DRAM training phase if
the minimum lane quality standard passed for either the read or
write direction. Ensure that both pass for a given set of delay
values before proceeding to the next training phase.
Change-Id: I2316ca639f58a23cf64bea56290e9422e02edf1c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13993
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The AMD Family 15h BKDG rev. 3.14 indicates that the maximum read latency
must be calculated prior to DQS position training, however the read
latency calculations use read DQS delay values that have not been
set prior to DQS position training.
Set the read DQS delay values to 1UI (i.e worst case) before calculating
the read latency prior to DQS position training.
Change-Id: I6ae88c891e92b21dc0ca3c47b8f3d269f83b3204
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13995
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: Martin Roth <martinroth@google.com>
|
|
A couple of arrays were not properly initialized. This
did not appear to affect operation of the codebase however
it led to some ugly values being displayed when debugging
was turned on.
Also bounds check an array index; as before this did not
appear to affect operation but was a potential point of
failure.
Change-Id: I243b7197a74aed78ddca808eb3b0f35f1fe9d95a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13934
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Iacfcd7f379d09a633973b4c3ef3cbb97e6d1f09f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13931
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I1088064e5f84fcabcd51e0eaaedfb5074f7fb2b5
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13709
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Certain registered DIMMs failed training due to an error
likely introduced during historical rebase. Ensure that
the SubMemclkRegDly bit is set according to BKDG
recommendations on Family 15 processors.
Change-Id: I24c95265dada9eabf4df280b6f2b4a1eb9cecaf1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13148
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Under certain conditions, not elucidated in the BKDG,
an extra memclock of CAS write latency is required.
The only reliable way I have found to detect when this
is required is to try training without the delay, and
if DQS position training fails, adding the delay and
retraining.
This is probably related in some form or another to
the badly broken DQS Write Early algorithm given
in the BKDG.
Change-Id: Idfaca1b3da3f45793d210980e952ccdfc9ba1410
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13531
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This fixes some spelling and whitespace issues that I came across
while working on various things in the tree.
There are no functional changes.
Change-Id: I33bc77282f2f94a1fc5f1bc713e44f72db20c1ab
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13016
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ib331bd330530d4d6be5eb7351d9f9b15c135dd63
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13167
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing code used an incorrect macro name to check for mainboard
DRAM voltage set support, and as a result no voltages were actually
set. Furthermore, the existing code did not contain a centralized
voltage assumption for boards that did not have a DIMM voltage set
implementation.
Use the correct macro name to test for boards with voltage set
implementation, and provide a basic fallback to 1.5V operation
for boards without a voltage set implementation.
Change-Id: I638c65fe013a8e600694d8cbedf6a10b33b0ef95
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13150
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing code generated an incorrect boot APIC ID from node and
core number for single node packages, leading to a boot failure when
the second node was installed.
Properly generate the boot APIC ID from node and core number.
Change-Id: I7a00e216a6841c527b0a016fa07befb42162414a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13149
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing code accidentally truncated the MSB from the MR0
WR value. While this probably had a minimal effect in reality,
it should be configured correctly for maximal system stability.
Change-Id: Ifb8a39c6ca47b32b44d33735e5c6c39f1dc5a44e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13147
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Ie91c990d9c2bcab8292a75d87523a46d5694a34a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13146
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The existing drive strength calibration code did not strictly
follow the BKDG-defined setup process. Bring the calibration
code in line with the BKDG recommendations.
Change-Id: I122eeb93958d88de59d0c3b2979f607afa2c52c3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13145
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When an Extended Temperature Range DIMM is installed on a channel
the refresh rate should be increased per the BKDG recommendations
to allow correct operation at higher temperature ranges.
Set fast refresh on a channel if an ETR DIMM is installed on that
channel.
Change-Id: I7a085d34efc78f3f0794a5cb33b88f27a5e6d54e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13144
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The existing MCT initialization code was largely missing C32 socket-
specific configuration data. Add C32 socket-specific timing and ODT
values as specified in the BKDG.
Change-Id: I8eef8d5c8581f03d269663a338d5542744c5cdd7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13141
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The existing code applied G34-specific speed limits to all socket
types. Update G34 and C32 specific speed limits to be in line with
BKDG recommendations.
Change-Id: I958ad333c47948ae741a56de5866af3e636fd24d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13140
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
