Currently boards based on fsp_broadwell_de fail to compile if the config
switch CONFIG_DEBUG_SPI_FLASH is selected. The error is caused by the
usage of const for the address pointer in the functions writeb_, writew_
and writel_. The reason why it stayed hidden for so long is the fact that
the switch is used with the preprocessor and nobody really selects it
until there is a bug one want to find in this area.
This patch fixes the parameter type definition which solves the error.
In addition the config switch is not used on preprocessor level anymore
but instead on compiler level. This ensures that at least the code
syntax is checked on build time even if the config option is not
selected. Also prefix the messages with "SPI:" to make them more
meaningful in a full log.
Change-Id: I3514b0d4c08bf5a4740f2632641e09af1b3aaf3a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16347
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This corrects indentation for sdram configs in nyan_blaze.
Change-Id: Ia9ad2a37c6e3b79e1260f490db893244c32685b6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/16342
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
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>
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>
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>
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>
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>
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>
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>
Werner Zeh