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>
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>
Instead of having many different arrays for USB configuration,
with each array containing one bit of information, have one
array containing all the information for each port.
This way we can put the basic tuning parameters into a
structure and then define structures for the basic supported
configurations.
The existing port definitions are taken from the Skylake HSIO
tuning guide.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados, verify USB functionality in
all ports.
Change-Id: I5873dee011ae9e250b6654c73a7bd5c17681095b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 864040412b2d2923d3acbfca8055724887c58506
Original-Change-Id: Id518b1086abbe4a8c25d77fd4efc2d0de856bd5f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/306734
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12163
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add default properties for NAU8825 codec
Change jack detecion irq to level to match the
codec driver
BUG=chrome-os-partner:44481
BRANCH=None
TEST=Build and Boot Kunimitsu board with this patch
Verify Audio jack detection IRQ working
Change-Id: Iaab7a7bfbab30fa0914e56477f7c6a93717b4518
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 58c45538ea6a85724f9ab1837e5cf0971611a1f8
Original-Change-Id: I11466b8fd64b768e1e826639ba37bd6e00810370
Original-Signed-off-by: Yong Zhi <yong.zhi@intel.com>
Original-Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303760
Original-Commit-Ready: Yang Fang <yang.a.fang@intel.com>
Original-Tested-by: Yang Fang <yang.a.fang@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/12162
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For SMT controllers to power gate, all SMT/SMS clock, data and alert signals should be inactive.
The SML0 blocks are not used for any functional purposes and are not configured in the GPIO tables.
SMT hardware will not allow the blocks to be power gated in this scenario. The SML* pins are
now configured as GPIOs - input and deep.
With this change, the SMT blocks are properly power gating.
BRANCH=none
BUG=chrome-os-partner:45618
TEST=build for Kunimitsu, boot on FAB3.
Change-Id: I16b31a8d5c3c9df0f37df15c751c5a0978ac0feb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d2913a75969008583f454a4bfc9da2156266548b
Original-Change-Id: I00dca84a3f6ba7bda4ca1c206b49ff81482279a5
Original-Signed-off-by: Archana Patni <archana.patni@intel.com>
Original-Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306391
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12161
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For SMT controllers to power gate, all SMT/SMS clock, data and alert signals should be inactive.
The SML0 blocks are not used for any functional purposes and are not configured in the GPIO tables.
SMT hardware will not allow the blocks to be power gated in this scenario. The SML* pins are
now configured as GPIOs - input and deep.
With this change, the SMT blocks are properly power gating.
BRANCH=none
BUG=chrome-os-partner:45618
TEST=build for Glados.
Change-Id: Ie5406f2a1e0c485ac1290e2154755085fa3bb7b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5b3fe3c2ddea4c5daedb04078b24cff14efa49d5
Original-Change-Id: I8dcc0bfc121e612a174e6fe3152650d0fcd68f39
Original-Signed-off-by: Archana Patni <archana.patni@intel.com>
Original-Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306481
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12160
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rename soc_display_upd_value to fsp_display_upd_value since the routine
was moved from src/soc/intel/common into src/drivers/intel/fsp1_1.
BRANCH=none
BUG=None
TEST=Build and run on Kunimitsu
Change-Id: Ifadf9dcdf8c81f8de961e074226c349fb9634792
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 95238782702999a178989467694ac1f15c079615
Original-Change-Id: Ibd26ea41bd5c7a54ecd3c237f7fb7bad6dbf7d8a
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306351
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12157
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Move the FSP common code from the src/soc/intel/common directory into
the src/drivers/intel/fsp1_1 directory. Rename the Kconfig values
associated with this common code.
BRANCH=none
BUG=None
TEST=Build and run on kunimitsu
Change-Id: If1ca613b5010424c797e047c2258760ac3724a5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e8228cb2a12df1cc06646071fafe10e50bf01440
Original-Change-Id: I4ea84ea4e3e96ae0cfdbbaeb1316caee83359293
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306350
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12156
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
In the program loading paths using vboot it's possible that
the boot media has not been initiazed for that stage. Therefore,
provide this call such that it's guaranteed to be called at least
once.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I3a0ef4d9eebbf5f15780316cc76b469e8ac3f358
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ee0c5bb36d17fd80ba34762e7547359fd8971ce
Original-Change-Id: If8dfeedbe1243ec482764e05c8d3f333c18aedd2
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/305540
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12154
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is based on glados with minor changes:
- updated GPIOs based on schematic
- add _PRW for trackpad wake now that it is on a new GPIO
- add SPD for new memory config
- disable ALS
BUG=chrome-os-partner:46289
BRANCH=none
TEST=emerge-chell coreboot
Change-Id: Id5746bf2b5b26000fcc3f029b901bfe29b788dac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c5ebe98cf599ba80aac5e9ef238b7996789a819
Original-Change-Id: I75efda64a50b0e6e4a5c9008ce05d76c1e605b0c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/304927
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
