| Age | Commit message (Collapse) | Author |
|---|
|
There were numerous issues surrounding AMD ECC initialization on
Family 15h processors due to the incomplete derivation from Family
10h MCT code. Bring the Family 15h ECC initialization and supporting
setup code in line with the BKDG recommendations.
Change-Id: I7f009b655f8500aeb22981f7020f1db74cdd6925
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12003
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The existing ECC initialization algorithm contained several bugs on both
Family 10h and Family 15h processors, including activation of ECC scrub
before DRAM setup was completed, in violation of both BKDG and errata
recommendations.
Change-Id: I09a8ea83024186b7ece7d78a4bef1201ab34ff8a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12002
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: Iacd789b3572dc8ee85e76d56c46685e6df31d1a6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12008
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ie7278745358daf0c78cdb9c579db5291a1a2a0cb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12004
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The existing prefetcher configuration was incorrect; use the correct
values from the AMD Family 10h and Family 15h BKDGs as appropriate.
Change-Id: I287ffa6345e1f4d232d4b2ea4251650ada3fda92
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12417
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The existing code enabled ECC before clearing memory. As the
AMD CPUs will generate MCEs on any invalid check bits, this
resulted in random lockups during memory training due to the
uniniailized check bits.
Initialize ECC check bits before enabling ECC hardware.
Change-Id: I992e7040520570893ba6a213138dd57bfa14733b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11996
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain DIMMs, for example DIMMs on which the EEPROM has been modified
by the end user, may not contain a valid SPD checksum. While this is
not a normal condition, it may be useful to allow a checksum override
while memory timing parameters are being altered, e.g. in the course
of overclocking or underclocking, or when recovering from a bad SPD
write.
This is an advanced level feature primarily useful for debugging
and development.
Change-Id: Ia743a13348d0a6e5e4dfffa04ed9582e0f7f3dad
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11987
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: If26e5d148a906d63bd1407b8ffa58f08ae6b4275
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11986
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I47089f2ad886a6fda4e0cd4472efd975bb8e06c5
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11995
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I47755caf7d2ff59463c817e739f9cb2ddd367c18
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11989
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Under specific circumstances, for instance in low power or fanless
machines, it may be useful to cap the maximum P-state of the CPU.
Allow the maximum CPU P-state to be set via an NVRAM option.
Change-Id: Ifdbb1ad11a856f855c59702ae0ee99e95b08520e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11985
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I5fee5f5fdf30ab6e3c4f94ed3e54ea66c1204352
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11980
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This patch adds CC6 power save support to the AMD Family 15h
support code. As CC6 is a complex power saving state that
relies heavily on CPU, northbridge, and southbridge cooperation,
this patch alters significant amounts of code throughout the
tree simultaneously.
Allowing the CPU to enter CC6 allows the second level of turbo
boost to be reached, and also provides significant power savings
when the system is idle due to the complete core shutdown.
Change-Id: I44ce157cda97fb85f3e8f3d7262d4712b5410670
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11979
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
A wrong function name made an #ifdef'd code path not compile. Fix that,
and also use IS_ENABLED() to make sure that such issues won't come up
again there.
Change-Id: Iccb98842dde498cce32cd86a770e22a506ad4cc2
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/12296
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Iae1cbe7d3a6471561abfdb8e182bc764c38bb222
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11978
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ibeb35da3395dc77a21a2f92f0e1d0845be53d175
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
DRAM training accounts for most of the romstage startup time, yet
if the hardware configuration has not changed from the previous boot
the previously discovered training values are still valid. Use them
if the DIMM configuration has not changed since the last boot.
The SPD values of all installed DIMMs are hashed and stored in the S3
resume data area of the main system Flash device. If a DIMM is changed
the hash will almost certainly change as well, forcing retraining on next
boot.
Change-Id: I37ed277b16476d38e4af76c6ae827a575c6b017d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11976
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Upon bootup the hardware reads at minimum 256 * 16 bytes (4Kb, or 32KB) over
I2C on a system with all DIMM slots populated. If even one of those reads
has a single flipped bit in it (due to EMI, cross coupling with another trace,
or just poor margins on some cheap DIMM) the system will hang and require a
hard reset. In practice I've seen failure rates as high as 1 failed boot in
50 due to this issue, granted with cheap DIMMs, but even so retrying the read
resolves the corruption issue.
I2C is not designed for continuous data transmission with high reliability, and
there is no hardware error checking, therefore a single retry when transferring
this amount of data makes sense.
Change-Id: Ifab63eca2233c63a6a42ab8b7e742f8e47fb2a09
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11975
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I1ad581454e08f7a24395f50623f29ec14e07f5fb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12360
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
Change-Id: Ic16a927a3f1fc6f7cb1aea36a8abe8cc1999cb52
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11973
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Intel northbridge must be paired with a southbridge. Add
the ii89xx southbridge header based on the config setting.
Change-Id: Ied708006310efaba31afe6977ab7e57fe4e5ceec
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/12167
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The RDK amd/db-ft3b-lc board will use this for on-board DDR3.
Change-Id: I2ffd38e7e949d3a60487e91188ddaab04b03d4b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12358
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
|
|
Change-Id: I5c12b5ef8564402601634e9f3528bbf9303e0b33
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11969
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: Id69b339bbed03d7a1f64aa5935721e7e8aab62fa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12265
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
This cast only hides errors in matching the API properly.
Change-Id: I9b878ab997b8ff087a7209f94522646b10b94bf6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12271
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This cast only hides errors in matching the API properly.
Change-Id: Ic396dfb572a50ac5ce5c1c83424e1f17f15bad1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fixed resources have to be declared early.
Change-Id: I03bb846e0685d47e0befc20bf7bc14c06694cb66
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12262
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Fixed resources have to be declared early.
Change-Id: Iedd92e5e7ee43a833bda48e6377da1b78fa4bd81
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12261
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
The plugged devices on PCIe should use IOAPIC2 instead of standard
IOAPIC1. The entries in IOAPIC2 count from the end of IOAPIC1.
The unchanged code worked because the OS uses MSI instead APIC.
To test that, boot linux with parameter pci=nomsi and see if the devices
like NIC work well as they do without the booting parameter.
Change-Id: I893e73f2aab3227381e44406fa285613e4ba2904
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11374
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The touched workaround for Sandy Bridge reserves two memory regions that
could cause graphics corruption if mapped by the integrated graphics
device. To the best of our knowledge, the workaround is not needed for
Ivy Bridge revisions.
Tested on kontron/ktqm77 (Ivy Bridge): Booted Linux and checked the
memory regions are not reserved. Couldn't test on Sandy Bridge, due to
lack of hardware.
Change-Id: I4273d1d804b490cf93c23426782eb1ffaf29f7d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12326
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
|
|
Most AMD hardware requires at minimum two warm resets
when booting from S5 (power off). This is uncomfortably
close to the maximum bootblock execution count, and has resulted
in unstable normal/fallback operation on some machines.
Increase the default max bootblock execution count before fallback
to 6. This translates to roughly 2 - 3 failed boots before fallback
mode will engage, with an absolute worst case of pushing the reset
button 5 times to engage fallback mode in the absence of a dedicated
recovery jumper.
Change-Id: I1911f1b77f168835b516e6a915d5b6949f47219a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12317
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a DMAR table to advertise IOMMU and IRQ remapping capabilities to
the OS.
Tested with kontron/ktqm77. Under Linux, the table is detected and
interrupt remapping is enabled automatically.
Change-Id: Id6ee601a0a8543ed09c6bb8d308a3a3549fc34e5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12195
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Sandy Bridge and Ivy Bridge processors have two IOMMU units. One for the
integrated graphics controller and one for all other PCI devices. Assign
resources for both IOMMUs and apply some quirks.
Tested with kontron/ktqm77 and a Muen based system that makes use of the
IOMMUs. Not tested on Sandy Bridge, but register dumps show the same
settings that are applied here.
Change-Id: I43b5e20b750e7529f448acac35de173185678fd9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12194
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add a parameter to acpi_create_dmar() for the flags field and define
flags given by the spec [1].
[1] Intel Virtualization Technology for Directed I/O
Architecture Specification
Document-Number: D51397
Change-Id: I03ae32f13bb0061bd3b9bef607db175d9b0bc5e1
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12191
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I0180e0ae2aeeffcef46a97892356f1955f581efd
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/12295
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
TEST: Booted ASUS KGPE-D16 with single Opteron 6380
* Unbuffered DDR3 DIMMs tested and working
* Suspend to RAM (S3) tested and working
Change-Id: Idffd2ce36ce183fbfa087e5ba69a9148f084b45e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11966
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I34501d3fc68b71db7781dad11d5b883868932a60
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11965
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Id7441dacef2e46e283d1fc99d5e5fa3f20e0d097
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11959
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I67a76cf0e4ebc33fbd7dd151bb68dce1fc6ba680
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11957
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This resolves a Kconfig warning.
Change-Id: Ic77c8bf89613c116dfdc73572709aeb354e33b2a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12287
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I8ab7b2cd9bf36d53b744a11d32dd40c750149567
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12272
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
All boards using it have been deleted a long time ago.
Change-Id: Ib1c4018ab6ec27868c0e2fdbf9c91323ead076fb
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12236
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I0f3297dff47dfb44da034ac6f305dcf1981b9de1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11080
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There are some inconsistencies in AMDs APIs between the coreboot
code and the vendorcode code. Unify the API.
UINTN maps to uintptr_t in UEFI land. Do the same
here. Also switch the other UEFI types to map to
fixed size types.
Change-Id: Ib46893c7cd5368eae43e9cda30eed7398867ac5b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I326c070398c72a877054969d3a03e6e427edc304
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11086
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ic97567851fa40295bc21cefd7537407b99d71709
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11952
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I169fafc3a61e11c3e4781190053e57bf34502d7b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11951
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This is extending http://review.coreboot.org/#/c/10583/
(29e6548) to the remaining AGESA northbridge drivers.
Change-Id: I6fa53b36a1420e92cb4aecb0f7b4c71541a94c71
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11021
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Issue observed:
In a multi GPU setup (IGD and PEG) the system still uses the IGD.
CONFIG_ONBOARD_VGA_IS_PRIMARY has no effect on Sandy/Ivy Bridge.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* ATI Radeon HD4780
Problem description:
The GMA is missing a disable function.
Problem solution:
Add a GMA disable function. Deactivate PCI device until remaining multi
GPU issues are resolved. Do not claim VGA decode any more.
Final testing results:
The system is able to boot using the PEG device as primary VGA
device.
Change-Id: I52af32df41ca22f808b119f3a4099849c74068b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11919
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I93534082d379369352e367c9c24b213513a543b2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12211
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I45eb03a4b351e458e8448245896743bd6fa57637
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11943
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The native AMD DDR3 memory initialization code was riddled with
numerous errors and was missing critical configuration code segments;
this made it so that DDR3 memory did not function on most AMD boards.
This patch corrects enough of the DDR3 initialization such that
UDIMMs can be used on most channels of G34 Opteron boards. Further
work is needed to fix the broken RDIMM code and remaining UDIMM issues.
Change-Id: Iab690db769e820600693ad1170085623b177b94e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11941
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
(this probably fixes relocate_sb_ht_chain() on tyan/s2885)
Change-Id: I5a26f4280b00bfb259c600048f6a7391a6c1268f
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10913
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
TEST: Booted ASUS KGPE-D16 and verified device functionality.
Change-Id: Ic6f5b3ca86eb55dc04291be0db67d06c34c6a6dc
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12188
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Change-Id: Iccd034f32c26513edd52ca3a11a30f61c362682d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11940
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
On Broadwell, this reduces the number of 'remarks' in the IASL build
from 222 to 3.
Fixes these remarks:
Object is not referenced (Name is within method [_CRS])
The ACPI compiler is trying to be helpful in letting us know
that we're not using various fields in the MCRS ResourceTemplate
when we define it inside of the _CRS method. Since we're not
intending to use those objects in the method, it shouldn't be an
issue, but the warning is annoying and can mask real issues.
Moving the creation of the MCRS object to outside of the CRS
method and referencing it from there solves this problem.
This change was made for fsp_baytrail in commit 2eaa0d49
fsp_baytrail: Fix ACPI 'Object is not referenced' warnings
Change-Id: I67a1faf963d1868f4133c7747a43a511cd28a44b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11268
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I3623f8945bd62b7050ec609934f96543552c792b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12018
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Change-Id: Ic27d404a7ed76b58043037e8b66097db6d664501
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11942
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I0a9b3a66231052622c862bae32b900f52f6efba9
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11944
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
|
|
Please don't remove chipsets and mainboards without discussion and input
from the owners. Someone was asking about cougar canyon 2 just a couple
of weeks ago - there's obviously still interest.
This reverts commit fb50124d22014742b6990a95df87a7a828e891b6.
Change-Id: Icd7dcea21fa4a7808b25bb8727020701aeebffc9
Signed-off-by: Martin Roth <martinroth@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/12128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763c16688d43752adbae2c76e7764da45.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Consolidate some common (and mostly broken) code. Will try to fix things
in separate commits.
Maybe, igd.asl taken from gm45 (the non-PCH case) could also be used for
i945 and sch. But this needs further investigation.
Change-Id: Id3663bf588458e1e71920b96a3149f96947921e9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11702
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Make sure edge write test results are sane.
Check rn.all to make sure rn.start and rn.end are valid.
Most likely the following test is going to fail on the same
rank anyway.
Change-Id: Ifa601406e6c74ceb8d70063be5ce1bf6bc512c18
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11247
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Don't disable PEG bits while turning on IGD.
Fixes PCI device enumeration of PEG devices.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Sidenote: This should be taken from a CMOS option instead.
Change-Id: I2d6522504e4404f2d57f9c319351d08317aefdcb
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11058
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Activate PEG clock-gating only if all PEG devices are disabled.
Fixes system hang when trying to access PEG registers.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Change-Id: I7d62fbb83c16741965639cea1a0e4978d4e3d6da
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11059
Tested-by: build bot (Jenkins)
|
|
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Building an image for the Lenovo X201 with native graphics
initialization selected fails due to the changes introduced by commit
a3b898aa (edid: Clean-up the edid struct).
Same as in 11738 / 11585 / 11491
Change-Id: I4233a4ce2f5423c7ebdad68e8059cd34ac61cfaa
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/11787
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
Building an image for the Lenovo X200 with native graphics
initialization selected fails due to the changes introduced
by commit a3b898aa (edid: Clean-up the edid struct).
Change-Id: Ifd36571c9c00761b4a2a6deb3c9c4a52d9d13e25
Signed-off-by: Audrey Pearson <apearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11738
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The thermal sensor interface exposed in function 3 of the northbridge is
a more convenient and faster way to access the processor-internal
thermal sensor than using the SMBus/SB-TSI interface from the FCH, see
the Family14 BKDG: "Tctl is a processor temperature control value used
for processor thermal management. Tctl is accessible through SB-TSI and
D18F3xA4[CurTmp]. Tctl is a temperature on its own scale aligned to the
processors cooling requirements"
Also on at least some of these boards the existing thermal zone is
broken and always returns 40C (the default value if the SMBus read
failed) because the SMBus muxing register (SmBus0Sel) is not set up
correctly.
Case in point: The fallback "smbus read failed" temperature is 40 C and
the the logs taken from the board status repository for the Asrock
E350M1 board all show: "ACPI: Thermal Zone [TZ00] (40 C)"
e.g.
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-5054-gf584218/2013-12-20T20:56:20Z/kernel_log.txt#l390
and
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-7030-g6d7de4f/2014-10-16T15:34:19Z/kernel_console.txt#l404
and
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-9989-gf2dfef0/2015-06-13T00:22:49Z/kernel_log.txt#l425
Example lm-sensors output with this patch on the pcengines APU1, on
Linux 4.1.0-rc8+ (wiht both CONFIG_ACPI_THERMAL and
CONFIG_SENSORS_K10TEMP enabled):
acpitz-virtual-0
Adapter: Virtual device
temp1: +54.0 C (crit = +100.0 C)
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +54.0 C (high = +70.0 C)
(crit = +100.0 C, hyst = +97.0 C)
Change-Id: Id9c5b783ba424246816677099ec6651814e59f21
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/10940
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
While the romstage code flow is not consistent across all
mainboards/chipsets there is only one way of running ramstage
from romstage -- run_ramstage(). Move the
timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. TS_END_ROMSTAGE still present in
timestamp table.
Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit 300caced9 introduced stack overflow when HAVE_ACPI_RESUME
is selected as the temporary storage for MTRRs is 4KiB.
Change-Id: I993df6abc04436fb135822729c4931c5c7496e5a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/11633
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The build system was previously determining the flow
and linking scripts bootblock code by the order of files
added to the bootblock_inc bootblock-y variables.Those
files were then concatenated together and built by a myriad of
make rules.
Now bootblock.S and bootblock.ld is added so that bootblock
can be built and linked using the default build rules.
CHIPSET_BOOTBLOCK_INCLUDE is introduced in order to allow the
chipset code to place include files in the path of the bootblock
program -- a replacement for the chipset_bootblock_inc
make variable.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards.
Change-Id: Ida4571cbe6eed65e77ade98b8d9ad056353c53f9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11495
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We don't build-test with native VGA init, so if the code is broken by
a commit, we won't see it when it's guarded by #ifdefs. This has
already happened in the past. Instead of gurading entire files, use
the IS_ENABLED() macro, and return early. This at least enables us to
build-test the code to some extent, while linker garbage collection
will removed unused parts.
BONUS: Indenting some blocks also makes the difference between
framebuffer init and textmode init clearer.
Change-Id: I334cdee214872f967ae090170d61a0e4951c6b35
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11586
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ib7ca49ffd53b0ae98a592b9fe8949dee2d9ae100
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11587
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Native VGA init no longer compiles from commit:
* 7dbf9c6 edid: Use edid_mode struct to reduce redundancy
Tested on a single X60 machine.
This patch basically copies 11491 which does
the same for north/intel/sandybridge.
Change-Id: I0663f3b423624c67c2388a9cc44ec41f370f4a17
Signed-off-by: Axel Holewa <mono-for-coreboot@donderklumpen.de>
Reviewed-on: http://review.coreboot.org/11585
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Native VGA init no longer compiles from commit:
* 7dbf9c6 edid: Use edid_mode struct to reduce redundancy
Change-Id: I51a4f4874ce77178cab96651eb7caf2edd862aa2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The reason for hardcoding the position of the MRC cache was to satisfy
the alignment to the erase size of the flash chip. Hardcoding is no
longer needed, as we can specify alignment directly. In the long term,
the MRC cache will have to move to FMAP, but for now, we reduce
fragmentation in CBFS.
Note that soc/intel/common hardcoding of mrc.cache is not removed, as
the mrc cache implementation there does not use CBFS to find the cache
region, and needs a hardcoded address.
Change-Id: I5b9fc1ba58bb484c7b5f687368172d9ebe625bfd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11527
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The BOOT_STATE_INIT_ENTRY macro can only be used in ramstage, however
the current state of the header meant bad build errors in non-ramstage.
Therefore, people had to #ifdef in the source. Remove that requirement.
Change-Id: I8755fc68bbaca6b72fbe8b4db4bcc1ccb35622bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11492
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In the gm45 code, IOMMU is always selected to be enabled. Instead
this patch removes the Kconfig symbol and its dependencies. This leads
to the same effect without the need for the symbol.
The symbol is still used in the K8 code as it's not selected, simply
defaulted to being enabled, and one of the mainboards disables it.
Change-Id: Ibc5939cd1e297d497bf71b1787d852f7cc09a551
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11345
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Idf28faa26a7ea5e94495af5ff027309df444766e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11376
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
After much consideration, and many years of an EXPERT mode sitting
almost completely unused, we've seen that it doesn't work for us.
There is no standard on what constitutes EXPERT, and most of
coreboot's options Kconfig are expert-level.
We even joked that not selecting "EXPERT" should prevent coreboot
from compiling:
@echo $(shell whoami) is not permitted to compile coreboot
Change-Id: Ic22dd54a48190b81d711625efb6b9f3078f41778
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11365
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Kconfig symbol CACHE_MRC_BIN was getting forced enabled everywhere
it existed.
Remove the Kconfig symbol and get rid of the #if statements
surrounding the code.
This fixes the Kconfig warning for Haswell & Broadwell chips:
warning: (NORTHBRIDGE_INTEL_HASWELL &&
NORTHBRIDGE_INTEL_SANDYBRIDGE &&
NORTHBRIDGE_INTEL_SANDYBRIDGE_NATIVE &&
NORTHBRIDGE_INTEL_IVYBRIDGE &&
NORTHBRIDGE_INTEL_IVYBRIDGE_NATIVE &&
CPU_SPECIFIC_OPTIONS) selects CACHE_MRC_BIN
which has unmet direct dependencies
(CPU_INTEL_SOCKET_RPGA988B || CPU_INTEL_SOCKET_RPGA989)
Change-Id: Ie0f0726e3d6f217e2cb3be73034405081ce0735a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit 27baa32 (cpu/amd/model_10xxx: Do not initialize SMM memory if
SMM is disabled) deactivated TSeg SMRAM, which had the side effect
of routing legacy VGA memory access to DRAM. Restore the correct
MMIO mapping via the MMIO configuration registers.
TEST: Booted KGPE-D16 with nVidia 7300LE card and verified proper VGA
functionality.
Change-Id: Ie4b7c0b2d6f9a02af9a022565fe514119513190a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11240
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The sysinfo object within the k8 ram init is used
to communicate progess/status from all the nodes in the
system. However, the code was assuming where the sysinfo
object lived in cache-as-ram. The layout of cache-as-ram
is dynamic so one needs to do the lookup of the correct
address at runtime. The way the amd code is compiled
by #include'ing .c files makes the solution a little
more complex in that some cache-as-ram support code
needed to be refactored.
Change-Id: I6500fa7b005dc082c4c0b3382ee2c3a138d9ac31
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10961
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I7f17cd1418f05ff3e8cd559eca6ec3ce7f9bfb79
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Related-to: I3175c8b29e94a27a2db6b11f8fc9e1d91bde11f9
(ACPI: Fix corrupt SSDT table on multiprocessor AMD Family 10h systems)
Change-Id: I0b5f265278d90cbaeddc6fc4432933856050f784
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10912
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Compiler complained about potentially uninitialized variable.
Fixes google/bolt, google/falco, google/panther, google/slippy
BRANCH=none
BUG=chromium:513990
TEST=the mentioned boards build with CONFIG_CHROMEOS=y
Change-Id: Ia28c833bd6ef8e1f7c820a61b41ce456eba51246
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 4566c355cc6828ab96e8d52bfad6ccbf6be6f7ce
Original-Change-Id: I4d9a685373362f8a092b325efee3f816c056c708
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/288850
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/11061
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Found while doing code review.
Simplify the code by using a loop for positive and negative phase
adjustments.
Change-Id: I0980443d0d2815bccef969709fddecc07d61a788
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10890
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Issue observed:
Two memory DIMMs are placed in the same channel, but only one shows up.
The SPD is read and printed, but the first DIMM isn't recognized any more.
Due to an existing but unconfigured memory DIMM the timB test failed.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMMs:
* crucial 2GB 256Mx64 CT2566aBA160BJ
* corsair 8GB CMZ16GX3M2A1866C9
Problem description:
The channel's rankmap was overwritten by the second slot's rankmap.
Problem solution:
Logical OR the channel's rankmap with every slot's rankmap.
Final testing result:
The DIMM is recognized and can be properly configured and used.
The timB test doesn't fail any more.
Change-Id: I17a205ff4d344c13d9ddfe71aaae2f3cef047665
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10960
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Change-Id: I694b739a29e9d82d153d9fb3b729dc250bd4901e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10583
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This is breaking the build right now. Reapply once the correct headers are in place.
This reverts commit 406effd59075cab212c5bf9c1a12759c8fad50a4.
Change-Id: I34b8717820ed58b462d4e7793711ee98fb8b882f
Reviewed-on: http://review.coreboot.org/11020
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
