Age | Commit message (Collapse) | Author |
|
The reef board needs at least ~28ms for its S0 rails to discharge
when S3 is entered. Because of the granularity in the chipset the
effective SLP_S3_L assertion width is 50ms.
BUG=chrome-os-partner:56581
Change-Id: I20514eb0825cd4bc2ee9276b648204b7bfd6a7b0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16327
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In order to provide time for the S0 rails to discharge one needs
to be able to set the SLP_S3_L assertion width. The hardware default
is 60 microcseconds which is not slow enough on most boards. Therefore
provide a devicetree option for the mainboard to set accordingly
for its needs. An unset value in devicetree results in a conservative
2 second SLP_S3_L duration.
BUG=chrome-os-partner:56581
Change-Id: I6c6df2f7a181746708ab7897249ae82109c55f50
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16326
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change-Id: Iea3f12a5a7eb37586f5424db2d7a84c4319492f8
Reported-by: Coverity (1361947)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16335
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I8a44a58506d7cf5ebc9fe7ac4f2b46f9544ba61a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16287
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I7fb9bfcaeec0b9dfd0695d2b2d398fd01091f6bc
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16286
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
|
|
Add new option to set up Cache-As-RAM by using CQOS, Cache Quality of
Service. CQOS allows setting ways of cache in no-fill mode, while keeping
other ways in regular evicting mode. This effectively allows using CAR
and cache simultaneously.
BUG=chrome-os-partner:51959
TEST=switch from NEM to CQOS and back, boot
Change-Id: Ic7f9899918f94a5788b02a4fbd2f5d5ba9aaf91d
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15455
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Update link addresses for romstage and verstage. Also update FSP-M relocation
address.
BUG=chrome-os-partner:51959
Change-Id: Ia51a341f05b33151ea5fda9f8620408b5a15bc19
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15454
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since whole L2 (1MiB) is not used, it is possible to shrink CAR size
to 768 KiB. Since 768 KiB is not power of two, 2 MTRRs are used to
set it up. This is a part of CQOS enabling.
BUG=chrome-os-partner:51959
Change-Id: I56326a1790df202a0e428e092dd90286c58763c5
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15453
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Iebdcc659bf2a3e738702c85ee86dbb71b504721a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16279
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I37dfa853c3dbe93a52f6c37941b17717e22f6430
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16277
Reviewed-by: Omar Pakker
Tested-by: build bot (Jenkins)
|
|
Change-Id: I48477c2917ab1be14d3cedf25e8b97dae1c1d309
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16289
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I307d37cdf2647467d4c88dfa4be5c66c8587202e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16285
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I3536a99a1a6fd2bc7b10777654c1937b92e8eacd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16288
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I43b9b86fd51dbdc50108026099c60238f3012cbe
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16290
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I89bc8b26f2dba4770aea14b8bbc7e657355e8c59
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16325
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Since we now have so much more room for activities in our romstage SRAM
section, we can easily fit the LZMA decompressor to enable ramstage
compression. Also shuffle around memlayout sections a little more to
make use of unused space, and balance out leftover memory so that all
sections that might need future expansion have a reasonable amount.
Change-Id: I47f2d03e520fc3103ef04257b4ba7e93874b8956
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch changes Gru SDRAM parameters from structures that just get
compiled into the romstage to individual CBFS files. This allows us to
only load the parameter set we need for the board we're booting from
flash, which reduces our boot time and the SRAM memory footprint
required to hold the romstage.
TEST=Booted Kevin.
Change-Id: Ie88a515cbdb19a794ca0a230a56bcc82bed1e550
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16274
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The current CBMEM code contains an optimization that maintains the
structure with information about the CBMEM backing store in a global
variable, so that we don't have to recover it from cbmem_top() again
every single time we access CBMEM. However, due to the problems with
using globals in x86 romstage, this optimization has only been enabled
in ramstage.
However, all non-x86 platforms are SRAM-based (at least for now) and
can use globals perfectly fine in earlier stages. Therefore, this patch
extends the optimization on those platforms to all stages. This also
allows us to remove the requirement that cbmem_top() needs to return
NULL before its backing store has been initialized from those boards,
since the CBMEM code can now keep track of whether it has been
initialized by itself.
Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16273
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch adds support for the CBFS attributes that were already
introduced in cbfstool and libpayload. I'm only copy&pasting the header
definitions needed for this once more. Really, we should be unifying the
definitions (and possibly part of the code) from cbfstool with
commonlib, but apparently that hadn't been done when this feature was
introduced and I don't really have time to do it cleanly now.
Also add a function to extract info from the compression attribute,
which can then be used to run cbfs_load_and_decompress() on the file.
Change-Id: I7b6463597757122cfe84f006c946a1658bb3acc6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16271
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This enables the C4 low power state on the lenovo x200 and t400.
It's inspired by the thread on the mailinglist:
"[coreboot] Lenovo X200 running Coreboot drains 3-4W more power
than with Vendor BIOS".
What this does, is to enable a C3 state using MWAIT(C3) request
and set the southbridge config c4onc3_enable to automatically
upgrade C3 to the lower power C4 state.
The latency (0x37) is the same value used by the vendor bios.
With C4 enabled the idle power consumption is about ~2-3W lower.
TEST= build and install on target. Use powertop top to measure power
usage. To manually disable c-state to compare them,
do (tested on linux 4.4):
echo 1 > /sys/devices/system/cpu/cpu*/cpuidle/stateX/disable
Change-Id: I1a1663a7662ebc7157a965667680688ad6a33545
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/15251
Tested-by: build bot (Jenkins)
Reviewed-by: Swift Geek
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Some SB700-based systems and ROMs support high speed (33MHz) SPI
access instead of the power-on default 16.5MHz. Add an option
to enable high speed SPI access in the bootblock, and set the
default value to Disabled. This greatly decreases boot time on
SB700-based systems, especiall when a large payload is in use.
On a KGPE-D16 with a Petitboot (Linux + initramfs) payload, the
command prompt was accessible within 20 seconds of power on, which
incidentally is faster than the proprietary BIOS on the same machine
could even reach the GRUB bootloader.
Change-Id: Iadbd9bb611754262ef75a5e5a6ee4390a46e45cf
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Test: Booted KGPE-D16 with Linux payload
Reviewed-on: https://review.coreboot.org/16306
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add in the base for ELOG for APL. Some PM events still need to be
added but the basic events are logged here. This enables the
basic functionality of ELOG for Apollolake.
BUG=chrome-os-partner:55473
BRANCH=none
TEST=Verified image boots on Amenia
Change-Id: I8682293e5a55b3efb5fdd9f1be1f3e4bf8d0757c
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/15937
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Call power management utility function clear_wake_sts
from southbridge_smi_sleep before going to sleep.
This is needed to clear the wake status bits in ACPI
registers GPE0.
BUG=chrome-os-partner:55583
BRANCH=None
TEST=Verified that system goes to sleep on lidclose and
powerd_dbus_suspend command issued from built-in
keyboard.
Change-Id: I204a59f8a19137d6a192ea2d89939eefcd5d41ce
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/16299
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch adds a power management utility function to
clear wake status bits in ACPI GPE0 registers. We need
to call this function before going to sleep from
common smi handler function.
BUG=chrome-os-partner:55583
BRANCH=None
TEST=Verified that system goes to sleep on lidclose and
powerd_dbus_suspend command issued from built-in
keyboard.
Change-Id: Icd095d377c82f2e154f2e2db773f737aa49cda64
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/16298
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
On x86 platforms, google_chromeec_early_init() is used to put the EC
into RO mode when there's a recovery request. This is to avoid training
memory multiple times when the recovery request is through an EC host
event while the EC is running RW code. Under that condition the EC will
be reset (along with the rest of the system) when the kernel verification
happens. This leads to an execessively long recovery path because of the
double reboot performing full memory training each time.
By putting this logic into the verstage program this reduces the
bootblock size on the skylake boards. Additionally, this provides the
the correct logic for all future boards since it's not tied to FSP
nor the mainboard itself. Lastly, this double memory training protection
works only for platforms which verify starting from bootblock. The
platforms which don't start verifying until after romstage need to
have their own calls (such as haswell and baytrail).
Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16318
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
When UART_DEBUG is enabled bootblock size grows more than the current
32K. Bump this up to 48K.
Change-Id: I580137dfdc9b4ad226c866f2b23b159bd820c62c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16317
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The chromium tree is currently using a different config for
Chrome OS than what is being built in coreboot.org. Align those
settings to reflect how skylake Chrome OS boards are actually
shipped to provide proper parity between coreboot.org and chromium.
Change-Id: I7ab9c1dfa8c6be03ac2125fb06cb7022f3befa97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16313
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Apply eMMC tuned DLL settings for reef evt.
Modify comments to avoid replicating info.
Add EDS reference.
BUG=chrome-os-partner:55648
BRANCH=none
TEST=Verify that reef evt boots to OS from eMMC.
Change-Id: If3bf51f3b7d38320f504ea6fbecf7c188a94ae5c
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://review.coreboot.org/16296
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The SPI drivers for the various chipsets are not consistent in
their handling of when they are accessible. Coupled with the
unknown ordering of boot_device_init() being called this can
lead to unexpected behavior (probing failures or hangs). Instead
move the act of initializing the SPI flash boot device to when
the various infrastructure requires its usage when it calls
boot_device_rw(). Those platforms utilizing the RW boot device
would need to ensure their SPI drivers are functional and
ready when the call happens.
This further removes any other systems failing to boot as
reported in https://ticket.coreboot.org/issues/67.
BUG=chrome-os-partner:56151
Change-Id: Ib3bddf5e26bf5322f3dd20345eeef6bee40f0f66
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16300
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: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Implement PS0 and PS3 methods to support eMMC power gate
in S0ix suspend and resume.
BUG=chrome-os-partner:53876
TEST=Suspend and Resume using 'echo freeze > /sys/power/state'.
System should resume from S0ix.
Change-Id: Ia974e9ed67ee520d16f6d6a60294bc62a120fd76
Signed-off-by: Vaibhav Shankar <vaibhav.shankar@intel.com>
Reviewed-on: https://review.coreboot.org/16233
Tested-by: build bot (Jenkins)
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
The return value check was incorect and checking for failure
in the success path. Fix the return value check so that it
actually checks for success.
BUG=chrome-os-partner:56151
Change-Id: Ie7960b89a916dec261015c97c3e0552be56b5b5d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16303
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
vboot_named_region_device_rw() is supposed to provide a writable
region_device. However, it was calling fmap_locate_area_as_rdev()
which only provides a read-only one. Fix this.
BUG=chrome-os-partner:56151
Change-Id: I6279fde32132b1b6138292c3ef771c59709e00c6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16302
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Normally machine-mode code operates completely within physical address
space. When emulating less privileged memory accesses (e.g. when the
hardware doesn't support unaligned read/write), it is useful to access
memory through the MMU (and with virtual addresses); this patch
implements this functionality using the MPRV bit.
Change-Id: Ic3b3301f348769faf3ee3ef2a78935dfbcbd15fd
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16260
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I273e9d20e02f0333f28e0fc2adcc7940578ea93e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16263
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Not all SBI calls are implemented, but it's enough to see a couple dozen
lines of Linux boot output.
It should also be noted that the SBI is still in flux:
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/6oNhlW0OFKM
Change-Id: I80e4fe508336d6428ca7136bc388fbc3cda4f1e4
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16119
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ie62f60b2e237fa4921384e3894569ae29639f563
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16262
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I06c6493355f25f3780f75e345c517b434912696f
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16261
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The timestamp code asserts that the _timestamp region (allocated in
memlayout for pre-RAM stages) is large enough for the assumptions it
makes. This is good, except that we often initialize timestamps
extremely early in the bootblock, even before console output. Debugging
a BUG() that hits before console_init() is no fun.
This patch adds a link-time assertion for the size of the _timestamp
region in memlayout to prevent people from accidentally running into
this issue.
Change-Id: Ibe4301fb89c47fde28e883fd11647d6b62a66fb0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Change-Id: I1c8127412af0f9acc5b5520dc324ac145e59a4bd
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A new Kconfig option, DEBUG_PRINT_PAGE_TABLES, is added to control this
behaviour. It is currently only available on RISC-V, but other
architectures can use it, too, should the need arise.
Change-Id: I52a863d8bc814ab3ed3a1f141d0a77edc6e4044d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16015
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I9789b0b3339435fbe30c69221826bf23c9b3c77b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16283
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ibec78b25c0f330fc8517654761803e8abf203060
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16282
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I42cc5b8736e73728c5deec6349e8d2a814e19e83
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16281
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Omar Pakker
|
|
Change-Id: I82e0736dc6b44cfcc57cdfdc786c85c4b6882260
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16276
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I6a533667c7c8ff5ec6ab9d4e1cfc51e993a90084
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16280
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: I9b3a2cce6c6bb85791d5cde076d5de95ef0e8790
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16278
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Add cmos.default file in order to ease future testing and debugging of
cmos related code.
Change-Id: I7c6a0aa4e38bb08a520e4838fa216c81b50f2917
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16247
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Update the config variable that gets set to use DMIC 2 channel blob for
intel/apollolake platforms. This flag is set in mainboard.
Change-Id: Ic6deb9f08d345cc45351d61a7597bc7075ee20f9
Signed-off-by: Saurabh Satija <saurabh.satija@intel.com>
Reviewed-on: https://review.coreboot.org/16251
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
It's necessary to call spi_init() prior to calling spi_flash_probe()
such that the SPI drivers can do any work required prior to performing
SPI transactions. It could be argued that the drivers should handle
such situations, however the SPI API implementations seem to assume the
callers ensured spi_init() was called before any SPI transactions.
This fixes systems that failed to boot introduced by [1]. Issue tracked
in https://ticket.coreboot.org/issues/67.
[1] I2aa75f88409309e3f9b9bd79b52d27c0061139c8
https://review.coreboot.org/16200
BUG=chrome-os-partner:56151
Change-Id: I2d8d5ac685833521f1efe212b07a4b61ba0d9bc3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16297
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|