| Age | Commit message (Collapse) | Author |
|---|
|
All current implementations of ramstage_cache_invalid() were just
resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE
Kconfig option. Move that behavior to a single implementation
within prog_loaders.c which removes duplication.
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17184
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Add config in fsp 2.0/1.1 driver to reset if ramstage stage cache is
invalid during S3 resume.
Change-Id: I83fe76957c061f20e9afb308e55923806fda4f93
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17112
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
BUG=chrome-os-partner:57846
Change-Id: Id6bd91b3fd6420994ad5811d362618b1a38a8afa
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17092
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
1. Export i2c_generic_fill_ssdt to allow other device-specific i2c
drivers to share and re-use the same code for generating AML code for
SSDT. In order to achieve this, following changes are required:
a. Add macro I2C_GENERIC_CONFIG that defines a structure with all
generic i2c device-tree properties. This macro should be placed by the
using driver at the start of its config structure.
b. Accept a callback function to add any device specific information to
SSDT. If generic driver is used directly by a device, callback would be
NULL. Other devices using a separate i2c driver can provide a callback
to add any properties to SSDT.
2. Allow device to provide _CID.
BUG=chrome-os-partner:57846
Change-Id: I3a0054e22b81f9d6d407bef417eae5e9edc04ee4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17089
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Add support to allow a device to define PowerResource in its SSDT AML
code. PowerResouce ACPI generation expects SoC to define the
callbacks for generating AML code for GPIO manipulation.
Device requiring PowerResource needs to define following parameters:
1. Reset GPIO - Optional, GPIO to put device into reset or take it out
of reset.
2. Reset delay - Delay after reset GPIO is de-asserted (default 0).
3. Enable GPIO - Optional, GPIO to enabled device.
4. Enable delay - Delay after enable GPIO is asserted (default 0).
BUG=chrome-os-partner:55988
Change-Id: Ieb2dd95fc1f555f5de66f3dda425172ac5b75dad
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17081
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Return config->name if it is not NULL.
BUG=chrome-os-partner:55988
Change-Id: I9ae229949b73de6f991383daae8d962d6cf457a7
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17077
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When compiling a non-x86 platform with DRIVERS_INTEL_WIFI enabled,
we get the build error:
src/drivers/intel/wifi/wifi.c:17:30: fatal error:
arch/acpi_device.h: No such file or directory
acpi_device.h only exists in the x86 architecture directory.
Change-Id: Id0e29558336bf44e638cfcb97c22f31683ea4ec7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16906
Tested-by: build bot (Jenkins)
Reviewed-by: Antonello Dettori <dev@dettori.io>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
This patch enables stage cache to save ~40ms during S3 resume.
It saves ramstage in the stage cache and restores it on resume
so that ramstage does not have to reinitialize during the
resume flow. Stage cache functionality is added to postcar stage
since ramstage is called from postcar.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for Reef and tested ramstage being cached
Change-Id: I1551fd0faca536bd8c8656f0a8ec7f900aae1f72
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16833
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: If79eb706b6d44f7c34dfe31a1545f5850870b334
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16866
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
UX Doc = go/gale-hw-ui
This color wasn't changed earlier as the change wasn't done in
the OS also. However, since we cannot change this later in FW
(but OS can change anytime), I am making this change after discussing
with the UX team.
BUG=b:31501528, b:31633562
TEST=Change the device state to 'recovery mode' to observe the new
color.
BRANCH=none
Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70
Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388206
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16767
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Colors and patterns as defined by the UX team
BUG=b:31501528
TEST=Move the device to different states in FW using rec and dev
button and verify the colors
BRANCH=None
Change-Id: I66d41a54590cd3ce4e5202c7cfa890f462fe195e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 703559d5dddaeeb7d435d6cadbb2009a1b7a76c8
Original-Change-Id: I95ab1fa59b483396ff1498a28f1ee98ac08d02d7
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387258
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16718
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
SPI read speed directly impacts boot time and we do quite a lot of
reading.
Add a way to easily find out the speed of SPI flash reads within
coreboot.
Write speed is less important since there are very few writes and they
are small.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=run on gru with SPI_SPEED_DEBUG set to 1. See the output messages:
read SPI 627d4 7d73: 18455 us, 1740 KB/s, 13.920 Mbps
Change-Id: Id3814bd2b7bd045cdfcc67eb1fabc861bf9ed3b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 82cb93f6be47efce3b0a3843bab89d2381baef89
Original-Change-Id: Iec66f5b8e3ad62f14d836a538dc7801e4ca669e7
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376944
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16701
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Gale EVT3 has only one LED controller (earlier we had 2).
Remove the support for the second controller and also the
corresponding microcode. The color values used are the same
as onHub (Arkham to be specific).
BUG=b:30890905
TEST=Move the device to different states manually by appropriate
actions (like dev mode, rec mode etc) and observe the different
colors.
BRANCH=None
Change-Id: I853035610ea7ea7c8d29c30d2de13c9e2e786b2b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 593905d2d69daa7482318aa5f5c5cd7cf984043e
Original-Change-Id: If8f22abd605faac6f6215ef600041740ce15ea0c
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/370821
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16697
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Move the setup of the IRQ status handler so it will be set up properly
before the early probe happens.
BUG=chrome-os-partner:53336
Change-Id: I4380af1233d2a252899459635a3cb69ca196088d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16861
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Because these variables had "non-hexidecimal" defaults, they
were updated by kconfig when writing defconfig files.
Change-Id: Ic1a070d340708f989157ad18ddc79de7bb92d873
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16827
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
A copy of our uart8250io driver sneaked in with Broadwell-DE support.
The only difference is the lack of initialization (due to FSP handling
that).
TEST=manually compared resulting object files
Change-Id: I09be10b76c76c1306ad2c8db8fb07794dde1b0f2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/16786
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Fix errors in debug display support.
BRANCH=none
BUG=None
TEST=Build FSP 2.0 (SEC/PEI core with all FSP debug on) and run on
Galileo Gen2
Change-Id: I2ece056d66dc8568a7b7206970f20368ec5bf147
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16809
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a config option to the generic I2C device driver to indicate to
the OS that this device should be probed before being added.
This can be used to provide ACPI device instantiations to devices that
may not actually exist on the board. For example, if multiple trackpad
vendors are supported on the same board they can both be described in
ACPI and the OS will probe the address and load the driver only if the
device responds to the probe at that address.
BUG=chrome-os-partner:57686
Change-Id: I22cffb4b15f25d97dfd37dc58bca315f57bafc59
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16742
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The VBT id string is 20 characters long.
If the string is shorter than 20 it needs spaces at the end.
This change is cosmetic as all strings were padded by hand.
Change-Id: Id6439f1d3dbd09319ee99ce9d15dbc3bcead1f53
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16739
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: Ic8f805159650c45382cacac8840450a1f8b4d7a1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16672
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: Ie2dfb7ede1bcda0e77070df945c47c1428115907
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16668
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifdcb3be0036b2c02bfbd1bcd326e9519d3726ee0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16667
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: I826a7f024f8d137453af86ba920e0a3a734f7349
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16666
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: Ia396fc48b8fe6e56e7071db9d74561de02b5b50e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16665
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Reduce the static buffer size from the generic default 1260
down to 64 to match the max FIFO size for the cr50 hardware
and reduce the footprint of the driver.
BUG=chrome-os-partner:53336
Change-Id: I6f9f71d501b60299edad4b16cc553a85391a1866
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Originally I thought it would be cleaner to keep this code in one
place, but as things continue to diverge it ends up being easier
to split this into its own driver. This way the different drivers
in coreboot, depthcharge, and the kernel, can all be standalone
and if one is changed it is easier to modify the others.
This change splits out the cr50 driver and brings along the basic
elements from the existing driver with no real change in
functionality. The following commits will modify the code to make
it consistent so it can all be shared with depthcharge and the
linux kernel drivers.
BUG=chrome-os-partner:53336
Change-Id: I3b62b680773d23cc5a7d2217b9754c6c28bccfa7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16663
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Move the common enums and variables to tpm.h so it can be
used by multiple drivers.
BUG=chrome-os-partner:53336
Change-Id: Ie749f13562be753293448fee2c2d643797bf8049
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16662
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This reverts commit 64df72e8e2d1c086705325533767ca5e201e842a.
|
|
This reverts commit c565f9910707b91fcc7a27bab28806e558bb474d.
|
|
This reverts commit 97a2a1ece152b6d40a524361721405b77c37959d.
|
|
This reverts commit 93c778688f0bf2f90334505a3082a2cd4ce1623a.
|
|
This reverts commit 6f5ceb26b9b3e1455ebbd6192e1d2c832bddc77e.
|
|
This reverts commit 557e1a729a9ca89e814220b6203b7ac0dc446913.
|
|
This reverts commit 1241e7db55aff313e56bf4546d969c11368b08a2.
|
|
This reverts commit a5e419c51187d24818f056327746a18676fe3a20.
|
|
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: I9f78f520fd089cb4471d8826a8cfecff67398bf8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: I7e3912fb8d8c6ad17d1af2d2a7189bf7c0c52c8e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifa1445224b475aec38c2ac56e15cb7ba7fcd21ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: Ib4a68ce1b3a83ea7c4bcefb9c6f002f6dd4aac1f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: I77fdd7ea646b8b2fef449f07e3a08bcce174fe8b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Reduce the static buffer size from the generic default 1260
down to 64 to match the max FIFO size for the cr50 hardware
and reduce the footprint of the driver.
BUG=chrome-os-partner:53336
Change-Id: Ia88facca607f3fd5072d0d986323fde075f15855
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Originally I thought it would be cleaner to keep this code in one
place, but as things continue to diverge it ends up being easier
to split this into its own driver. This way the different drivers
in coreboot, depthcharge, and the kernel, can all be standalone
and if one is changed it is easier to modify the others.
This change splits out the cr50 driver and brings along the basic
elements from the existing driver with no real change in
functionality. The following commits will modify the code to make
it consistent so it can all be shared with depthcharge and the
linux kernel drivers.
BUG=chrome-os-partner:53336
Change-Id: Ia9a65e72519b95f5739e3b7a16b9c2431d64ebe2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Move the common enums and variables to tpm.h so it can be
used by multiple drivers.
BUG=chrome-os-partner:53336
Change-Id: I0febe98620d0ddd4ec6b46cd3073e48c12926266
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Remove fsp1.1 driver code that adds vbt.bin & use soc/intel/common
instead to add vbt.bin in cbfs.
Also, VBT blob is added to CBFS as RAW type hence when walking the
CBFS to find vbt.bin, search with type as RAW.
Change-Id: I08f2556a34f83a0ea2b67b003e51dcace994361b
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16610
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
move lb_framebuffer function in soc/intel/apollolake
to driver/intel/fsp20 so that fsp 2.0 bases soc's can
use common lb_framebuffer function.
Change-Id: If11bc7faa378a39cf7d4487f9095465a4df84853
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/16549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
If FSP_M_XIP is selected, then relocate FSP-M binary
while adding it in CBFS so that it can be executed in place.
Change-Id: I2579e8a9be06cfe8cc162337fb1064d15842229f
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16563
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The TPM driver was largely ignoring the meaning of the command
ready bit in the status register, instead just arbitrarily
sending it at the end of every receive transaction.
Instead of doing this have the command ready bit be set at the
start of a transaction, and only clear it at the end of a
transaction if it is still set, in case of failure.
Also the cr50 function to wait for status and burst count was
not waiting the full 2s that the existing driver does so that
value is increased. Also, during the probe routine a delay is
inserted after each status register read to ensure the TPM has
time to actually start up.
Change-Id: I1c66ea9849e6be537c7be06d57258f27c563c1c2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16591
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
'bool' type is reported undefined due to missing stdint.h inclusion,
Fix it by including the same.
Change-Id: Ib09c121471bd8c490442330a478145a7d1d8855f
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/16538
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This replaces magic values with defines without changing any value.
Change-Id: I332442045aa4a28ffed88fc52a99a4364684f00c
Signed-off-by: Sebastian "Swift Geek" Grzywna <swiftgeek@gmail.com>
Reviewed-on: https://review.coreboot.org/16339
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The early TPM probe was done directly in tis.c ignoring the lower
layer that provides appropriate access to the chip. Move this into
a tpm_vendor_probe() function so it can use iic_tpm_read() with all
of the built-in delays and semantics instead of calling i2c_readb()
directly from the wrong layer.
This fixes early init failures that were seen with the cr50 i2c tpm
on the reef mainboard.
Change-Id: I9bb3b820d10f6e2ea24c57b90cf0edc813cdc7e0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16527
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
If the TPM completely fails to respond then the vendor structure may not
have assigned handlers yet, so catch that case and return error so the
boot can continue to recovery mode instead of asserting over and over.
Change-Id: If3a11567df89bc73b4d4878bf89d877974044f34
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16416
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add code to generate an ACPI descriptor for an I2C TPM based
on the device as described in devicetree.cb.
This currently requires the devicetree to provide the HID,
since we don't currently talk to the TPM in ramstage and I
didn't want to add yet another init path for it here.
This was tested on a reef board to ensure that the device
is described properly in the SSDT.
Change-Id: I43d7f6192f48e99a4074baa4e52f0a9ee554a250
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16397
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add support for the cr50 TPM used in apollolake chromebooks.
This requires custom handling due to chip limitations, which
may be revisited but are needed to get things working today.
- timeouts need to be longer
- must use the older style write+wait+read read protocol
- all 4 bytes of status register must be read at once
- same limitation applies when reading burst count from status reg
- burst count max is 63 bytes, and burst count behaves
slightly differently than other I2C TPMs
- TPM expects the host to drain the full burst count (63 bytes)
from the FIFO on a read
Luckily the existing driver provides most abstraction needed to
make this work seamlessly. To maximize code re-use the support
for cr50 is added directly instead of as a separate driver and the
style is kept similar to the rest of the driver code.
This was tested with the cr50 TPM on a reef board with vboot
use of TPM for secdata storage and factory initialization.
Change-Id: I9b0bc282e41e779da8bf9184be0a11649735a101
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16396
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
Allow the sleep durations used by the driver to be set by the
specific chip so they can be tuned appropriately.
Since we need to read the chip id to know the values use very
conservative defaults for the first command and then set it
to the current values by default.
Change-Id: Ic64159328b18a1471eb06fa8b52b589eec1e1ca2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16395
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Use CAR accessors where needed for accessing static data.
In some cases this required some minor restructuring to pass
in a variable instead of use a global one.
For the tpm_vendor_init the structure no longer has useful
defaults, which nobody was depending on anyway. This now
requires the caller to provide a non-zero address.
Tested by enabling I2C TPM on reef and compiling successfully.
Change-Id: I8e02fbcebf5fe10c4122632eda1c48b247478289
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16394
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
FSP header files should be located in vendorcode, not soc directory.
This patch includes changes any references to the old location to
the new location.
Change-Id: I44270392617418ec1b9dec15ee187863f2503341
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16310
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The following patch is based off of the UEFI 2.6 patch. The FSP header files
are temporarily staying in soc/intel/apollolake and FspUpd.h has been relocated
since the other headers expect it to be in the root of an includable directory.
Any struct defines were removed since they are defined in the headers and no
longer need to be explicity declared as struct with the UEFI 2.6 includes.
BUG=chrome-os-partner:54100
BRANCH=none
TEST=confirmed coreboot builds successfully
Change-Id: I10739dca1b6da3f15bd850adf06238f7c51508f7
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>#
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/16308
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I4d0087b2557862d04be54cf42f01b3223cb723ac
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16321
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Disable ps8640 mipi mcs function to avoid recognizing the normal mipi dsi
signal as msc cmd.
BUG=chrome-os-partner:56346
BRANCH=none
TEST=build pass elm and show ui
Change-Id: I91c690fb1ff3bd9b5c1f227205829c914347cd30
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 4fd441b46300fea9f238b27c9c1cda4e9e53c80d
Original-Change-Id: I85b9f1e6677e4bf8ab1e30c2e69445079fff2d18
Original-Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/373219
Original-Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Original-Tested-by: jitao shi <jitao.shi@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/16365
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add delay before and in polling ps8640 ready to reduce the frequency
of polling.
BUG=chrome-os-partner:54897
BRANCH=none
TEST=build pass elm and show ui
Change-Id: I43c833af910490e53496a343330a6a6af35623a9
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bc8c3d6f7cf0b2da693a465cf3845e8bbc53825a
Original-Change-Id: I5c725eed8110ff9f545c1142ca28bcff336b6860
Original-Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/371718
Original-Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Original-Tested-by: jitao shi <jitao.shi@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/16364
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
If ramstage caching outside CBMEM is enabled
i.e CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM, then a
helper function to determine the caching region in SMM
should be implemented. Add the same to FSP2.0 driver.
FSP1.1 driver had the same implementation hence copied stage_cache.c.
The SoC code should implement the smm_subregion to provide
the base and size of the caching region within SMM. The fsp/memmap.h
provides the prototype and we will reuse the same from FPS 1.1.
Change-Id: I4412a710391dc0cee044b96403c50260c3534e6f
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16312
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
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>
|
|
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>
|
|
Add SMBIOS memory GUID and functions to retrieve HOB.
BUG=chrome-os-partner:55505
TEST='dmidecode -t 17' and 'mosys -k memory spd print all'
Change-Id: Ie7e2239bb691c748d9fd852c3dc8cdc05243b164
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/16245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Instead of assuming SPI backing use a region_device to
abstract away the underlying storage mechanism.
BUG=chrome-os-partner:55932
Change-Id: I6b0f5a7e9bea8833fb1bca87e02abefab63acec3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16204
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
On many x86 platforms the boot device is SPI which is memory
mapped. However, in order to write to the boot device one needs
to use the SPI api. Therefore, provide a common implementation
of boot_device_rw() which has no mmap() functionality. It only
reads, writes, and erases. This will be used in the existing
infrastructure but in a SPI agnostic way.
Two options are added:
1. BOOT_DEVICE_SPI_FLASH_RW_NOMMAP
2. BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY
The former is auto-selected when COMMON_CBFS_SPI_WRAPPER is not
selected. The latter can be used to include the implementation
in the early stages such as bootblock, verstage, and romstage.
BUG=chrome-os-partner:56151
Change-Id: I2aa75f88409309e3f9b9bd79b52d27c0061139c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16200
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It shouldn't matter if COMMON_CBFS_SPI_WRAPPER is selected to
include the SPI flash support in all stages. Therefore, include
the SPI flash support files in all the stages. While there include
the same set of files for all stages. They were out of sync for
some reason.
BUG=chrome-os-partner:56151
Change-Id: I933335104203315cbbcf965185a7c176974e6356
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16198
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The spi_flash_probe() routine was setting a global varible
unconditonally regardless if the probe was for the boot device
or even if the boot devcie was flash. Moreover, there's no need
to report the SPI information if the boot device isn't even SPI.
Lastly, it's possible that the boot device is a SPI flash, but
the platform may never probe (selecting SPI_FLASH) for the
actual device connected. In that situation don't fill anything
in as no correct information is known.
BUG=chrome-os-partner:56151
Change-Id: Ib0eba601df4d77bede313c358c92b0536355bbd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16197
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Provide the RW boot device operations for the common cbfs
SPI wrapper. The RW region_device is the same as the read-only
one. As noted in the boot_device_rw() introduction patch the
mmap() support should not be used in conjuction with writing
as that results in incoherent operations. That's fine as the
current mmap() support is only used in the cbfs layer which
does not support writing, i.e. no cbfs regions would be
written to with any previous or outstanding mmap() calls.
BUG=chrome-os-partner:56151
Change-Id: I7cc7309a68ad23b30208ac961b1999a79626b307
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16199
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Indicate to the build system that a platform provides support
for a writable boot device. The following will provide the
necessary support:
COMMON_CBFS_SPI_WRAPPER users
soc/intel/apollolake
soc/intel/baytrail
soc/intel/braswell
soc/intel/broadwell
soc/intel/skylake
The SPI_FLASH option is auto-selected if the platform provides
write supoprt for the boot device and SPI flash is the boot
device.
Other platforms may provide similar support, but they do that
in a device specific manner such as selecting SPI_FLASH
explicitly. This provides clearance against build failures
where chipsets don't provide SPI API implementations even
though the platform may use a SPI flash to boot.
BUG=chrome-os-partner:56151
Change-Id: If78160f231c8312a313f9b9753607d044345d274
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16211
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The common boot device spi implementation is very much
specific to SPI flash. As such it should be moved into
that subdirectory. It's still a high-level option but
it correctly depends on BOOT_DEVICE_SPI_FLASH. Additionally
that allows the auto-selection of SPI_FLASH by a platform
selecting COMMON_CBFS_SPI_WRAPPER which allows for culling
of SPI_FLASH selections everywhere.
BUG=chrome-os-partner:56151
Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fixed "intierface" typo.
Change-Id: I65f0156ee059a8bed96c900ca3da3a06f45901e8
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-on: https://review.coreboot.org/16252
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
Provide a default value of 0 in drivers/spi as there weren't
default values aside from specific mainboards and arch/x86.
Remove any default 0 values while noting to keep the option's
default to 0.
BUG=chrome-os-partner:56151
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Almost all boards and chipsets within the codebase assume or
use SPI flash as the boot device. Therefore, provide an option
for the boards/chipsets which don't currently support SPI flash
as the boot device. The default is to assume SPI flash is the
boot device unless otherwise instructed. This falls in line
with the current assumptions, but it also allows one to
differentiate a platform desiring SPI flash support while it not
being the actual boot device.
One thing to note is that while google/daisy does boot with SPI
flash part no SPI API interfaces were ever implemented. Therefore,
mark that board as not having a SPI boot device.
BUG=chrome-os-partner:56151
Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16191
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This reverts commit a83bbf58541cf41ea7a97dedbc8c02dffa59e86d.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
All flash drivers are automatically included in the build unless
COMMON_CBFS_SPI_WRAPPER was selected. However, there are cases
where these drivers are unnecessary such as certain intel platforms
where spi controller uses hardware sequencing without any ability
to manually probe the device. Therefore, provide an option that the
SoC can set the default value for. The COMMON_CBFS_SPI_WRAPPER
option is still honored by not including all drivers when that
is selected.
BUG=chrome-os-partner:56151
Change-Id: Ie9aa447da450f7c8717545f05cff800139a9e2dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16187
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Provide more informative messages when CONFIG_ELOG_DEBUG is enabled
as well as more informative error messages in the case of
elog_scan_flash() failing. In the sync path the in-memory buffer is
dumped in before the contents are read back from the non-volatile
backing store and dumped again if the subsequent parsing fails.
BUG=chrome-os-partner:55932
Change-Id: I716adfb246ef6fbefc0de89cd94b3c1310468896
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16184
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Don't verify HOB list pointer or HOBs when FSP returns a reset request.
BRANCH=none
BUG=chrome-os-partner:56159
TEST=Build and run on Galileo Gen2.
Change-Id: I6382f5ff92092623955806ebff340608c4ee156a
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16162
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It cooperates better with the file sorting heuristic.
Change-Id: I1c071243720352970dd2c4c2afed12451f91dcaa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16141
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add fsp_write_line function which may be called by FSP to output debug
serial data to the console.
TEST=Build and run on Galileo Gen2
Change-Id: If7bfcea1af82209dcdc5a9f9f2d9334842c1595e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add fsp_write_line function which may be called by FSP to output debug
serial data to the console.
TEST=Build and run on Galileo Gen2
Change-Id: Ib01aef448798e47ac613b38eb20bf25537b9221f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16128
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Commit 0d9cd92e (chromeos: Clean up elog handling) removed the
individual elog_init() calls from mainboards that did them and automated
adding certain events through the boot state machine. Unfortunately,
the new code would sometimes not log any specific event at all, and
thereby also never call elog_init() (through elog_add_event()) which
adds the "System boot" event.
We can assume that any board that configures the eventlog at all
actually wants to use it, so let's just add another call to elog_init()
to the boot state machine so we can ensure it gets called at least once.
BRANCH=None
BUG=chrome-os-partner:56001
TEST=Booted Kevin, confirmed that eventlog code runs again.
Change-Id: Ibe7bfc94b3e3d11ba881399a39f9915991c89d8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16118
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Instead of relying on global state to determine if an error
occurred provide the ability to know if an add or shrink
operation is successful. Now the call chains report the
error back up the stack and out to the callers.
BUG=chrome-os-partner:55932
Change-Id: Id4ed4d93e331f1bf16e038df69ef067446d00102
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16104
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Don't conditionally compile parts of the code. The unused pieces
get culled by the linker, and the #if's just clutter things up.
BUG=chrome-os-partner:55932
Change-Id: Ic18b2deb0cfef7167c05f0a641eae2f4cdc848ee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There were checks against global variables trying to determine
failing cases of elog_find_flash(). Instead move the checks
into elog_find_flash() and return value indicating failure.
A minimum 4KiB check was added to ensure the eventlog is at
least that size which makes the heuristic checks cleaner.
BUG=chrome-os-partner:55932
Change-Id: I4d9d13148555e05d4f217a10f995831a0e437fc3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16101
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There were 3 variables indicating the state of the event log
region. However, there's no need to keep track of those
individually. The only thing required is to know is if
elog_scan_flash() failed. There's no other tracking required
beyond that.
BUG=chrome-os-partner:55932
Change-Id: I88ad32091d3c37966a2ac6272f8ad95bcc8c4270
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16100
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There were multiple paths where writes and erases of the flash
were being done. Instead provide a single place for synchronizing
the non-volatile storage from the mirrored event log. This
synchronization point resides as the very last thing done when
adding an event to the log. The shrinking check happens before
committing the event to non-volatile storage so there's no need
to attempt a shrink in elog_init() because any previous events
committed already honored the full threshold.
BUG=chrome-os-partner:55932
Change-Id: Iaec9480eb3116fdc2f823c25d028a4cfb65a6eaf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16099
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Instead of treating offsets relative to after the header make
the offsets relative to the in-memory mirror buffer. This
simplifies the logic in that all offsets are treated the same.
It also allows one to remove a global variable.
BUG=chrome-os-partner:55932
Change-Id: I42491e05755d414562b02b6f9ae47f5c357d2f8a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16098
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
A region_device can be used to represent the in-memory mirror
of the event log. The region_device infrastructure has builtin
bounds checking so there's no need to duplicate that. In addition,
it allows for removing much of the math juggling for the buffer
size, etc.
BUG=chrome-os-partner:55932
Change-Id: Ic7fe9466019640b449257c5905ed919ac522bb58
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16097
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There's only 2 users of checking if the event buffer is cleared
to the EOL value. Each were passing pointers of the in-memory
mirror while also doing calculations for the size to check. Since
the in-memory mirror is one big buffer the only thing required
to know is the offset to start checking from. The check is always
done through the end of the buffer.
BUG=chrome-os-partner:55932
Change-Id: Icd4a7edc74407d6578fc93e9eb533abd3aa17277
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16096
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of taking pointers and back-calculating the
proper offset perform writes in terms of the offsets
within the elog region in flash.
BUG=chrome-os-partner:55932
Change-Id: I5fd65423f5a6e03825c788bc36417f509b58f64d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16095
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
The elog_flash_erase() was only called to erase the entire
elog region in flash. Therefore, drop the parameters and
perform the full erase.
BUG=chrome-os-partner:55932
Change-Id: I6590347ae60d407bc0df141e9196eb70532f8585
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16094
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There was a check against the next event offset against
the shrink size in elog_shrink(). However, all calls
to elog_shrink() were conditionalized on the next
event offset exceeding the full threshold. The shrink
size is set to the minimum of the full threshold and
a percentage of the elog region size. Therefore, it's
impossible for the next event offset to be less than
the shrink size because full threshold is always greater
than or equal to the shrink size.
BUG=chrome-os-partner:55932
Change-Id: Ie6ff106f1c53c15aa36a82223a235a7ac97fd8c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16093
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
For the elog shrink case we log the number of bytes shrunk
from the event log. However, when clearing the log the
size recorded was the entire region size including the header
as well as the event region space. To be more consistent
mark the clearing event with the number of bytes actually
cleared out (excluding the header size).
BUG=chrome-os-partner:55932
Change-Id: I7c33da97bd29a90bfe975b1c6f148f181016f13f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16092
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
