| Age | Commit message (Collapse) | Author |
|---|
|
Certain AMD platforms, such as those using the SP5100 southbridge,
contain a very poorly documented bug related to LPC ROM access,
which is triggered by repeated (hundreds or more) rapid calls to
get_option(). This bug manifests as a complete system deadlock
in ramstage device configuration, requiring standby power to be
removed from the system to release the deadlock.
Cache the platform ECC status to avoid repeated calls to get_option()
in the lane count detection logic.
Change-Id: I8b48c523218ccc8c113319957d6eca2d15e1070f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14273
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I08d3ba8b64459b1f84a5f1318e37c31010d7ae0f
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/14251
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This adds boot mode constants. They match EDK2 found in PiBootMode.h
constants but are part of FSP2.0 spec.
Change-Id: I16ee90ff372d252ddc042ca89c1e5912ab041616
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14249
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Include SOC specific FADT tables to current mainboard.
Change-Id: Id4099528657304e9f7675c839e7666c58f189004
Signed-off-by: Lance Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/13353
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
This reverts commit 272a1f05b943d781acb8c04c01874bde9df3b774.
In Chrome OS this command's usage was dropped in favor of another
solution. As it's not used drop the support for it.
Change-Id: I58b51446d3a8b5fed7fc391025225fbe38ffc007
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14261
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Upcoming designs are based on similar SOCs, this patch moves code
which can be reused into a common directory under soc/rockchip.
Changing spi.h to include stdder.h, as this is were check_member() is
defined, this becomes necessary later when the new SOC code is added.
Renaming UART driver private functions not to be bound to any
particular SOC.
BUG=none
BRANCH=none
TEST=the refactored code works fine on the new platform (with the rest
of the patches applied).
Change-Id: I39a505aecda8849daa58a8eca0e44a5243664423
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f63f2582042ac115481207ddf329ea2e3260e55e
Original-Change-Id: I3a1139305354d460492b25a45f3da315a9a0b49e
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/335408
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14235
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Our EDID code had always been aligning the framebuffer's
bytes_per_line (and x_resolution dependent on that) to 64. It turns out
that this is a controller-dependent parameter that seems to only really
be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper
function to calculate bits-per-pixel dependent values) probably actually
broke this for some other controllers by applying the alignment too
widely.
This patch makes it explicitly configurable and depends the default on
ARCH_X86 (which seems to be the simplest and least intrusive way to make
it fit most cases for now... boards where this doesn't apply can still
override it manually by calling edid_set_framebuffer_bits_per_pixel()
again).
Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14267
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The logic to enable reset on sync flood per RPR guidelines
somehow ended up guarded on the SATA AHCI setup. Unconditionally
enable reset on sync flood per the RPR.
Change-Id: I62d897010a8120aa14b4cb8d096bc4f2edc5f248
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14260
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Otherwise, on OS X, some architectures will fail
to build libgcc (verified for ARM toolchain).
Change-Id: I8b58e0582596ad39cad92e9d478158c46a96a26e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14256
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Most cross compilers fail to compile on systems with Clang being the
default compiler (OS X and some BSDs). Clang dislikes some of GCC's
autogenerated code. We also missed switching CFLAGS to CXXFLAGS when GCC
switched to C++ compilation per default.
Change-Id: I87caa1a15982c431048aa79748ea7ef655a9a3a1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14232
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Since r is a pointer, memset(r, 0, sizeof(r)) would only zero the first
4 (or 8) bytes of the newly allocated struct align_region_t.
An alternative to this patch would be to use calloc, or introduce a new
zalloc (zeroed allocation; a single-element calloc) and use that.
Change-Id: Ic3e3487ce749eeebf6c4836e62b8a305ad766e7e
Found-by: Coverity (ID 1291160)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14244
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
power_on_after_fail=Enable in cmos.default leads to wake on AC behaviour
on mobile systems. Therefore set cmos.default entry to "Disable" in order
to improve user experience.
Change-Id: I977a4e6bc028c8c4c7fc1c2f5fdd74a59e951c60
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/13884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
Fill the ACPI FADT table base on apollolake SOC definition.
Change-Id: Ib7226a3b130f14810dc2af5ca484cef58f477063
Signed-off-by: Lance Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/13352
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In error case die in top level function.
No functionality is changed.
Change-Id: Ie15b01184d40bdbce20d49dcab2f9fb607068c7a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14171
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Return errors to top level ram init function.
Required by the folowing series to implement a fallback.
No functionality is changed.
On error case the system still halts in every test.
Change-Id: I6278c4a1d7b4a96be8988a60671fc3d72cd6cb3d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14170
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I76a1047742369416b90e5c8bf307f85c02ae9bbb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14242
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
SP5100 devices are affected by an erratum that can lock up the
EHCI ports under certain conditions. Add an optional CMOS
option to enable a workaround at the expense of performance.
Change-Id: I305d23dfa50f10a3dcb5c731e8923305c8956dde
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14241
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change the existing chromeos.fmd files and the dts-to-fmd script to mark
RW_LEGACY as CBFS, so it's properly "formatted".
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I76de26032ea8da0c7755a76a01e7bea9cfaebe23
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 717a00c459906fa87f61314ea4541c31b50539f4
Original-Change-Id: I4b037b60d10be3da824c6baecabfd244eec2cdac
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336403
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14240
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The codepath was untested and incomplete. It now determines the right
GBB region sizes and puts the data in.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I2cc47ddd8aa7675375ca5ed5f75632c30c65dd1e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36e026404ed049d61b677ef043a781c8c209dd93
Original-Change-Id: Ib872627740dbd8ac19fc3e2a01464457f38366ed
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336358
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14239
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This mirrors vboot's flag table.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I4473eb6c0e073f555e6a692a447e8cc85f8e4eeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0fc50a6cff5ba900e6407d58a8f18db63b5946a5
Original-Change-Id: Ieabd3f9391ba256557e18386f334558d64a81694
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336630
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14238
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
cros_sdk puts weird stuff into CFLAGS and LDFLAGS and we never care
because we don't use CFLAGS. futility's Makefiles do.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I512d5adb55cad8b31dc29d9c076ecd5d9c701cf6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 58739332ddba7ef759aac37f3a4410dd487f210f
Original-Change-Id: I66898c7e66d808047b0326c7471c64eaae950b15
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336436
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14237
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
BUG=none
BRANCH=none
TEST=emerge-oak coreboot
Change-Id: Ia5f2bc9b021b9051f2e5035c5d295b6b9eea1301
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7304016041d42a5317448fc2f9c58c6e6715fc25
Original-Change-Id: I7bcd1cf8dabbe190fcbc62cbf6b3a34430a97b21
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336592
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14236
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The MT8173 hardware watchdog can assert an external signal which we use
to reset the TPM on Oak. Therefore we do not need to do the same
double-reset dance as on other Chromebooks to ensure that we reset in a
correct state.
Still, we have a situation where we need to reconfigure the watchdog
early in the bootblock in a way that will clear information about the
previous reboot from the status register, and we need that information
later in ramstage to log the right event. Let's reuse the same watchdog
tombstone mechanism from other boards, except that we don't perform a
second reset and the tombstone is simply used to communicate between
bootblock and ramstage within the same boot.
BRANCH=None
BUG=None
TEST=Run 'mem w 0x10007004 0x8' on Oak, observe how it reboots and how
'mosys eventlog list' shows a hardware watchdog reboot event afterwards.
Change-Id: I1ade018eba652af91814fdaec233b9920f2df01f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 07af37e11499e86e730f7581862e8f0d67a04218
Original-Change-Id: I0b9c6b83b20d6e1362d650ac2ee49fff45b29767
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/334449
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14234
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This allows to accommodate different platforms' default
configurations, memory configuration is fine tuned later during boot
process.
BUG=chrome-os-partner:51537
BRANCH=none
TEST=none yet, the full stack of patches boots fine on EVB
Change-Id: I39da4ce247422f67451711ac0ed5a5e1119ed836
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 97a9a71ade4df8a501043f9ae58463a3135e2a4f
Original-Change-Id: I39da4ce247422f67451711ac0ed5a5e1119ed836
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/332384
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/13914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Changing these thresholds again for new tuning in March of 2016.
Something's changed in the latest firmware to cause all
values previously read on Chell to float down.
Set "nuvoton,sar-threshold" property to thresholds
based on tuning with the Android Wired Headphone
Compatibility Kit and Chell DVT.
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:49333
BRANCH=none
TEST=Run evtest, selecting the input event for sklnau8825adi
Using the Nominal headphones from the kit, check that the
buttons for "KEY_VOLUMEDOWN", "KEY_VOLUMEUP", "KEY_MEDIA",
and code 582 (?) (should be voice search, but evtest doesn't understand)
All of these buttons should work properly.
Change-Id: Ie5ff1d35599d2cca5ce76467ecd7ec3ecab42d8b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1d13e967addb5cd31e6196e32541cda97ae00257
Original-Change-Id: I11de7a0853a3598f3834e8bae3140b9942cbd0b0
Original-Reviewed-on: https://chromium-review.googlesource.com/334402
Original-Commit-Ready: Benson Leung <bleung@chromium.org>
Original-Tested-by: Benson Leung <bleung@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14233
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A long time ago many Chrome OS boards had pages full of duplicated
boilerplate code for the fill_lb_gpios() function, and we spent a lot of
time bikeshedding a proper solution that passes a table of lb_gpio
structs which can be concisely written with a static struct initializer
in http://crosreview.com/234648. Unfortunately we never really finished
that patch and in the mean time a different solution using the
fill_lb_gpio() helper got standardized onto most boards.
Still, that solution is not quite as clean and concise as the one we had
already designed, and it also wasn't applied consistently to all recent
boards (causing more boards with bad code to get added afterwards). This
patch switches all boards newer than Link to the better solution and
also adds some nicer debug output for the GPIOs while I'm there.
If more boards need to be converted from fill_lb_gpio() to this model
later (e.g. from a branch), it's quite easy to do with:
s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/
Based on a patch by Furquan Shaikh <furquan@google.com>.
BUG=None
BRANCH=None
TEST=Booted on Oak. Ran abuild -x.
Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14226
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Northbridge resource assignment:
Dynamicly update memory resources for northbridge devices, exclude any
fixed MMIO resources.
Change-Id: I9595f9a12434fa423862836d19f7266d6023fc5a
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/13371
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ia1e8f7c11708208638f83dc1058f1754e69d4d0c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14020
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I99c3b4dd0c4da41b99bc108977079c8069afc0bd
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14019
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I7afb35fd5bc971a2c4d63e3a084ce7473f7a66fa
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14018
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The official spelling of Nuvoton is not all uppercase. Only the first
letter is uppercase. See the footer of the Nuvoton Web site.
Change-Id: I6ccd4194d7be0c89f8b332fcca5feb2420a4de1e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/5928
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Instead of using arch_segment_loaded() implement
platform_segment_loaded() so as not to tangle the notion of
arch and the chipset. Lastly, add a TODO to allow filtering
of the L1D to L2 flush depending on the region loaded.
Change-Id: I52e7cd2ae6e2d95f21bdd2fe1a471a10565309cb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14215
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
In order to not muddle arch vs chipset implementations provide
a generic prog_segment_loaded() which calls platform_segment_loaded()
and arch_segment_loaded() in that order. This allows the arch variants
to live in src/arch while the chipset/platform code can implement
their own.
Change-Id: I17b6497219ec904d92bd286f18c9ec96b2b7af25
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14214
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
While rmodule_load() calls arch_segment_loaded() when it's done
loading any pieces of code which further modify it, like changing
parameters within the program itself, need to notify the rest of
the system.
Change-Id: Ia3374b58488120ba6279592a77d7f9c6217f1215
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14213
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Instead of using platform_prog_run() for flushing programs
from L1D to L2 for code coherency purposes use arch_segment_loaded()
instead as that it's primary purpose. The arch_segment_loaded()
is called within the infrastructure at the appropriate places when
loading programs. Therefore use that to perform the L1D flush
instead of when something is just about to run.
Change-Id: Ib0a6be6f676dcf2c946ef5702471af65d89133e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
In order for the platform code to handle situations where
special actions are required after a piece of code is loaded
use arch_segment_loaded() to signal to the platform code
that the component is fully loaded into memory.
Change-Id: I119cfc9913f15eb4968fe5bf6a56589e2c53f2d1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14211
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
The flush L1D to L2 operation was only being used when loading
romstage from bootblock. However, when the FSP-M component is
loaded no code coherency actions are taken. I suspect this is
because the FSP-M component is larger than the 24KiB L1D and
the entry point is early in the image. Thus, when loading
the FSP-M component the earlier part of the image is flushed
out to L2 in the process of loading the latter part of the
component. Also, once verstage is introduced the same
code coherency actions need to be taken as well. Therefore,
position the apollolake code to handle all these cases.
Change-Id: Ie71764f1b420a6072c4f149ad3e37278b6cb70e1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14210
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
The revision mask for all DR-* series processors was incorrectly
set to only include the DR-B revision mask. Include all DR-*
series prcessors in the DR_ALL revision mask.
Change-Id: Iceda96aa6267b24abcbf78d39f4848d2be8053b8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Found-by: Coverity, CID 1229627 (#1 of 1): Logically dead code (DEADCODE)
Reviewed-on: https://review.coreboot.org/14216
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
mmio_resource() takes memory address in kilobytes. This patch
adds resources properly.
Change-Id: Id78dcecf05ad5b2c84e5bb5445ae3a4e4ec9d419
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14203
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The log shows the following error on systems that use the
native gfx init. The error isn't shown using the VBIOS blob:
GET_VBIOS: aa55 8086 0 3 0
VBIOS not found.
Don't shift the class-code, as it's already shifted by the PCI layer.
Tested-on: x220
Tested-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I69018940dd51966b45774e0576a1380f90716dce
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14188
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
The typo is not present anymore in Family 16h (Kabini), so fix it for
the older families (Family 10h, 12h, 14h, 15h, 15h Trinity) too using
the command below.
$ git grep -l ' ne ' src/vendorcode/amd/agesa | xargs sed -i 's/ ne / be /g'
Change-Id: I9cb419251eeec79925f48a5832fac339d40f01d1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/5543
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Enabling sync flood on DRAM MCE directly after ECC clear can
lead to a system hang with no way to determine the offending
DRAM module. Clear MCEs after ECC setup, but do not enable
sync flood until NB setup in ramstage to allow time for any
MCEs to accumulate in the status registers. Before enabling
sync flood on MCE, determine if any MCEs were logged during
ramstage execution and display them on the serial console.
Also clear the DRAM ECC sync flood bits during DRAM training
and initial ramstage execution.
Change-Id: Ibd93801be2eed06d89c8d306c14aef5558dd5a15
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14192
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The lint-stable-004-style-labels check tries to verify that labels in c
and asm files start at the first column, and don't have whitespace in
front of them.
This fixes the 2 actual violations of the lint check.
Change-Id: Ia11a90d7301e62a116c7a9ef9b4c2bc3f982b308
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14193
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
|
|
During power on from cold (S5) state, numerous MCEs are generated
before DRAM training starts, e.g. during HT link training. Clear
these MCEs before DRAM training start, and report any MCEs generated
during DRAM training.
Change-Id: I7d047571242e5bd041e4aac22c1ec1d7d26ef0e6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14191
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
On Family 15h processors, with certain RDIMMs, MCEs are generated
as a normal part of DCT startup / DRAM training. Disable sync
flood on parity or UC data error until ECC has been enabled.
Change-Id: Ife54751ff127ffd59baaad35d3fea14ea01ef505
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14186
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Datasheet: http://www.fintek.com.tw/files/productfiles/F81865_V028P.pdf
There is a multi-function select register listed as 0x2a-1 and 0x2a-2.
These are the original names in the datasheet, but superiotool will
display register 0x29 and 0x28 and their values.
This patch renames them both to 0x2a and shows both of the default values
for them. They are both 0x00, so one of them could be dropped though.
Change-Id: Iad91f9e4755d2d1a123e56ab0fa9257be7ea9978
Signed-off-by: Wilbert Duijvenvoorde <w.a.n.duijvenvoorde@gmail.com>
Reviewed-on: https://review.coreboot.org/5404
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This resolves a long-standing issue with RDIMM control word
configuration failure, likely due to random parity failure.
Change-Id: If8b8dc5b8b99f4c2fe29b3a133b064631e4693be
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14184
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I96d695ed10176276116fcf3a2b77605fb3f2d5db
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13710
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In order to add a fallback mechanism, move the ram training code
into a new function. This function will be called multiple times
and must return error or success to the calling function.
Change-Id: I5ee1b3a528290d8252d236b9152b81291736958a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14169
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Somehow the missing header file in
https://review.coreboot.org/#/c/14182 did not trigger compilation
errors before. Add the required header file to enable proper
compilation of storm.
Change-Id: I83c8f2b5fc41e38c1385ff405370753e6eba2abc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14185
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This patch would enable PROCHOT feature in skylake. Asserting
PROCHOT line would throttle the GPU/CPU.
BUG=chrome-os-partner:51142
BRANCH=glados
TEST=manually tested on lars. asserting PROCTHOT by EC
reduces FSP in fish-tank from approx 40 to 20. (50 fish setting),
also CPU freq. drops to from 1600000 to 400000
Change-Id: I8fc0c015ea2c26d20bbbfc619f720f231d540feb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1b88b1f183df9c7362d7e58acb0a1fa0b076d56e
Original-Change-Id: Ida8636efc3d8da56ebd3931144d31ab1b88fe806
Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/331690
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-(cherry picked from commit d091a999c3827179182b62a1274a9b3581f7f006)
Original-Reviewed-on: https://chromium-review.googlesource.com/333073
Original-Commit-Ready: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Tested-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/14120
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
MinPL1: 2.5W
MaxPL1: 7W
StepPL1: 0.25W
_PSV(TSR2): 51C
_TRT(TSR2): 9 second
BUG=chrome-os-partner:49859
BRANCH=glados
TEST=build and boot on chell
Change-Id: I69de1d66fb0d52ad0ad77eb51ca56f50fc44c255
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 845f1d046a5143057d683b2bd9cf5dab2ab2ef34
Original-Change-Id: I8a161c979a22621f5f854926677cb7835f8ce88b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/332857
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-(cherry picked from commit 4d5023524591fc6b651a199874ed990bd5be1d50)
Original-Reviewed-on: https://chromium-review.googlesource.com/333071
Reviewed-on: https://review.coreboot.org/14119
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
GPP_E_21_DDPC_CTRLDATA is pulled low by default.
This causes 2.5mW leakage from 3.3S to GND via R877.
So configuring GPP_E21 in native mode.
BUG=chrome-os-partner:50958
BRANCH=glados
TEST=Build and boot. Measure Power at 3P3S(R955).
Change-Id: I2bdcb698d0b0cd3228c2e59653ac3fb3b1a26951
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d01f932cda44b0b44c5494b316aefc43c8b84c52
Original-Change-Id: Ifd13ea4b16108ef98d09891365f0d17831ab5f65
Original-Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332369
Original-Commit-Ready: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14108
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When doing verification of memory init code in verstage vboot
should issue a TPM_Startup(ST_STATE) instead of TPM_Startup(ST_CLEAR)
in order to preserve the flags in TPM_STCLEAR_FLAGS which include
things like physical presence. In doing so we can also skip the rest
of the TPM init work in this function in the S3 resume path.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=S3 resume on chell and ensure TPM is resumed instead of being
cleared and that 'tpmc getvf|getpf|getf' does not show any difference
in flags between boot and resume.
Change-Id: I7a48eaf7f57d2bc6ebc182178cbe60ceb2ad8863
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f059f39a0f5c2f21e564b9554efacf26a41ad794
Original-Change-Id: I647869202d2f04328764155d3de4cad9edf10ae4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332434
Original-(cherry picked from commit 5fc7792e4104523569140cd84ce313da721ec34b)
Original-Reviewed-on: https://chromium-review.googlesource.com/332542
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
For platforms that do verification of memory init (and have verstage
execute before romstage) FSP should not attempt to re-initialize the
TPM again in romstage as it has already been done.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=boot and resume on chell and ensure TPM is not re-initialized
Change-Id: Ied6f39dc8dacdbc3d76070b6135de2308196ff53
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fefd4d4b3fde4c7fe4b6de304790914b7a2f87d8
Original-Change-Id: I60a2e4e2d73270697218f094527e09d444e6ab56
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332433
Original-(cherry picked from commit 2de1fd57fe1db7960e0bb86c64dccf827fa55742)
Original-Reviewed-on: https://chromium-review.googlesource.com/332299
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14106
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The board status script wasn't checking the entire tree to make sure
that all boards had board_info.txt files. Also it would only print
out the first issue that was found.
Change-Id: I5f2fa9e564c805c6dbee7a35cab80c1c342567a5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14118
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
It's required to store the dimm_info in ramctr_timing as only ramctr_timing
is written to mrc cache.
Allows to fill SMBIOS type 17 if mrc cache is used.
Change-Id: I7634b05069df307d471938d9854997a018de81b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
DRAM initialization on storm requires ipq blobs to be
loaded from cbfs. vboot_locator first checks cbmem_find to see if cbmem is
initialized and contains selected region info, else it falls back to
vboot work buffer.
Since cbmem_find calls into cbmem_top to identify the location of
cbmem area, board/chipset is expected to return NULL until the backing
store is ready, which in this case until DRAM is initialized in
romstage, return NULL for cbmem_top.
Change-Id: I1880ce61dcfdabaa527d7a6dcc3482dfe5d5fd17
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Board or chipset needs to ensure that cbmem backing store is ready
when returning the cbmem top address. cbmem infrastructure has no
support for checking the validity of the backing store/address.
E.g.: If romstage handles cbmem coming online, chipset or board need
to ensure that call to cbmem_top in romstage returns NULL if the
backing store is not yet initialized.
Add a comment to ensure that developers know this requirement while
implementing cbmem_top for future chipsets/boards.
Change-Id: I0086b8e528f65190b764a84365cf9bf970b69c3f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14181
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In the board status repository, there is trailing whitespace in the
coreboot log of the board ASUS KFSN4-DRE.
```
SATA S SATA P
```
Remove it, as it’s unnecessary.
Change-Id: I5c505eb7c734dca3fa18235e2bc0bc82b5b50b16
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/14175
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
|
|
Replace open coded memset() functions with calls to the library function.
The new code also explicitly backs up and restores the data structures
that are preserved across calls to mct_ResetDataStruct_D(), and no longer
relies on structure member order to function correctly.
Change-Id: I6dd6377deda0087cd1b65f7555588978657d6516
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic5482dc13ab7b53ec4df408bbe32d20888ae2e12
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13725
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If you want to be a maintainer Damien just add yourself to the list.
Change-Id: I15c646fc23d0804a8172da66d9297ab7977e6e6a
Reviewed-on: https://review.coreboot.org/14157
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add coreboot build tests after running the toolchain build. This
verifies that everything still builds with the new toolchain.
Change-Id: Ifa51db897925c0b77791c83bbcbfd75045c907b5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14156
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The lint script didn't catch that these mainboard directories didn't
have board_info files.
Add all missing board_info.txt files
Change-Id: Ib1d61a3c04e91b22480527885faf60c22093d98a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14117
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
The intelmetool shows information about the Intel
Management Engine for different platforms.
Original source code can be found under following link:
https://github.com/zamaudio/intelmetool.git
Change-Id: I0eb17833a21eb04cf9245a7312289a4102bec1a9
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/14136
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A call to i2c_read() for a non-existent address followed by an i2c_read()
to a valid address results in a false abort status for the 2nd call.
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0x4000000 (I2C_ERR_ABORT)
Because the abort status register is cleared on read and wait_tx_fifo()
reads it twice, the returned status does not contain the abort status.
Fixing that changed the 2nd read to reflect the abort status.
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0x4000001 (I2C_ERR_ABORT)
Bit 0 indicates that the address was not acknowledged by any slave.
That's the abort status from the previous transaction.
So I added a read of the abort status before starting a transaction in
both i2c_read() and i2c_write().
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0 (I2C_SUCCESS)
Tested on a Bay Trail E3845 SoC.
Change-Id: I39e4ff4206587267b6fceef58f4a567bf162fbbe
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14160
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
i2c.c uses "*(volatile unsigned int *)" constructs where it could use
read32() and write32().
Switch to using read32() and write32().
The remaining instances in wait_tx_fifo() and wait_rx_fifo() are fixed
in https://review.coreboot.org/#/c/14160/
Change-Id: I39e4ff4206587267b6fceef58f4a567bf162fbbe
(intel/fsp_baytrail: Fix I2C abort logic)
I also fixed a few minor white space issues.
Change-Id: I587551272ac171ef1f42c7eb26daf877dc56646b
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14162
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
- Copy each config in configs/ to the junit_config, update each,
in turn, and clean up when done. This avoids updating the saved
config files and creating dirty files in git.
- Use 'make olddefconfig' instead of 'yes "" | make oldconfig'
- Update clean target to remove junit_config file
- Update distclean target to remove junit.xml
Change-Id: Ib023eb3197f2d8806c73c9c18464157ce3de958f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14164
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Add check_for_library routine to test for missing libraries.
- Add a check for zlib.
- Remove 'utility' text from please_install() routine since we can test
for libraries or utilities now.
- Remove incorrect 'solution' text from alternate install since I was
updating that line.
Change-Id: Id5ef28f8bde114cbf4e5a91fc119d42593ea6ab2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14147
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are multi-threaded decompressors for .gz and .bz2 compressed
files. If they're installed, use them to decompress, if they're not,
use the standard single-threaded decompressors.
Change-Id: I397740817e6b234a43b62075899964bdab14f121
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14146
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a newline after the supported version text.
Move $TARGETDIR left so that longer paths print better.
Change-Id: If520e1b8657a526dee27763aee62cb78777d020d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
During maximum read latency training on Family 15h processors,
the maximum read latency was incorrectly set from the NBP1
value instead of the correct NBP0 value.
Modify maximimum read latency training to explicitly operate
on the NBP0 value, and store the previously calculated NBP1
value for reference by other portions of the training algorithm.
Change-Id: I5d4a6c2def83df3e23f1a4c598314c31a0172cd7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14150
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This is required on powerpc64 to build both little endian and big endian
libgcc.
Change-Id: I295c8ee5e8131d4108e98d1bfd53abb8bd8982b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14163
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Update IASL from 20150619 to 20160318
See release notes at acpica.org
Change-Id: Ic7e7b3956378ad611069e984d5a59c78e4cb08b1
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/12817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Coreboot and most payloads support three basic pixel widths for the
framebuffer. It assumes 32 by default, but several chipsets need to
override that value with whatever else they're supporting. Our struct
edid contains multiple convenience values that are directly derived from
this (and other properties), so changing the bits per pixel always
requires recalculating all those dependents in the chipset code. This
patch provides a small convenience wrapper that can be used to
consistently update the whole struct edid with a new pixel width
instead, so we no longer need to duplicate those calculations
everywhere.
BUG=None
TEST=Booted Oak in all three pixel widths (which it conveniently all
supports), confirmed that images looked good.
Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: If8c07fb3bee4bf0b531e52fae29890af99f924b4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14161
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
dqsTrainMaxRdLatency_SW_Fam15()
Change-Id: Ic3f636983cf6ba2796ee56e2a25b56513a4343c1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14148
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As a follow up to Change-Id: I1fb3fc139e0a813acf9d70f14386a9603c9f9ede,
use as builtin compiler hint instead of inline assembly to allow the
compiler to generate more efficient code.
Change-Id: I690514ac6d8988a6494ad3a77690709d932802b0
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12083
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current Apollolake flow has its code executing out of
cache-as-ram for the pre-DRAM stages. This is different from
past platforms where they were just executing-in-place against
the memory-mapped SPI flash boot media. The implication is
that when cache-as-ram needs to be torn down one needs to be
executing out of DRAM since the act of cache-as-ram going
away means the code disappears out from under the processor.
Therefore load and use the postcar infrastructure to bootstrap
this process for tearing down cache-as-ram and subsequently
loading ramstage.
Change-Id: I856f4b992dd2609b95375767bfa4fe64a267d89e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14141
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This patch adds support for an alternative ternary number system in
which group of GPIOs can be interpreted. In this system, the digit
combinations that would form a binary number (i.e. that contain no 'Z'
state) are used to represent the lower values in the way they're used in
the normal binary system, and all the combinations that do contain a 'Z'
are used to represent values above those. We can use this for boards
that originally get strapped with binary board IDs but eventually
require more revisions than that representation allows. We can switch
their code to binary_first base3 and all old revisions with already
produced boards will still get read as the correct numbers.
Credit for the algorithm idea goes to Haran Talmon.
BRANCH=None
BUG=None
TEST=Stubbed out the actual GPIO reading and simulated all combinations
of 4 ternary digits for both number systems.
Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14116
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: If3b49c3056abe6e1c1a14578d6c62a866bc6834d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14127
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Hannah Williams <hannah.williams@intel.com>
|
|
In order for a caller to utilize an rmodule's parameters section
after calling rmodule_stage_load() export the rmodule's parameter
pointer in struct rmod_stage_load.
Change-Id: I9cd51652cf8cdb3fae773256989851638aa1a60f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14139
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change-Id: Ib127af5392ca2b349480f5b21fad2186b444d7e6
Signed-off-by: Lance Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/13348
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Set MMCONF_BASE_ADDRESS to 0xf8000000.
It was already done for some boards, but not all.
The sandybridge chipset code assumes 64 pci buses behind MMCONF.
Therefore, only 64MiB of physical address space is required.
Increasing the address allows to use additional 128MiB of MMIO
space and to use the Intel IGD and a PEG at the same time.
Previously it wasn't possible to use both at the same time,
as two 256MiB areas won't fit into MMIO space.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* Onboard GPU Intel IvyBridge Desktop
* PEG GPU AMD RV770
Change-Id: I3bf72439056c8089ada6899bb0605e5cd9d89cd6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14096
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
In Chromium OS downstream this was done together with adding the support
for ATF, but unfortunately ATF upstream isn't ready yet. This commit
is a reminder to enable things once ATF caught up.
Change-Id: Id0d6908d906a1e54cdda4f232d572d996d9c556f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13968
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As the DA9212 and MT6311 external buck can be controlled by hardware
since rev-5 board, we don't need to pass any board specific parameter
to ARM TF.
BRANCH=none
BUG=none
TEST=build pass
Change-Id: I43eebe25ab14d3dd84e8bb4286e2bb55c8c3c063
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c4dfe61c69042e464b384e2e0edbc55eda23a74
Original-Change-Id: I541357fee6afb1ff2d771bcb073f7c9a9db52f00
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332344
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14124
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove the code which is passing parameters to ARMTF and move external
buck initilizaton from ARMTF to coreboot.
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: I4f4b30acbee9b42a202b326f2fe4517cb4b9d83c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 37bec54b4d8a3bce38878e292e4821da3959026a
Original-Change-Id: Ib81709812a064f6daf13c9b4d6525f1858c81393
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332343
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14123
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add secondary PMIC for external buck control on Oak rev0/1/2/5
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: Ia000b0c7d61e8396856656247f9627e33b21b19b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 241508e7d781fac8ee085ee81962043dd654c52d
Original-Change-Id: I6c75e2462363a5523bf1ebb03af7a36740293624
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332342
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14122
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add secondary PMIC for external buck control on Oak rev3/4
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: I24c18a1cf71fc57deacedcbeb6a100b131c28077
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7f7f8ceac795d8193194a6918a73c4b391009025
Original-Change-Id: I312d8281d2c09d8bc43f092edef3e405d51ee7d0
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332341
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14121
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
i2c_read_field() - read the value from the specific register field
i2c_write_field() - write the value to the specific register field
BRANCH=none
BUG=none
TEST=none
Change-Id: I2098715b4583c1936c93b3ff45ec330910964304
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0817fc76d07491b39c066f1393a6435f0831b50c
Original-Change-Id: I92c187a89d10cfcecf3dfd9291e0bc015459c393
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14105
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Under certain conditions (training abort) BlockRxDqsLock could
remain set in violation of the BKDG. Ensure BlockRxDqsLock is
reset to 0 after a lane training abort.
Change-Id: I1a49a24d02b2b7cacae074794ec274a424a9e66b
Reviewed-on: https://review.coreboot.org/14144
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Document how to test TempRamExit and verify the MTRR setup and loading.
TEST=None
Change-Id: I57a604fa139edac4b05453547d3caf185db491e0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14113
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add datasheet links for the components supporting GPIO. This includes
I2C I/O ports, I2C PWMs, bus buffers and multiplexers.
TEST=None
Change-Id: I0a1d222d6f9bdbd824b78edf2338cd797e83ebba
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14114
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add documentation on disabling the SPI flash which is mapped (shadowed)
into the x86 address space at 0x000e0000 - 0x000fffff.
TEST=None
Change-Id: I1d94d84c6cade97886a3274a7e7403f7b3275c5a
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14112
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Disable the ROM shadow and enable RAM for 0x000e0000 - 0x000fffff.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing successful display of 0x000ffff0 - 0x000fffff does not match
the end of the SPI flash.
Change-Id: I6e0a50417815320333eae0b69b96280c39db7eaa
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14110
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Enable the SPI controllers on the Quark SoC.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Load the SPI driver stack
* Testing is successful when the time is able to be displayed on a
set of seven-segment displays controlled by a Maxim MAX6950 SPI
display controller.
Change-Id: Ic9c4575730c5a9a27cf9a38a41e82d8462467f3f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14109
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add missing punctuation and align output.
No functionality is changed.
Old logging output:
Revision: 11
Type : b
Key : 2
Banks : 8
Capacity: 4 Gb
Supported voltages: 1.5V
SDRAM width : 8
Bus extension : 0 bits
Bus width : 64
Optional features : DLL-Off_mode RZQ/7 RZQ/6
Thermal features : ASR ext_temp_range
Thermal sensor : no
Standard SDRAM : yes
DIMM Rank1 Address bits mirrored!!!
DIMM Reference card B
DIMM Manufacturer ID cd04
DIMM Part number F3-1866C9-8GSR
XMP Profile 1
Max DIMMs per channel: 4
XMP Revision: 1.3
Requested voltage: 1500 mV
New logging output:
Revision : 11
Type : b
Key : 2
Banks : 8
Capacity : 4 Gb
Supported voltages : 1.5V
SDRAM width : 8
Bus extension : 0 bits
Bus width : 64
Optional features : DLL-Off_mode RZQ/7 RZQ/6
Thermal features : ASR ext_temp_range
Thermal sensor : no
Standard SDRAM : yes
Rank1 Address bits : mirrored
DIMM Reference card: B
Manufacturer ID : cd04
Part number : F3-1866C9-8GSR
XMP Profile : 1
Max DIMMs/channel : 4
XMP Revision : 1.3
Requested voltage : 1500 mV
Change-Id: Iee4d7a7c0e1070706fb60d7316fad49813963b51
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14083
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When CONFIG_X86_TOP4G_BOOTMEDIA_MAP was introduced verstage
was not updated. Correct this oversight.
Change-Id: I2775c08798906ba0ba55a361407d7d2b52313229
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14142
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
|
