Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code originates from times before __SIMPLE_DEVICE__ was
introduced. To keep behaviour unchanged, use explicit PCI
IO operations here.
Change-Id: I44851633115f9aee4c308fd3711571a4b14c5f2f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17720
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: Id6ec25706b52441259e7dc1582f9a4ce8b154083
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17534
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: If31bc0a67b480bcc1d955632f413f5cdeec51a54
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RW flag was added to spi_slave structure to get around a requirement on
some AMD flash controllers that need to group together all spi volatile
operations (write/erase). This rw flag is not a property or attribute of
the SPI slave or controller. Thus, instead of saving it in spi_slave
structure, clean up the SPI flash driver interface. This allows
chipsets/mainboards (that require volatile operations to be grouped) to
indicate beginning and end of such grouped operations.
New user APIs are added to allow users to perform probe, read, write,
erase, volatile group begin and end operations. Callbacks defined in
spi_flash structure are expected to be used only by the SPI flash
driver. Any chipset that requires grouping of volatile operations can
select the newly added Kconfig option SPI_FLASH_HAS_VOLATILE_GROUP and
define callbacks for chipset_volatile_group_{begin,end}.
spi_claim_bus/spi_release_bus calls have been removed from the SPI flash
chip drivers which end up calling do_spi_flash_cmd since it already has
required calls for claiming and releasing SPI bus before performing a
read/write operation.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Idfc052e82ec15b6c9fa874cee7a61bd06e923fbf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17462
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
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>
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>
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>
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>
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>
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 c094d99611.
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>
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 f961becc43.
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>
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>
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>
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>
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>
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>
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>
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>
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>
This just updates existing guard name comments on the header files
to match the actual #define name.
As a side effect, if there was no newline at the end of these files,
one was added.
Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This continues what was done in commit a73b93157f
(tree: drop last paragraph of GPL copyright header)
Change-Id: Ifb8d2d13f7787657445817bdde8dc15df375e173
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12914
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit d3deecdd9c.
Do not mix open-source AGESA and binary PI trees. Once you have
working S3 support for binaryPI platforms, add the adapted
oem_s3.c file as northbridge/amd/pi/oem_s3.c instead.
Change-Id: I7c981d0023a5c0225e046f9c0104acfa07436b79
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/12282
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
As the southbridge largely controls the PCI[e] configuration space
this patch moves the resource allocation from the northbridge
to the southbridge when the extended configuration space region
is enabled.
Change-Id: I0c4ba74ddcc727cd92b848d5d3240e6f9f392101
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12050
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
The Kconfig symbols were missing an underscore, so were not getting
evaluated properly.
Change-Id: I619cf3f44f44f9c9699482d64164d3db28cd4c8f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12559
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In coreboot, bool, hex, and int type symbols are ALWAYS defined.
Change-Id: I58a36b37075988bb5ff67ac692c7d93c145b0dbc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The PER_DEVICE_ACPI_TABLES Kconfig symbol is no longer used as it was
removed in commit 83f81cad (acpi: Remove monolithic ACPI)
Change-Id: Ie6ba252f6e7d33da9d4500f1201367f116e4c505
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12554
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The existing code re-used the Family 10h XCS buffer setup on
Family 15h CPUs, which set incorrect values leading to random
system lockups.
Use the Family 15h XCS buffer setup shown in the BKDG.
Change-Id: Ie4bc8b3ea6b110bc507beda025de53d828118f55
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12070
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The secondary bus number set code incorrectly overwrote the link
buffer settings in F0x[F4,D4,B4,94]. Constrain the secondary
bus number set to the appropriate bits of the registers.
Change-Id: If70825449f298aa66f7f8b76dbd7367455a6deb1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12068
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The Family 15h DRAM initialization did not set up the various
tristate enable codes in the MCT.
Add Family 15h tristate enable setup. This fixes multiple
DIMMs on a single channel.
Change-Id: I0278656e98461882d0a64519dfde54a6cf28ab0f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12060
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
The Kconfig symbol CONFIG_HT3_SUPPORT is not implemented.
This mirrors commit c5163ed8 (AMD binaryPI: Drop HT3_SUPPORT)
Change-Id: I2682d3b620e2cee613c7421622a8c79db5ba3a86
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12556
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
There is no need to continue testing a DCT configuration after
data errors have already been detected; this just wastes time
during boot.
Change-Id: I979e27c32a3e0b101590fba0de3d7a25d6fc44d2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12066
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The BKDG recommends the use of an antiphase window detection
algorithm to ensure that the DQS data eye is properly centered.
TEST: Booted both with DIMMs known to move the data eye into the
prior clock phase and DIMMs known to keep the data eye in the
current clock phase.
Change-Id: I1d85fddd45197ca82dcaa46fe863e64589712d1f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12059
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Martin Roth <martinroth@google.com>
The odd rank of each DIMM could experience data corruption due to
incorrect DQS training. Fix the DQS training algorithm by executing
the relevant portions of the training algorithm on the odd ranks.
Change-Id: Ibc51f5052d5189e45b3d9aa98ca8febbfe13f178
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12058
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Also fix incorrect Trfc[0-3] value on Family 15h.
Change-Id: Iafc233984ae1d44fe6a1cb5b109d36397cbd991a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12055
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The silicon in control of CC6 appears to contain minor bugs
and / or deviations from the BKDG; through trial and error
it was found that these issues can be worked around by reserving
the entire possible CC6 save region, regardless of currently
installed node count.
Change-Id: If31140651f25f9c524a824b2da552ce3690eae18
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12054
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The coherent fabric on all Family 10h/15h devices supports
isochronous mode, which is required for IOMMU operation.
Add initial support for isochronous operation.
Change-Id: Idd7c9b94a65f856b0059e1d45f8719d9475771b6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12042
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Certain workloads may evict too many lines of other cores from the
L3 cache if configured as one monolithic shared cache region.
Forcibly partition L3 cache to improve performance.
Change-Id: Ie4e28dd886aaa1c586b0919c5fe87ef1696f47e9
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12036
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing code generated an invalid NUMA table
that was rejected by Linux, leading to poor resource
allocation. This was due to system MMIO resources
being inserted into the table when the table should
only contain DRAM resources.
Do not include system MMIO resources (i.e. resources
with an index less than 0x10) in the NUMA table.
Change-Id: I99c200382b52a99687daf266a84873d9ae2df025
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12035
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Stability issues have arisen on multiple Family 15h systems
when configuration restoration is enabled. In all cases these
stability issues resolved by allowing the RAM to go through a
full training cycle.
Change-Id: I017e0dd5120110124d5b5d5276befef6f7740614
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12034
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The BKDG is not correct regarding HT Freq write ordering;
indicate this in a comment to avoid confusion.
Change-Id: I37db191c144c81aba5d4a1e6291db5669a35a31a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12030
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.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>
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>
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>
