On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?
Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?
Yes, I know it's Intel syntax. Will be converted to AT&T syntax
as soon as the whole thing actually works.. 8)
Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11106
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>
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>
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>
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>
