| Age | Commit message (Collapse) | Author |
|---|
|
This symbol is not defined.
Change-Id: I2b0a3fca82d85962fc882f237b70702cab0400db
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/13647
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
See discussion on https://review.coreboot.org/13600 and
https://review.coreboot.org/13601
Change-Id: Ia8274b0b296d6b398f75c0d91a6fded4c5f57e10
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13643
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
These files aren't updated (or updatable), and as such don't need to be
copied to the RW sections.
Change-Id: Ie78936792ad651fbf8500fc7e34f0899e33a904c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds a new kconfig option that will back up the VBNV data
from CMOS to flash, and restore it if the CMOS data is invalid
during boot.
This allows special flags to not get lost when power is lost,
RTC reset is triggered, or CMOS is corrupted.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell:
1-boot and run "enable_dev_usb_boot"
2-reboot and check that it is enabled with crossystem
3-run "mosys nvram clear"
4-reboot and check that it is still enabled
Change-Id: I38103d100117da34471734a6dd31eb7058735c12
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8a356e616c6885d5ae3b776691929675d48a28f9
Original-Change-Id: I06e7ddff7b272e579c704914a0cf8cc14d6994e8
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324122
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain platforms query the recovery mode switch more than just within
vboot during the boot flow. Therefore, it's important that the first call to
get_recovery_mode_switch() is consistent through memory training because
certain platforms use the recovery mode switch to take different action
for memory training. Therefore, defer the clearing of the rec mode
switch to a place when it's known that memory is up and online.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Three finger salute is honored on chell by retraining memory.
Change-Id: I26ea51de7ffa2fe75b9ef1401fe92f9aec2b4567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b0de9369242e50c7ff3b164cf1ced0642c7b087
Original-Change-Id: Ia7709c7346d1222e314bf3ac7e4335a63e9a5144
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325120
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This modifies the vbnv_flash driver to make it safe for use
in cache-as-ram by handling the global variables safely.
To make this cleaner all of the variables were moved into
one structure and referenced from there.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell using following patches to
test backup and restore of vbnv_cmos into flash
Change-Id: I3a17fa51cfd754455502ac2e5f181dae35967f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48876561fa4fb61e1ec8f92596c5610d97135201
Original-Change-Id: Id9fda8467edcc55e5ed760ddab197ab97d1f3d25
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13599
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The VBNV region size is determined by vboot and is not really
configurable. Only the CMOS implementation defined this config
variable so switch it to use VBNV_BLOCK_SIZE defined by vboot
in vbnv_layout.h instead.
This requires updating the broadwell/skylake cmos reset functions
to use the right constant.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d
Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324520
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a wrapper around the vbnv implementations and call into the different
backend functions from there. Also move some of the common functions to
the common code and simplify the backend drivers. This will allow some
of the code to be re-used so the CMOS backend can backup the data into
the flash backend.
One side effect of this is that the cache of VBNV was removed from CMOS
and EC backends and moved into the VBNV wrapper, but the flash backend
also still has a separate cache because it has more state and complexity
in the implementation. The wrapper cached data is not used for normal
vbnv_read/vbnv_write because some callers need the ability to force a
write if the backend storage is cleared (i.e. CMOS clear).
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4d2e0e99af7e8a44aec77ad9991507401babcca6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c30f60434a64f6c0eb9ede45d48ddafff19dd24f
Original-Change-Id: Ia97f6607c5ad837b9aa10b45211137221ccb93a0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13597
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Vboot keeps track of the size of the hashed region in each
RW slot. While that size was being used to calculate the hash
it wasn't being honored in restricting the access within the
FMAP region for that RW slot. To alleviate that create a sub
region that covers the hashed data for the region in which
we boot from while performing CBFS accesses.
BUG=chrome-os-partner:49764
BUG=chromium:445938
BRANCH=glados
TEST=Built and booted chell with cbfstool and dev-util patches.
Change-Id: I1a4f45573a6eb8d53a63bc4b2453592664c4f78b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ac9e84af5b632e5735736d505bb2ca6dba4ce28
Original-Change-Id: Idca946926f5cfd2c87c4a740ad2108010b6b6973
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324093
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When vboot_handoff_flag() is called in the bootblock or a separate
verstage there's no memory nor the possibility of dram coming online.
Therefore, don't bother to attempt call cbmem_find().
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell with separate verstage which pulls in vboot_common.c
dependency. No more linking errors w/ cbmem_find() not being
around.
Change-Id: I494c93adc1c00459fdfaa8ce535c6b4c884ed0fb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 414ce6aeaff657dc90289b25e5c883562189b154
Original-Change-Id: I8a5f2d154026ce794a70e7ec38883fa3c28fb6e7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324070
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13580
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Sometimes it's necessary for the platform to perform clean up
tasks prior to reboot when employing vboot. For example, x86 systems
that resume and do vboot verification may need to clear their
sleep control register prior to doing a cold reset so that the
next boot doesn't appear to be a resume. Allow that hook by
introducing vboot_platform_prepare_reboot().
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Ensure vboot_platform_prepare_reboot() called from vboot_reboot().
Change-Id: I622c9181d9fa3048204e3df3223d5dd4b458abca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f31ffc40bde002dec398fd4dd9d2ee9d65df0d7b
Original-Change-Id: I97318cec34494a7fc4b1ecf2cb22715d20e730ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323501
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13575
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This requires payload integration somewhere to be useful, because
without that, adding it will (hopefully) break the signature.
Change-Id: I67b8267e5040e26353df02d258e92a0610e19a52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Use the flags to preset the GBB flags field. The Kconfig defaults are
chosen for a "developer" configuration.
Change-Id: Ifcc05aab10b92a2fc201b663df5ea47f92439a3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The GBB contains hardware-specific data plus some configuration. The
latter isn't supported by this change yet and will come later.
The fields that are supported (hardware ID, bmpfv, vboot keys) are
configurable through Kconfig and point to Chrome OS-style default (eg.
developer keys).
While adding vboot keys, the two keys used to sign RW regions are also
added to Kconfig, even if not yet used.
Change-Id: Icfba6061ca83182df560cd36052fbb257826d4b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Just rename the two scripts that are in the src/ tree to give them
a .sh extension. Since we generally expect files in the src directory
to be source files, this allows to identify these as scripts easily.
Change-Id: I0ab20a083880370164488d37a752ba2d5a192fdc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch adds a check to the VPD parsing code to avoid reading the
whole thing if the first byte ('type' of the first VPD entry) is 0x00
or 0xff. These values match the TERMINATOR and IMPLICIT_TERMINATOR types
which should never occur as the first entry, so this usually means that
the VPD FMAP section has simply never been initialized correctly. This
early abort avoids wasting time to read the whole section from SPI flash
(which we'd otherwise have to since we're not going to find a Google VPD
2.0 header either).
BRANCH=None
BUG=None
TEST=Booted Oak, confirmed that VPD read times dropped from 100ms to
1.5ms.
Change-Id: I9fc473e06440aef4e1023238fb9e53d45097ee9d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20a726237e03941ad626a6146700170a45ee7720
Original-Change-Id: I09bfec3c24d24214fa4e9180878b58d00454f399
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322897
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/13467
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch adds three timestamps to coreboot and the cbmem utility that
track the time required to read in the Chrome OS Vital Product Data
(VPD) blocks (RO and RW). It's useful to account for these like all
other large flash accesses, since their size is variable.
BRANCH=None
BUG=None
TEST=Booted Oak, found my weird 100ms gap at the start of ramstage
properly accounted for.
Change-Id: I2024ed4f7d5e5ae81df9ab5293547cb5a10ff5e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b97288b5ac67ada56e2ee7b181b28341d54b7234
Original-Change-Id: Ie69c1a4ddb6bd3f1094b3880201d53f1b5373aef
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322831
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/13139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add flag handling for CONFIG_VBOOT_EC_SLOW_UPDATE to indicate
to vboot that it should show the "critical update" screen during
software sync for EC+PD.
In order to make this work on x86 where we do not run graphics
init in the normal path add handling for CONFIG_VBOOT_OPROM_MATTERS
and indicate to vboot when the option rom has been loaded.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Build and boot on chell in normal mode with an EC update payload
and ensure that it reboots to enable graphics, shows the "critical
update" screen, and then reboots to disable graphics init again.
Change-Id: I5ca46457798a22e9b08aa2febfec05b01aa788f9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6a1bb8572c3485f64b9f3e759288321b44184e66
Original-Change-Id: I9f66caaac57bb9f05bc6c405814469ef7ddf4d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322781
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13073
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Setup an initial rule to make use of the updatable CBFS regions in fmap.
Change-Id: I1fe1c6e7574854b735760c85590da6e297f6e687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13060
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Implement wifi_regulatory_domain function by getting country code from
VPD
Original-Reviewed-on: https://chromium-review.googlesource.com/314385
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Hannah Williams <hannah.williams@intel.com>
Change-Id: Ia6a24df110a3860d404d345571007ae8965e9564
Signed-off-by: fdurairx <felixx.durairaj@intel.com>
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/12743
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
CB used to clear recovery status towards romstage end after FSP
memory init. Later inside FSP silicon init due to HSIO CRC mismatch
it will request for an additional reset.On next boot system resume
in dev mode rather than recovery because lost its original state
due to FSP silicon init reset.
Hence an additional 1 reset require to identify original state.
With this patch, we will get future platform reset info during romstage
and restore back recovery request flag so, in next boot CB can maintain
its original status and avoid 1 extra reboot.
BUG=chrome-os-partner:43517
BRANCH=none
TEST= build and booted Kunimitsu and tested RO mode
Change-Id: Ibf86ff2b140cd9ad259eb39987d78177535cd975
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 40ddc21a97b318510116b7d5c4314380778a40f7
Original-Change-Id: Ia52835f87ef580317e91931aee5dd0119dea8111
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302257
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12975
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Provide a common routine to hash the contents of a cbfs
region. The cbfs region is hashed in the following order:
1. potential cbfs header at offset 0
2. potential cbfs header retlative offset at cbfs size - 4
3. For each file the metadata of the file.
4. For each non-empty file the data of the file.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Utilized in chromeos cros_bundle_firmware as well as at
runtime during vboot verification on glados.
Change-Id: Ie1e5db5b8a80d9465e88d3f69f5367d887bdf73f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12786
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This file became obsolete when FMAP code moved to src/lib/ and is no
longer built by any Makefile. Let's remove it to avoid confusing people.
Change-Id: I55639af28f9f3d4c4cb0429b805e3f120ecc374e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12753
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
ELOG requires SPI_FLASH, so don't bother selecting if if SPI_FLASH isn't
available.
Change-Id: I080ac47e74aba820c94409d4913647abee215076
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12661
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
verstage, romstage, and payload can be added through infrastructure now.
Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Put dependecies on CHROMEOS's selection of the Kconfig symbols
TPM_INIT_FAILURE_IS_FATAL and SKIP_TPM_STARTUP_ON_NORMAL_BOOT to match
the dependencies on those symbols where they are defined in
src/drivers/pc80/tpm/Kconfig
The file that uses these only gets built in if CONFIG_LPC_TPM is
selected selected.
The warnings were:
warning: (CHROMEOS) selects TPM_INIT_FAILURE_IS_FATAL which has unmet
direct dependencies (PC80_SYSTEM && LPC_TPM)
warning: (CHROMEOS) selects SKIP_TPM_STARTUP_ON_NORMAL_BOOT which has
unmet direct dependencies (PC80_SYSTEM && LPC_TPM)
Change-Id: I7af00c79050bf511758bf29e3d57f6ff34d2a296
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12497
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are few drawbacks reading VPD from SPI flash in user land, including
"lack of firmware level authority" and "slow reading speed".
Since for many platforms we are already reading VPD in firmware (for
example MAC and serial number), caching the VPD data in CBMEM should
will speed up and simplify user land VPD processing without adding
performance cost.
A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing
raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in
Coreboot tables.
BRANCH=smaug
BUG=chrome-os-partner:39945
TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully.
[pg: lots of changes to make it work with what happened in upstream
since 2013]
Change-Id: If8629ac002d52abed7b480d3d06298665613edbf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45
Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/285031
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12453
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
While migrating from vboot1 to vboot2, the tpm_init was moved out of
vboot library and implemented in coreboot. However, while doing this,
the initial factory flow was missed.
We need to ensure following flow for tpm_init:
1. Perform tpm_init
2. If tpm_init fails, set secdata_context flag to indicate to vboot
that tpm needs reboot.
3. Call vb2_api_phase1
4. If vb2_api_phase1 returns error code saying boot into recovery,
continue booting into recovery. For all other error codes, save
context if required and reboot.
[pg: everything but step 2 was already done, so this upstream commit is
quite minimal]
CQ-DEPEND=CL:300572
BUG=chrome-os-partner:45462
BRANCH=None
TEST=Verified behavior on smaug. Steps to test:
1. Reboot into recovery
2. tpmc clear
3. Reboot device
Expected Behavior: Device should reboot after Enabling TPM. Should not
enter recovery
Confirmed that the device behaves as expected.
Change-Id: I72f08d583b744bd77accadd06958c61ade298dfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85ac93137f3cfb28668dcfa18dfc773bf910d44e
Original-Change-Id: I38ab9b9d6c2a718ccc8641377508ffc93fef2ba1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/300570
Original-Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12205
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I69a50c71d93ab311c1f7d4cfcd7d454ca1189586
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d9679b02f6d21ed903bb02e107badb0fbf7da46c
Original-Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/307946
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/12199
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We need to special-case filling out the vboot structures when
we use CBFS instead of vboot's custom indexed format, otherwise
(due to the way the CBFS header looks), it will try to write several
million entries.
Change-Id: Ie1289d4a19060bac48089ff70e5cfc04a2de373f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When a separate verstage is employed the verstage file
was just being added through the cbfs-files mechanism.
However, that doesn't allow one to specify other flags
that aren't supported that an architecture may require.
The x86 architecture is one of those entities in that
it needs its verstage to be XIP. To that end provide
a mechanism for adding verstage with options.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using his mechansim on x86.
Change-Id: Iaba053a55a4d84d8455026e7d6fa548744edaa28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11819
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In order to support x86 verstage proper the work buffer
needs to live in cache-as-ram. However, after cache-as-ram
is torn down one still needs the verification results to
know which slot was selected. Though the platforms with
a dedicated SRAM can just use the work buffer in SRAM, the
x86 cache-as-ram platforms need a place to stash the
results. For that situation cbmem is employed. This works
because when cbmem is initialized cache-as-ram is still
enabled. The VBOOT_DYNAMIC_WORK_BUFFER case assumes
verified boot doesn't start until after cbmem is up. That
doesn't change, but it's a goal to get rid of that option
entirely once all other x86 platforms are moved over to
pre-romstage vboot.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with pre-romstage verification
as well as VBOOT_DYNAMIC_WORK_BUFFER case.
Change-Id: I7eacd0edb2b6ca52b59b74075d17c00b50676d4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11821
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For the purpose of isolating the work buffer logic
the surface area of the API was slimmed down. The
vb2_working_data structure is no longer exposed,
and the function signatures are updated accordingly.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If64184a79e9571ee8ef9822cfce1eda20fceee00
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11818
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Up to now, the multi-CBFS code path merely looked up files in the "boot
ro" image (ie. the default), disregarding the specified fmap region to
use for CBFS.
The code still relies on the master header being around, which on the
upside allows it to skip an offset at the beginning of the region (eg.
for ARM bootblocks).
This will change later (both the reliance on the master header and the
presence of the bootblock like this).
Change-Id: Ib2fc03eac8add59fc90b4e601f6dfa488257b326
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Certain chipsets provide their own main symbol for verstage.
Therefore, it's necessary to know this so that those chipsets
can leverage the common verstage flow.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan using this option.
Change-Id: If80784aa47b27f0ad286babcf0f42ce198b929e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
vboot_handoff_flag was duplicating the logic to grab the handoff info, that is
already made available with vboot_get_handoff_info.
This uses vboot_get_handoff_info in vboot_handoff_flag instead.
Change-Id: I28f1decce98f988f90c446a3a0dbe7409d714527
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11498
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The vboot verification in a stage proper is unified
replacing duplicate code in the tegra SoC code. The
original verstage.c file is renamed to reflect its
real purpose. The support for a single verstage flow
is added to the vboot2 directory proper.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I14593e1fc69a1654fa27b512eb4b612395b94ce5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This moves a few vboot-prefixed functions that were defined in chromeos.c to
vboot_common.c, since those are only relevant to vboot and depend on the vboot
handoff data. This allows more separation between CONFIG_CHROMEOS and what
CONFIG_CHROMEOS selects, so that each separate option (such as
CONFIG_VBOOT_VERIFY_FIRMWARE) can be enabled separately.
Thus, the actual definitions of these functions will only be declared when
CONFIG_VBOOT_VERIFY_FIRMWARE is set, so the check before calling
vboot_skip_display_init in bootmode was also adapted.
Change-Id: I52f8a408645566dac0a2100e819c8ed5d3d88ea5
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11497
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Currently, erase operation only works if the region is sector-aligned.
These asserts ensure we can erase the region when it's all used up.
Erase operation can be updated to handle unaligned erases by read,
update, write-back cycle. However, these asserts will still remain useful
in case the adjacent region contains critical data and mis-updating it
can cause a critical failure.
Additionaly we should write a FAFT test but it's more reliable to catch
it here since FAFT can fail in many ways.
BUG=none
BRANCH=master
TEST=tested on samus using misaligned nvram region
Change-Id: I3add4671ed354d9763e21bf96616c8aeca0cb777
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fc001a4d3446cf96b76367dde492c3453aa948c6
Original-Change-Id: Ib4df8f620bf7531b345364fa4c3e274aba09f677
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297801
Reviewed-on: http://review.coreboot.org/11654
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With VIRTUAL_DEV_SWITCH moved under 'config CHROMEOS' in all of the
mainboards, this is no longer needed.
Change-Id: I5fbea17969f6b0c3b8a5dcd519ab9d36eb2ad6f1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11337
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
One may prefer to include vboot from another directory than 3rdparty for
convenience. This is especially the case in Libreboot, where 3rdparty is not
checked out at all.
Change-Id: I13167eb604a777a2ba87c3567f134ef3ff9610e4
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11116
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
$(obj) might be defined either as a relative or an absolute path. Thus, it has
to be filtered out before adding $(top) to it (in case of an absolute path) when
building vboot. It is then provided separately in CFLAGS (as an absolute path).
In addition, VB2_LIB inherits $(obj), so it might also already be an absolute
path, and prefixing $(top) to it doesn't apply. Thus, the absolute path to it
should be passed to the vboot make command.
Change-Id: I13e893ebdf22c4513ee40d9331a30ac7de8f9788
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
TEST=built for samus and veyron_jerry
Change-Id: I7173f46d2ed2e323bff227a484c32c4bb6f6c828
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/11028
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Assume that it's 64 byte.
Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10919
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This can be a problem with freshly updated devices that are periodically
powered on while closed (as explained in the bug report).
In this case, just don't count down. In case of actual errors (where we
want the system to fall back to the old code), this now means that the
retries have to happen with the lid open.
Bump vboot's submodule revision for the vboot-side support of this.
BUG=chromium:446945
TEST=to test the OS update side, follow the test protocol in
https://code.google.com/p/chromium/issues/detail?id=446945#c43
With a servo, it can be sped up using the EC console interface to start
the closed system - no need to wait 60min and plugging in power to get
to that state.
Change-Id: I0e39aadc52195fe53ee4a29a828ed9a40d28f5e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The many different places to put vboot verification in can be confusing.
Instead of using libverstage (which isn't enough since those functions are
sometimes called outside that, too), mention all stages where it can resides
explicitly.
Change-Id: I9360face822ada7018a1cfdfced8da29b347cbb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10722
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That way they're available wherever the verstage code ends up, bootblock,
verstage or romstage.
Change-Id: I6e59a40761f95a98d96a9b72e3bbcc59caae9b1a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not all devices have a lid switch, so we need to state this
somehow. Since the alternative would be to extend get_lid_switch()'s
semantics to become a tri-state (open, closed, N/A), do this
through Kconfig.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Icc50f72535f256051a59925a178fb27b2e8f7e55
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d20a1d1a22d64546a5d8761b18ab29732ec0b848
Original-Change-Id: Ie8ac401fbaad5b5a9f1dec2b67847c81f4cc94aa
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273850
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Iaadbd52d948000d1ed46865b83bdb0f4926ca429
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10677
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of calling the init function to clear out vboot2 data structures in
multiple places, move the function and call close to verstage_main().
Change-Id: If42e18a8e4581f22f7a7aced70ccbe3188bb0cd5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10701
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Icc3cf64f259d4ebd7900ad91163276774e5422ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Otherwise it'll determine some offsets from uninitialized data and hilarity
ensues.
Change-Id: I6a671987857cfd3f3cd6078aebd13dd09fc79020
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
VPD strings are not null terminated, so we can't use strcpy
on them in cros_vpd_gets.
BUG=none
BRANCH=none
TEST=add serial_number followed by cam_calib_data to VPD on smaug;
make sure that smaug boots and serial number matches exactly (no garbage)
Change-Id: Id72885517b3d0b1934ba329c1ef0d89a67bd2bb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 56bbe6688b11043360a046a250d1ea93db4d9f0e
Original-Change-Id: I811dfc2f0830a91410eb69961a6565080ff78267
Original-Signed-off-by: Stephen Barber <smbarber@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/280836
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-on: http://review.coreboot.org/10627
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Some patches landed that didn't introduce the Kconfig
options for additional firmware components. Add them.
Change-Id: I0a0b7f0291389d126a7c491f710618a278cfb5d7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With addition of bl31 and trusty, we need to increase the number of
parsed fw components in vboot to 6.
CQ-DEPEND=CL:273866
BUG=chrome-os-partner:40713
BRANCH=None
TEST=Compiles successfully and vboot finds trusty and bl31.
Change-Id: I3597e98370bbaef4d2e563c868eed59b2e18adca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ff87fdbc7779e6ee410905d1618281411b38a93
Original-Change-Id: Ia403f895b50cc5349bb700d01f62e13c679f68f4
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273865
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Timestamps should not be forced on by a subset of chipsets.
However, they are a requirement on Chrome OS platforms, so
have CONFIG_CHROMEOS select it.
Change-Id: I408c6b17aa8721a3abec69020084174e414a8940
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/10357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This code is not specific to ChromeOS and is useful outside of it.
Like with small modifications it can be used to disable TPM altogether.
Change-Id: I8c6baf0a1f7c67141f30101a132ea039b0d09819
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10269
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Now that vboot is using offsets for everything remove the
pass through vboot_get_region() and use region_devices
as first class citizens.
Change-Id: I1a86f3725e5bce38e6ca31e9641b1a8f4ac50e96
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10225
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Because of the fmap API returning pointers to represent
regions within the boot device a vboot_region structure
was used to track the case where offsets could be pointers
on x86 but not on !x86. Normalize this tracking to use
offsets only as it provides consistency in the code.
Change-Id: I63c08b31ace3bd0e66ebc17e308f87eb5f857c86
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
The vboot_context.h file hasn't been used since commit
6d65f796db. Remove it.
Change-Id: I57a6c619c6e1f57be6963da2954329bc9c007dd8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10223
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When we are taking the recovery path there is no slot or
components to fill out.
Change-Id: Ic97a247629365ef54a340c4398cb7491935edc11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10198
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There was no indication of verstage being loaded. Provide this
output so that one can follow the flow from console messages.
Change-Id: I67ae6bb334608fe10a4a12fe690498afaf6b8366
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10195
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The support for RELOCATABLE_RAMSTAGE was accidentally omitted in
the vboot loader. Add said support.
Change-Id: I569918823253c33f698acefd6a619133543c7aef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10184
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The vboot library currently relies on link-time known
address and sizes of the work buffer. Not all platforms
can provide such semantics. Therefore, add an option
to use cbmem for the work buffer. This implies such platforms
can only do verification of the firmware after main memory
has been initialized.
Change-Id: If0b0f6b2a187b5c1fb56af08b6cb384a935be096
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10157
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of using the symbols directly provide a size
function to provide symmetry between getting the work
data and size. It also allows for an abstraction where
the linker symbols may not be the only source of this
information.
Change-Id: I4568064a0050d118c3544ab1ea59a08eb0bad8e4
Signed-off-by: Aaron Durbi <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
vboot_verify_firmware() was only defined to ease upstreaming.
It was only an empty inline as it is so remove it. Additionally,
vboot2 does not require romstage_handoff so there's no need in
adding it for the nyan boards.
Change-Id: I4d84ac9fb60c756cf10742f26503f7f11af5f57b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10155
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As previously done the vboot loader can be optionally
inserted in the stage loading logic in order to
decide the source of each stage. This current patch
allows for verstage to be loaded and interrogated
for the source of all subsequent stages. Additionally,
it's also possible to build this logic directly into
one of the additional stages.
Note that this patch does not allow x86 to work.
Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10154
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This make it pass through -fno-stack-protector, and also uses
libverstage fields consistently.
verstage is for 'stage' stuff, libverstage for all the vboot logic.
Change-Id: I3032e072414bed52effd2dc5057896781ad562c6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10174
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In order to allow easier setting of variables without
changing mainboards and/or chipset Kconfig files allow
the vboot options to be selected by the user.
Change-Id: I6e995eb209b4cd63c73ef679d0c5699759d129f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The VB_FIRMWARE_ARCH variable was not being set correctly,
and the VBOOT_STARTS_IN_BOOTBLOCK Kconfig option was not properly
prefixed with CONFIG_. Correct both of these oversights.
Change-Id: Id27974c285d2629bd47b90b6a93aca1ec8a76512
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10152
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Somewhere along the development path the following
vboot functions were dropped:
int vboot_enable_developer(void)
int vboot_enable_recovery(void)
Add them back, but also refactor the flag extraction
so as not duplicate all that same logic.
Change-Id: Id58f3b99f29caeff98b2d3111cfa28241d15b54f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10151
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I9cbdf06f4d0956b5374915f8af7501c6f75b4687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10113
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This allows providing a verified boot mechanism in the
default distribution, as well as reusing vboot code like
its crypto primitives for reasonably secure checksums over
CBFS files.
Change-Id: I729b249776b2bf7aa4b2f69bb18ec655b9b08d90
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
verstage still needs to be built with its flags.
Change-Id: I125e4be283d3838fc7ce6587bf9996731540d517
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10098
Tested-by: build bot (Jenkins)
|
|
The name is more consistent with what we have elsewhere,
and the callsite didn't build at all (with vboot enabled)
Change-Id: I3576f3b8f737d360f68b67b6ce1683199948776d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10096
Tested-by: build bot (Jenkins)
|
|
It's not used at all.
Change-Id: I97bf02a9277f6ca348443c6886f77b4dfc70da78
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10095
Tested-by: build bot (Jenkins)
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Idf99c1491386578ac2471ca5cc8a153d2b5225e4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10044
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Builds with CHROMEOS fail due to missing includes.
Change-Id: I8c88bca8f8cc3247d3f3311777f794c4fdfee3c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10029
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The ChromeOS machines employing vboot verfication require
different combinations of support:
1. When vboot verification starts.
2. Is the vboot code a separate stage or program?
3. If a separate stage, does the that vboot program (verstage) return
to the stage that loaded the verstage?
For the above, #1 is dependent on when to load/run vboot logic which
is orthogonal to #2. However, #3 is dependent on #2. The logic
to act on the combinations follows in subsequent patches.
Change-Id: I39ef7a7c2858e7de43aa99c38121e85a57f1f2f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10024
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With vboot1 out of the way place all the associated Kconfig
options in vboot2's Kconfig file (excluding main vboot verify
option). More options will be added to accomodate vboot's various
combinations of use cases.
Change-Id: I17b06d741a36a5e2fefb2757651a61bfed61ae1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10023
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This file was moved previously to get it out of the way
for easier merging from the chromium repo. It's not used
currently so remove it.
Change-Id: I8e691623f29ac2218b83bc46f5b4a348e0e1b3ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9960
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There's no need to have the VBOOT2_VERIFY_FIRMWARE
distinction because it's the only game in town.
Change-Id: I82aab665934c27829e1a04115bf499ae527a91aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In preparation for moving to vboot2 for all verified
boot paths bring over Kconfig options to the common
area from vboot1. Also remove vboot1 directory entirely.
Change-Id: Iccc4b570216f834886618f0ba5f2e1dd6c01db4b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9957
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
