| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I99e5d7f3b46c90ca863ddf6c186b5447d0c8e6f2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14607
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: I16c04452d2d6c3205aea29fe8aa8fad8fc485a46
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14600
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The PLL will never lock if the requested frequency is already set.
As the fallback may request the same frequency again exit early
to prevent a hang.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: I625b2956346d8c50cca84def6190c076bf99dbec
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14174
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the following fallbacks:
* Try decreasing clock frequency.
In case of DDR1600 the next possible value of DDR1333 is being used.
* Try decreasing clock frequency.
In case of DDR1333 the next possible value of DDR1066 is being used.
* Disable failing channel.
The system may be able to boot with a single channel enabled.
The fallbacks are untested.
Change-Id: I3be7034ad25312b3ebf47a54f335a3893f8d7cc1
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14173
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The LVDS port is configured to accept data from pipe A, but the panel
fitter and VGA were attached to pipe B.
Changes to VGACNTRL:
- select pipe A instead of pipe B.
- disable VGA centering to fix jitter.
TEST=Build and run on Thinkpad X200 in both text and framebuffer modes.
Change-Id: I2356f264580d8b021952c217de3477291d866f98
Signed-off-by: Nick High <nhigh@openmailbox.org>
Reviewed-on: https://review.coreboot.org/14524
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.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>
|
|
Fix regression introduced by:
Ib48fe8380446846df17d37b22968f7d4fd6b9b13
Don't run channel_test on S3 resume as it overrides memory
that might be in use.
Fixes MCE events reported by the GNU/Linux kernel that
low memory has been modified.
Reset on failed s3 resume.
Change-Id: Ibadea286619c7906225f86a93aaa0b4caf26cabe
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14439
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@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>
|
|
Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make
them pluggable.
Also, fix up the following driver subdirectories by switching
to the src/drivers/[X]/[Y]/ scheme as these are hard requirements
for the main change:
* drivers/intel
* drivers/pc80
* drivers/dec
Change-Id: I455d3089a317181d5b99bf658df759ec728a5f6b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14047
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.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>
|
|
Always use MRC cache if possible.
Added a CRC16 array to make sure the DIMMs haven't been replaced.
In case one of the CRC's doesn't match, start normal RAM training.
Use new fallback in case of broken mrc cache.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Test result:
The system boots a lot faster using the MRC cache.
On swapping DIMMs the CRC16 doesn't match and normal ram training
is started.
Change-Id: Ib48fe8380446846df17d37b22968f7d4fd6b9b13
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
In error case die in top level function.
No functionality is changed.
Change-Id: Ie15b01184d40bdbce20d49dcab2f9fb607068c7a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14171
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Return errors to top level ram init function.
Required by the folowing series to implement a fallback.
No functionality is changed.
On error case the system still halts in every test.
Change-Id: I6278c4a1d7b4a96be8988a60671fc3d72cd6cb3d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14170
Tested-by: build bot (Jenkins)
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>
|
|
In order to add a fallback mechanism, move the ram training code
into a new function. This function will be called multiple times
and must return error or success to the calling function.
Change-Id: I5ee1b3a528290d8252d236b9152b81291736958a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14169
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It's required to store the dimm_info in ramctr_timing as only ramctr_timing
is written to mrc cache.
Allows to fill SMBIOS type 17 if mrc cache is used.
Change-Id: I7634b05069df307d471938d9854997a018de81b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
|
|
The Intel i3100 northbridge code is the only user of
cache_ramstage(). Therefore, place it next to the sole
consumer.
Change-Id: If15fb8d84f98dce7f4de9e089ec33035622d8f74
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14097
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@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>
|
|
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i3100 boards in the chipset.
Change-Id: Ia66a0561c75777a9e98bb87117859808a2ff3732
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13786
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i810 boards in the chipset.
Change-Id: Ifda7dcfdf37b6affce838ee96ca6382b2d4be8c3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13784
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i830 boards in the chipset.
Change-Id: I0a63ddd3c5e43ea65f776385f54eceb6569751ac
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13783
Tested-by: build bot (Jenkins)
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 sourcecode is 99% the same. Only two lines differ, but not
in functionality.
Also rename mrccache.c -> mrc_cache.c
Tested-on: boot + suspend/resume on x220
Change-Id: I36f79d066336f223b608c70c847ea6ea6e4ad287
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14007
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The mrc_cache definition and the struct mrc_container are the same
over all intel platforms.
Change-Id: I128a4b5693d27ead709325c597ffe68a0cc78bab
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13998
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I2738da99e4651598faeaa228fba447d0872e9ded
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13999
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
|
|
Commit 71512b2c (northbridge/i945/gma: fix build error with native graphics init)
unintentionally changed the code to ignore the NVRAM setting
`tft_brightness`. Revert that hunk to restore the original behavior.
Change-Id: Iffdfc5272732bad3476f35ddac1f5a7564270531
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14002
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i440BX boards in the chipset.
Change-Id: I411191927f3fba1d0749edcf79378e8013fb195a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This is a step towards isolating the timer drivers.
Change-Id: I4c9349054be0cf520cd4407be9fb393b664223a4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13922
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Sandy and Ivy Bridge processors use the same socket, and a mainboard
with the socket can support both types of CPUs. However, they use
different native graphics init code for LVDS and cause a crash if
running the wrong code.
This change detects the CPU type and then selects the right code to
run. It will add some more code in ramstage. It also merges the
{SANDY,IVY}BRIDGE_LVDS symbol to one SANDYBRIDGE_IVYBRIDGE_LVDS.
Tested on a Lenovo T520 with i7-2630qm and i7-3720qm
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Change-Id: I4624759f9c92d56d547db1ab4b9a1d611a182a91
Reviewed-on: https://review.coreboot.org/12087
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Fill minimal info required for SMBIOS type 17.
Report
* DIMM size
* channel
* rank per DIMM
* speed in Mhz
* DIMM type
* slot
* manufacturer ID
* serial
Allows dmidecode to print the current RAM configuration.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* Linux 4.3
* dmidecode 3.0
dmidecode output:
Handle 0x0005, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0000
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 8 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Unknown (cd04)
Serial Number: None
Asset Tag: Not Specified
Part Number: F3-1866C9-8GSR
Rank: 2
Configured Clock Speed: 1600 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Handle 0x0006, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0000
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 8 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: Channel-1-DIMM-1
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Unknown (cd04)
Serial Number: None
Asset Tag: Not Specified
Part Number: F3-1866C9-8GSR
Rank: 2
Configured Clock Speed: 1600 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Change-Id: I4e5f772d68484b9cb178ca8a1d63ad99839f3993
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13852
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of hardcoding the maximum supported DDR frequency to
800Mhz (DDR3-1600), read the fuse bits that encode this information.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: I515a2695a490f16aeb946bfaf3a1e860c607cba9
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13487
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The code can't handle cyclic zero runs. Make sure it will never
wrap around by setting the top-most bit to constant one.
Fixes "Mini channel test failed (2)".
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: I55e610d984d564bd4675f9318dead6d6c1e288a3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13853
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
I first found the missing of #include guards when I tried to include
both sandybridge/gma.h and sandybridge/sandybridge.h, but
sandybridge.h includes gma.h in it and gives a compile error.
Change-Id: I13fdb8014b82e6065be2064137b7ea10062deaca
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/13775
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Improved version of
I1a115a45d5febf351d89721ece79eaf43f7ee8a0
The first version wasn't well tested due to the lack of hardware
and it was to aggressive.
With timC being direct function of timB's 6 LSBs it's critical to match
timC and timB.
Some tests increments the value of timB by a small value,
which might cause the 6bit value to overflow, if it's close
to 0x3F.
Increment the value by a small offset if it's likely
to overflow, to make sure it won't overflow while running
tests and bricks the system due to a non matching timC.
In comparission to the first attempt, only 4 out of 128 timB values
are considered bad.
Needs test on real hardware !
Fixes a "edge write discovery failed" on my test system.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: If9abfc5f92e20a8f39c6f50cc709ca1cedf6827d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ib73abb0ada7dfdfab3487c005719e19f51ef1812
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: https://review.coreboot.org/13779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Some vendors store lower frequency profiles in the regular SPD,
if the SPD contains a XMP profile. To make use of the board's and DIMM's
maximum supported DRAM frequency, try to parse the XMP profile and
use it instead.
Validate the XMP profile to make sure that the installed DIMM count
per channel is supported and the requested voltage is supported.
To reduce complexity only XMP Profile 1 is read.
Allows my DRAM to run at 800Mhz instead of 666Mhz as encoded in the
default SPD.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: Ib4dd68debfdcfdce138e813ad5b0e8e2ce3a40b2
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13486
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
Use printram() in more places and use printk() only where
it makes sense.
Remove spamming "MRd: %x <= %x\n".
Use common syntax for timing output.
Change-Id: I38965967a029994112d7ab63afd4d9968a7728c5
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13414
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Issue observed:
The PCIe Root port shows up in GNU/Linux but no PCIe device
is being detected.
Test system:
* Gigabyte GA-B75M-D3H (Intel Pentium CPU G2130)
* Lenovo T530 (Intel Core i5-3320M CPU)
Problem description:
The PEG Root port link training on Ivy Bridge needs to be manually started.
Problem solution:
The bits are set in early_init to meet PCIe reset timeout of 100msec.
The bits should be set in PCI device enable function, but this causes the
PCI enumeration to not detect the card, as it's still booting. Adding
a fixed delay of 100msec resolves this problem, but this would
increase boot time.
Read the PCI base revision mask to make sure it's any IvyBridge CPU.
Don't run the code on MRC path as it has its own PEG initilization code.
Tested with:
* Nvidia NVS 5400M (PCIe2)
* ATI Radeon HD4780 (PCIe2)
* Nvidia GeForce 8600 GT (PCIe1)
Untested:
* PCIe3 devices
Final test results:
The PEG device shows up under GNU/Linux and can be used without issues.
Change-Id: Id8cfc43e5c4630b0ac217d98bb857c3308e6015b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/11917
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Use shared gpio code from common folder.
Bd82x6x's gpio.c and gpio.h is used by other southbridges
as well and will be removed once it is unused.
Change-Id: I8bd981c4696c174152cf41caefa6c083650d283a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13614
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It looks like the falling timing was missing the shift offset.
Not sure if this was intentional, I guess not.
Tested on my hardware and produced no regressions.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Please test on real hardware !
Change-Id: Id8c60217093a48bf322f406ea258c10a02c936e8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13682
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Otherwise the image is simply unusable.
Change-Id: I1e2562ba17279d14dc73b05e4f8fa493e06fbcd2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13699
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Tested by making lenovo x230 configurable despite pretty MRC bugs.
Change-Id: Ia2a123f24334f5cd5f42473b7ce7f3d77c0e65b7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13658
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I11e09804ed1d8a7ae8b8d4502bd18f6be933f9fa
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13656
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In the same time remove few native gfx options which were improperly set
and only added dead code to the binary.
Change-Id: I4ed3fec03a1655ae0a779c3aa3845de273cb12e1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13649
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
This is needed for stout EC init.
Change-Id: I5c73499c17763229840152a473a2d820802ee2f6
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13535
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This reverts commit 0e06f5bd70b45fd330d8dfb1dc77cce043caf841.
It breaks gm45 and also does some magic without being asked too. It
disables bridge devices permanently if no device was found on the se-
condary bus. In a simple notebook world this might be ok, but it breaks
hot-plugging and late detection (if a secondary bus device comes up too
slow for the firmware to detect and the OS has to enumerate it).
Change-Id: Ia2010640d7c55b0bdd44164b81c75dd4be50410b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/13609
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
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>
|
|
Walk the bus and try to find enabled devices.
Disable the PEG port if no devices are attached.
Change-Id: I67fcc831fd78ecc6dba83f4e0662ec7549cc2591
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/12894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Issue observed:
The system boots with 4G in channel 0 and 4G in channel 1.
The system doesn't boot with any combination of 4G + 1G in
channel 0 and 4G in channel 1.
In both cases DIMM1 failed, while DIMM0 showed no issues.
Problem description:
The CLK to CMD/CTL was off by a half clock cycle.
The find the issue I X-Y plotted timC vs timB for every
lane on the failing rank.
You can see an offset by 32 units for timB, that is not present on
other ranks.
It turns out that the XOVER CMD/XOVER CTL enable bit for DIMM1 was
missing in program_timings(), which caused the clock offset.
Problem solution:
Add two functions to calculate XOVER CMD and XOVER CTL and use both
to set XOVER in program_timings() and dram_xover().
Final testing result:
The system boots with 4G + 1G in channel 0 and 4G in channel 1.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: I88694c86054ade77e9d8bb2f1fdaf7bc559c1218
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13415
Tested-by: build bot (Jenkins)
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>
|
|
On certain Winbond SuperIO devices, when a PS/2 mouse is not
present on the auxiliary channel both channels will cease to
function if the auxiliary channel is probed while the primary
channel is active. Therefore, knowledge of mouse presence
must be gathered by coreboot during early boot, and used to
enable or disable the auxiliary PS/2 port before control is
passed to the operating system.
Add auxiliary channel PS/2 device presence detect, and update
the Winbond W83667HG-A driver to flag the auxiliary channel as
disabled if no device was detected.
Change-Id: I76274493dacc9016ac6d0dff8548d1dc931c6266
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It break x230 access to channel 1.
This reverts commit 9f1fbb9a3002e8d74d53d7973bd1c7e3d4879238.
Change-Id: I8a3b13d17729f25cea3460ac2f87bca3c193d388
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
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>
|
|
Previously with errors in the ram init, early cbmem was disabled.
Now that the ram is working correctly, set as early cbmem platform
and update all (1) boards to use it.
Tested on GA-G41M-ES2L
Change-Id: I5925c28821537f0e326b4f5a2ac39778e4724a3c
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13131
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Tidy up the code and move vga_textmode_init() later
Change-Id: I49967e7197416c955ae6c8775eac7d1a60c92d1c
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13128
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
- Fix bug with msbpos, it was not returning the correct result
due to typo in logic, and unsigned value needed to be negative.
- Add reclaim above 4GiB
- Fix to ME related registers near the end of raminit
Change-Id: I04acd0593a457437ee4a42e14b287b2b17a160af
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13127
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
- Add device enable macros
- Set the PMBASE correctly through southbridge device
Change-Id: I1b8cc3de96b1ecaf01e31bad8fba1fada8671c2d
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13126
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Previously, 0xa0000000 to 0xc0000000 needed to be reserved as
a non-usable memory hole because it would hang on memory i/o.
Memtest86+ now passes with no errors on both channels populated.
Tested on GA-G41M-ES2L with 2x2GiB sticks of ram.
Change-Id: Ib52a63a80f5f69c16841f10ddb896ab3c7d30462
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13125
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
