Change-Id: I3df66320d0bc18221f947b47e7f09533daafabad
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11108
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
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>
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>
This mirrors a similar commit made to Family 10h support
in changeset 11966 file model_10xxx_init.c
TEST: Booted ASS KFSN4-DRE with 1x Opteron 8222
Change-Id: I760ef27be00aed11c0ac21b9bd741189f4b05834
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12250
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The existing Kconfig option for FIDVID was permanently
set to "no" due to Kconfig stopping at the first matching
value set when parsing the file. This patch moves the
conditional set above the unconditional set, resolving
the issue.
Change-Id: Ic19f68f6b17943f9133ff32a9b6538f0bf942eca
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12224
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Backport a handful of debugging routines and the extended APIC
initialization code from Family 10h support to K8 support.
Change-Id: I08cc5c8bc65635ce09a69e32940dd7edd8d3be87
TEST: Booted ASUS KFSN4-DRE with 1x Opteron 8222
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The recommendation to set DisFillP during CAR initialization
on K8 NPT CPUs was ignored. The consequences of this are
largely unknown; fix up coreboot to follow the recommendations.
Change-Id: Ide512bbc1d9aa284179628e2aa598ef5475e8eeb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12249
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These two mainboards contained trivial mistakes related
to FIDVID that broke build when FIDVID was enabled.
Change-Id: Ie7bec77f26ec37eada21308984db4a9fd7a1866f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12226
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is a clone of the original Family 10h-compatible ASUS
KFSN4-DRE board, modified for basic K8 support to allow for
future K8 Socket F Opteron testing.
TEST: Booted KFSN4-DRE with 1 Opteron 8222 processor
KNOWN ISSUES:
* Second CPU package fails to initialize AP
This prevents use of a secondary CPU package
* Second memory channel of at least CPU package #0
does not function (crash at CAR handoff)
Change-Id: I591725babe685fa50a0d7473b17005fbd258056e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12212
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 785b3eb6e8fcafb38395eec00f4f0fc0e906c7cc.
The commit re-tuned the upstream link again, it does not tune secondary side.
Change-Id: I9be70e95b06ceff99beba8a7c7eb6402b32fcca1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/12253
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Previously if we tried to read the HDMI EDID several times and failed
each time then we're return from hdmi_read_edid() with no error. Then
we'd interpret whatever happened to be in memory at the time as an
EDID--not so great.
Let's actually look at the error.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Monitor that can't read EDID not shows that in the log
Change-Id: I6e64b13ae3f8c61bf1baaa1cfc8b24987bd75cf3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 44bda7311f9ee677235e4dc8db669226518b3895
Original-Change-Id: I9089755b75118499bec37bdb96d1635f66252e65
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309298
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12231
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are cases where one region_device needs to be
accessed using offset/sizes from one address space
that need the offset translated into a different
address space for operations to take place. The
xlate_region_device provides an offset that is
subtracted from the incoming transaction before
deferring to the backing access region.
Change-Id: I41d43924bb6fbc7b4d3681877543209e1085e15c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12227
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@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>
Add a comment explaining what `abcfg_reg(0xc0, 0x01FF, 0x0F4)` does.
This is a follow-up for commit 24501cae (AMD cimx/sb800: Initially
enable all GPP ports).
Change-Id: I5ac263ee088d36a7f7a2d03c1454ed647faa7147
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/12190
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This mitigates the Memory Sinkhole issue (described on
https://github.com/xoreaxeaxeax/sinkhole) by checking for the issue and
crashing the system explicitly if LAPIC overlaps ASEG.
This needs to happen without a data access (only code fetches) because
data accesses could be tampered with.
Don't try to recover because, if somebody tried to do shenanigans like
these, we have to expect more.
Sandybridge is safe because it does the same test in hardware, and
crashes. Newer chipsets presumably do the same.
This needs to be extended to deal with overlapping TSEG as well.
Change-Id: I508c0b10ab88779da81d18a94b08dcfeca6f5a6f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11519
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
While migrating from vboot1 to vboot2, the tpm_init was moved out of
vboot library and implemented in coreboot. However, while doing this,
the initial factory flow was missed.
We need to ensure following flow for tpm_init:
1. Perform tpm_init
2. If tpm_init fails, set secdata_context flag to indicate to vboot
that tpm needs reboot.
3. Call vb2_api_phase1
4. If vb2_api_phase1 returns error code saying boot into recovery,
continue booting into recovery. For all other error codes, save
context if required and reboot.
[pg: everything but step 2 was already done, so this upstream commit is
quite minimal]
CQ-DEPEND=CL:300572
BUG=chrome-os-partner:45462
BRANCH=None
TEST=Verified behavior on smaug. Steps to test:
1. Reboot into recovery
2. tpmc clear
3. Reboot device
Expected Behavior: Device should reboot after Enabling TPM. Should not
enter recovery
Confirmed that the device behaves as expected.
Change-Id: I72f08d583b744bd77accadd06958c61ade298dfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85ac93137f3cfb28668dcfa18dfc773bf910d44e
Original-Change-Id: I38ab9b9d6c2a718ccc8641377508ffc93fef2ba1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/300570
Original-Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12205
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change the tuning setting for the type-c port that is over
the flex cable to use the max possible drive strength.
Also fix up the comments to indicate what Type-c port goes
where instead of just referring to them by number.
BUG=chrome-os-partner:45367
BRANCH=none
TEST=build and boot on glados
Change-Id: Iebcffc9ab95d56289258017248c273090c88bb06
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 824ca87c4bf556d493dc8cdec561f37ab135cd2d
Original-Change-Id: I081623bbb1b0f39f1569b9f5cf7933abefe202b3
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309010
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12204
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a new USB2_PORT_MAX with the max possible settings
(56mV) for the TX and Pre-emphasis bias values. Also fix
the settings for the detachable tablet config to match the
skylake HSIO tuning guide as it was incorrect before.
BUG=chrome-os-partner:45367
BRANCH=none
TEST=build and boot on glados
Change-Id: Id9ccc683fe92c962095347e0d1a0afeb082c821f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e5d56831e75f98a3c75ed333e4b79b1a37f14792
Original-Change-Id: Ia2e3e93236f1463201f83a1cae28349de2836110
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/308729
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12203
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If we boot without a heatsink then DPTF may power off the system when
it starts if the CPU temp is >90C. Since TJmax is 100C set the
critical threshold to just below that value.
Also remove the active thresholds as chell does not have a fan.
This will have DPTF use the default values but without the DPTF active
policy it shouldn't get used.
BUG=chrome-os-partner:46694
BRANCH=none
TEST=build and boot on chell w/o a heatsink
Change-Id: Id9e8f2c547468db8ad0edaf6c362a9a9bb5b95a2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 23d9117d5d7a4b44fc2298352eba133747f8e246
Original-Change-Id: Ib8e074098e3956efeed0f9b7f8b16652658db374
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/308728
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12202
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is based on kunimitsu with minor changes:
- update GPIOs based on schematic
- update SPD data for memory config
- disable ALS
BUG=None
TEST=emerge-lars coreboot
Change-Id: Id1c9edfe3cc665e90683344f1662de2e65caf766
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3201aa573a77fcad3b6b1335d23eb4c2a09c1708
Original-Change-Id: Ifae446e4668569b6100b29bc1f52b0fea1df2952
Original-Signed-off-by: David Wu <David_Wu@quantatw.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/308283
Original-Commit-Ready: David Wu <david_wu@quantatw.com>
Original-Tested-by: David Wu <david_wu@quantatw.com>
Original-Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/12201
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I69a50c71d93ab311c1f7d4cfcd7d454ca1189586
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d9679b02f6d21ed903bb02e107badb0fbf7da46c
Original-Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/307946
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/12199
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Intel's FSP 1.0 platforms are moving back to loading microcode in
coreboot instead of in the FSP. Update the Ivy Bridge chips to
be compatible.
Change-Id: I4af155dea51e89ab9595b922c95ceade29a2dc52
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12196
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This aids the fuzzer test case.
Change-Id: Ic7d43b76cf5660e085e7b3b13499de0358c13197
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/12181
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
As of this commit S3 suspend does not work on any K10 boards,
including this board.
Change-Id: Idd3971422fb2473bff7c60fe8d8161d6e20808ed
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11946
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Output how long it took to scan a bus.
Note, that the function `scan_bus()` is called recursively.
Change-Id: I6335e10db783f092ea18d3a1c79f93135bee5826
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/12103
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some platforms do not have `timer_monotonic_get()` implemented. So only
call `timer_monotonic_get()` if `CONFIG_HAVE_MONOTONIC_TIMER` is
selected and set the times to 0 otherwise.
Change-Id: If9cba4c0c17a7011aa357079d8fdd0aa47ad1b66
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/12105
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
