It's standard practice in vboot that the FWID consists of
<board_name>.<version_number> (e.g. Google_Kevin.8785.57.0). In fact,
some tools rely on this and cut the string at the first dot to
separate the two.
The current Kconfig default in coreboot instead leads to ugly,
parser-breaking FWIDs like Google_Kevin4.5-1234-5678abcd. This patch
fixes that.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ibbe8a40ccbcba8e4d448eb618b6291d43969a6b1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 46f292f9bf
Original-Change-Id: I65cd5285c69e2e485d55a41a65d735f6a2291c16
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/19487
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/493970
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
1. Select CONFIG_{TPM,TPM2} only when MOCK_SECDATA is not selected.
2. Provide tlcl_lib_init for mock TPM case.
BUG=b:37682566
TEST=Verified that when mock TPM is used, CONFIG_TPM is not set
anymore in coreboot config.
Change-Id: Ib704fe98cab5d6f13b5b7ea75d0ba242ed7e386a
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Id: 00f360e3f1
Original-Change-Id: If3bdd1528e153b164e9d62ee9cbcc4c3666b8b66
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/19456
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/490680
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I48be3be92c154c5c93e7696e39d1d65773fc6c5f
Original-Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Original-Reviewed-on: https://review.coreboot.org/18302
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: e91d170d21
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462015
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I45230f7a73521d66fdc46a54ee9bde32b3e7eae7
Original-Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Original-Reviewed-on: https://review.coreboot.org/18984
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 58c3938705
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462014
No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with
CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why
this wouldn't work (e.g. x86 CAR migration logic currently always
assumes verstage code to run pre-migration). It would also not really
make sense: the reason we use separate verstages is to decrease
bootblock size (mitigating the boot speed cost of slow boot ROM SPI
drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick,
neither of which would apply to the after-romstage case. It is better to
just forbid that case explicitly and give programmers more guarantees
about what the verstage is (e.g. now the assumption that it runs pre-RAM
is always valid).
Since Kconfig dependencies aren't always guaranteed in the face of
'select' statements, also add some explicit compile-time assertions to
the vboot code. We can simplify some of the loader logic which now no
longer needs to provide for the forbidden case. In addition, also try to
make some of the loader logic more readable by writing it in a more
functional style that allows us to put more assertions about which cases
should be unreachable in there, which will hopefully make it more robust
and fail-fast with future changes (e.g. addition of new stages).
Change-Id: Ibf115ba8ac3238bb9f87cafbfde236cd4f555d11
Original-Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa
Original-Reviewed-on: https://review.coreboot.org/18983
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 73d042bd90
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462013
Currently, src/vboot/bootmode.c gets compiled even if vboot is disabled.
It seems that this was only done to support calling certain
developer/recovery mode functions in this case. There is no reason to
compile the whole file for that -- we can just differentiate with a
stub in the header instead, which is what other parts of coreboot
usually do for cases like this.
Change-Id: I2a80a26e93c8ca4a2ac66395b9a22ea940e9a79d
Original-Change-Id: If83e1b3e0f34f75c2395b4c464651e373724b2e6
Original-Reviewed-on: https://review.coreboot.org/18982
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 5fc7c2896a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462012
The virtualized developer switch was invented five years ago and has
been used on every vboot system ever since. We shouldn't need to specify
it again and again for every new board. This patch flips the Kconfig
logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with
CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to
set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the
latter for Lumpy which seems to have been omitted incorrectly, and hide
it from menuconfig since it's a hardware parameter that shouldn't be
configurable.)
Since almost all our developer switches are virtual, it doesn't make
sense for every board to pass a non-existent or non-functional developer
mode switch in the coreboot tables, so let's get rid of that. It's also
dangerously confusing for many boards to define a get_developer_mode()
function that reads an actual pin (often from a debug header) which will
not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set.
Therefore, this patch removes all those non-functional instances of that
function. In the future, either the board has a physical dev switch and
must define it, or it doesn't and must not.
In a similar sense (and since I'm touching so many board configs
anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC.
Instead, it should just be assumed by default whenever a Chrome EC is
present in the system. This way, it can also still be overridden by
menuconfig.
CQ-DEPEND=CL:459701
Change-Id: I33d6fe4570b6c7e6d120ed43736413ace0016454
Original-Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f
Original-Reviewed-on: https://review.coreboot.org/18980
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 320edbe2ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462010
VBOOT_DYNAMIC_WORK_BUFFER and VBOOT_STARTS_IN_ROMSTAGE are equivalent in
practice. We can't have a dynamic work buffer unless we start in/after
romstage, and there'd be no reason to go with a static buffer if we do.
Let's get rid of one extra option and merge the two.
Change-Id: I1946f68355ea9549f0458615f4c0f7b8929baa39
Original-Change-Id: I3f953c8d2a8dcb3f65b07f548184d6dd0eb688fe
Original-Reviewed-on: https://review.coreboot.org/18979
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: fa8fa7dd54
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462009
CHIPSET_PROVIDES_VERSTAGE_MAIN_SYMBOL allows the SoC directory to
provide its own main() symbol that can execute code before the generic
verstage code runs. We have now established in other places (e.g. T210
ramstage) a sort of convention that SoCs which need to run code in any
stage before main() should just override stage_entry() instead. This
patch aligns the verstage with that model and gets rid of the extra
Kconfig option. This also removes the need for aliasing between main()
and verstage(). Like other stages the main verstage code is now just in
main() and can be called from stage_entry().
Change-Id: I505fa91910fc6fda6bd11da709493ada605090ae
Original-Change-Id: If42c9c4fbab51fbd474e1530023a30b69495d1d6
Original-Reviewed-on: https://review.coreboot.org/18978
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 94d9411415
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462008
Add a Kconfig value to enable other platforms to use the soft reboot
workaround.
TEST=Build and run on Galileo Gen2
Change-Id: I6055693c8c02e7448390750a1865f14452aaf553
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 33efd98cfd
Original-Change-Id: I5a7ebd200229654128d367ecb50647ff69bb5258
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18798
Original-Tested-by: Martin Roth <martinroth@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/455821
cr50 by default delays nvmem commits internally from the point of
reset to accumulate change state. However, the factory process can
put a board into dev mode through the recovery screen. This state
is stored in the TPM's nvmem space. When the factory process is
complete a disable_dev_request and battery_cutoff_request is performed.
This leads to disabling the dev mode in TPM, but the battery is
subsequently cut off so the nvmem contents never stick. Therefore,
whenever antirollback_write_space_firmware() is called we know there
was a change in secdata so request cr50 to immediately enable nvmem
commits going forward. This allows state changes to happen immediately.
The fallout from this is that when secdata is changed that current
boot will take longer because every transaction that writes to TPM
nvmem space will perform a write synchronously. All subsequent boots
do not have that effect.
It should also be noted that this approach to the implementation is
a pretty severe layering violation. However, the current TPM APIs
don't lend themselves well to extending commands or re-using code
outside of the current routines which inherently assume all knowledge
of every command (in conflict with vendor commands since those are
vendor-specific by definition).
BUG=b:35775104
BRANCH=reef
TEST=Confirmed disablement of dev mode sticks in the presence of:
crossystem disable_dev_request=1; crossystem
battery_cutoff_request=1; reboot;
Change-Id: Ia2f5ec97f750570c3b16aa68b01ab1eaa94f6960
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eeb77379e0
Original-Change-Id: I3395db9cbdfea45da1f5cb994c6570978593b944
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18681
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/452888
We rely on gnu make, so we can expect the jobserver to be around in
parallel builds, too. Avoids some make warnings and slightly speeds up
the build if those sub-makes are executed (eg for arm-trusted-firmware
and vboot).
BUG=none
BRANCH=none
TEST=none
Change-Id: I858f72696b7a3f3491ca950b4374735cbb363bb7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 78a5f22994
Original-Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://review.coreboot.org/18263
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/435403
For the boards that intend to use mock tpm and have recovery mrc cache
support enabled, provide mock functions to read and write mrc hash
space.
Reading MRC hash space returns TPM_SUCCESS as later checks take care of
comparing the hash value and retraining if hash comparison fails. Thus,
in case of mock tpm, device would always end up doing the memory
retraining in recovery mode.
BUG=chrome-os-partner:62413
BRANCH=None
TEST=Verified that eve builds with mock tpm selected.
Change-Id: Ib946ea2044a64286495a20a285ae5200702c24c9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 775765eaf3
Original-Change-Id: I7817cda7821fadeea0e887cb9860804256dabfd9
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18248
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/435338
Currently, it will print the function name as a prefix to the debug
output. Make it so that a null function name won't get printed, so
that it's possible to print little bits of debug output.
BUG=chromium:683391
BRANCH=none
TEST=build_packages --board=reef chromeos-firmware
Change-Id: I1dff38e4d8ab03118e5f8832a16d82c2d2116ec9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431111
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add rmu.bin to the list of files that exist only in the read-only
section (COREBOOT) of the SPI flash.
TEST=Build and run on Galileo Gen2.
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18031
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I30cbd3fb2ef1848807e4de4c479dc7a561c1faba
Reviewed-on: https://chromium-review.googlesource.com/425292
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When CONFIG_VBOOT_VBNV_CMOS_BACKUP_TO_FLASH is set, vbnv_cmos will try
to load VBNV from flash if the VBNV in CMOS is invalid. This is usually
correct, except the case of battery cut-off.
CMOS will always be invalid after battery cut-off if there is no RTC
battery (or if that is dead). However, in current implementation the
backup in flash is only updated in Coreboot, while the real battery
cutoff (and the clearing of cutoff flags in VBNV) is done in payload
(Depthcharge) stage. This will create an endless reboot loop that:
1. crossystem sets battery cutoff flag in VBNV_CMOS then reboot.
2. Coreboot backups VBNV_CMOS to VBNV_flash.
3. Depthcharge sees cutoff flag in VBNV_CMOS.
4. Depthcharge clears cutoff flag in VBNV_CMOS.
5. Depthcharge performs battery cutoff (CMOS data is lost).
6. (Plug AC adapter) Reboot.
7. Coreboot sees invalid VBNV_CMOS, load backup from VBNV_flash.
8. Jump to 3.
As a result, we should always clear battery cutoff flags when loading
backups from VBNV_flash.
BRANCH=glados,reef
BUG=chrome-os-partner:61365,chrome-os-partner:59615
TEST=emerge-reef coreboot bootimage;
Change-Id: I3250a3a179a7b0de9c6e401e4a94dcd23920e473
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/423460
Reviewed-by: Duncan Laurie <dlaurie@google.com>
The cbmem_possibly_online() is a helpful construct. Therefore,
push it into cbmem.h so other users can take advantage of it.
BUG=chrome-os-partner:60592
BRANCH=reef
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17868
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: If5a1c7815ed03874dcf141014b8ffefb82b7cc92
Reviewed-on: https://chromium-review.googlesource.com/421027
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
vboot_handoff.c is the only place that needs the vb2 internals.
Provide it in the one place it is actually required instead of
pulling in the headers unnecessarily in common code. There is,
however, still a need to get the vb2 hashing types for a function
declaration.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17475
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I038fda68b1cd05fa2e66135158e5e2d18567563a
Reviewed-on: https://chromium-review.googlesource.com/413244
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently the code considers the absence of the NVRAM firmware
rollback space a a trigger for invoking the TPM factory initialization
sequence.
Note that the kernel rollback and MRC cache hash spaces are created
after the firmware rollback space. This opens an ever so narrow window
of opportunity for bricking the device, in case a startup is
interrupted after firmware space has been created, but before kernel
and MRC hash spaces are created.
The suggested solution is to create the firmware space last, and to
allow for kernel and MRC cache spaces to exist during TPM factory
initialization.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=odified the code not to create the firmware space, wiped out the
TPM NVRAM and booted the device. Observed it create kernel and
MRC cache spaces on the first run, and then reporting return code
0x14c for already existing spaces on the following restarts.
Verified that the device boots fine in normal and recovery modes
and TPM NVRAM spaces are writeable in recovery mode.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17398
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: Id0e772448d6af1340e800ec3b78ec67913aa6289
Reviewed-on: https://chromium-review.googlesource.com/412048
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add a new index for recovery hash space in TPM - 0x100b
2. Add helper functions to read/write/lock recovery hash space in TPM
3. Add Kconfig option that can be selected by mainboards that want to
define this space.
4. Lock this new space while jumping from RO to RW.
BUG=chrome-os-partner:59355
BRANCH=None
TEST=Verified use of recovery hash space on reef.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17273
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1cacd54f0a896d0f2af32d4b7c9ae581a918f9bb
Reviewed-on: https://chromium-review.googlesource.com/410114
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add new function vboot_recovery_mode_memory_retrain that indicates if
recovery mode requires memory retraining to be performed.
2. Add helper function get_recovery_mode_retrain_switch to read memory
retrain switch. This is provided as weak function which should be
implemented by mainboard just like {get,clear}_recovery_mode_switch.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=Verified behavior of recovery mode with forced memory retraining on
reef
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17241
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I46c10fbf25bc100d9f562c36da3ac646c9dae7d1
Reviewed-on: https://chromium-review.googlesource.com/410098
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is no code which uses the backup space in TPM created for vboot
nvram.
All chromebooks currently supported at the trunk store vboot nvram
in flash directly or as a backup.
BUG=chrome-os-partner:47915
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: Ied0cec0ed489df3b39f6b9afd3941f804557944f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395507
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Function which invoked when TPM clear is requested was left empty,
this patch fixes it.
BRANCH=gru
BUG=chrome-os-partner:57411
TEST=verified on a chromeos device that tpm is in fact cleared when
CLEAR_TPM_OWNER_REQUEST is set by userland.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/16805
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Change-Id: I4370792afd512309ecf7f4961ed4d44a04a3e2aa
Reviewed-on: https://chromium-review.googlesource.com/391088
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This improves the previous linear search to O(log n). No change in
storage format.
BUG=chromium:640656
BRANCH=none
TEST=Manual
(test empty)
flashrom -i RW_NVRAM -e
Reboot; device should boot normally.
(start using records)
crossystem kern_nv=0xaab0
crossystem recovery_request=1 && reboot
Device should go into recovery mode with reason 1
Reboot again; it should boot normally.
crossystem kern_nv (should still contain 0xaab0)
Repeat steps several times with request=2, 3, etc.
flashrom -i RW_NVRAM -r nvdata
Modify nvdata to copy the first record across all valid
records
flashrom -i RW_NVRAM -w nvdata
Reboot; device should boot normally.
Change-Id: I1eb5fd9fa6b2ae56833f024bcd3c250147bcc7a1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376928
Reviewed-by: Julius Werner <jwerner@chromium.org>
On x86 platforms, google_chromeec_early_init() is used to put the EC
into RO mode when there's a recovery request. This is to avoid training
memory multiple times when the recovery request is through an EC host
event while the EC is running RW code. Under that condition the EC will
be reset (along with the rest of the system) when the kernel verification
happens. This leads to an execessively long recovery path because of the
double reboot performing full memory training each time.
By putting this logic into the verstage program this reduces the
bootblock size on the skylake boards. Additionally, this provides the
the correct logic for all future boards since it's not tied to FSP
nor the mainboard itself. Lastly, this double memory training protection
works only for platforms which verify starting from bootblock. The
platforms which don't start verifying until after romstage need to
have their own calls (such as haswell and baytrail).
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5
Reviewed-on: https://chromium-review.googlesource.com/376858
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The return value check was incorect and checking for failure
in the success path. Fix the return value check so that it
actually checks for success.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16303
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ie7960b89a916dec261015c97c3e0552be56b5b5d
Reviewed-on: https://chromium-review.googlesource.com/374468
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There's no need to be SPI specific w.r.t. how the flash is
connected. Therefore, use the RW boot device to write the
contents of VBNV. The erasable check was dropped because that
information isn't available. All regions should be aligned
accordingly on the platform for the underlying hardware
implementation. And once the VBNV region fills the erase
will fail.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16206
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I07fdc8613e0b3884e132a2f158ffeabeaa6da6ce
Reviewed-on: https://chromium-review.googlesource.com/373368
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Explicitly provide a RW view of an vboot FMAP region. This is
required for platforms which have separate implementations of
a RO boot device and a RW boot device.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16205
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: If8bf2e1c7ca9bff536fc5c578fe0cf92ccbd2ebc
Reviewed-on: https://chromium-review.googlesource.com/373367
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@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
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Reviewed-on: https://chromium-review.googlesource.com/373029
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
However, the latter still has some 'select' clauses to ensure that
required TPM libraries are built. The TPM is an essential part of vboot,
and without these libraries the vboot code cannot compile... therefore,
they should be moved under CONFIG_VBOOT.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16229
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I0145558e5127c65c6a82d62f25b5a39e24cb8726
Reviewed-on: https://chromium-review.googlesource.com/371502
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
This removes the newlines from all files found by the new
int-015-final-newlines script.
BUG=None
BRANCH=None
TEST=None
Change-Id: I89fcb55ff285e4793d7f057f684187359334cb70
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15975
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/366218
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
