summaryrefslogtreecommitdiff
path: root/src/vboot
AgeCommit message (Collapse)Author
2017-03-23src/vboot: Add valid license headers to all filesMartin Roth
Change-Id: I77d7d6048fee9b378aa04c1a62b830e08f95ec22 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18407 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-03-14vboot: Allow other platforms to use soft reboot workaroundLee Leahy
Add a Kconfig value to enable other platforms to use the soft reboot workaround. TEST=Build and run on Galileo Gen2 Change-Id: I5a7ebd200229654128d367ecb50647ff69bb5258 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/18798 Tested-by: Martin Roth <martinroth@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-09vboot/tpm2: enable nvmem commits on cr50 when writing firmware secdataAaron Durbin
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: I3395db9cbdfea45da1f5cb994c6570978593b944 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/18681 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: build bot (Jenkins)
2017-01-31build system: mark sub-make invocations as parallelizablePatrick Georgi
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). Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/18263 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-30vboot: Add mock functions for recovery space read/writeFurquan Shaikh
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: I7817cda7821fadeea0e887cb9860804256dabfd9 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/18248 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2017-01-24vboot: vb2ex_printf() ignores null function nameRandall Spangler
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: I046fa766773fc08a29460db1f884d7902692d182 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 853ff7176e97e5e1ab664d094e1914c9c94510aa Original-Change-Id: I1dff38e4d8ab03118e5f8832a16d82c2d2116ec9 Original-Signed-off-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/431111 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18204 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-04vboot: Remove rmu.bin from FW_MAIN_A and FW_MAIN_BLee Leahy
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. Change-Id: I30cbd3fb2ef1848807e4de4c479dc7a561c1faba 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>
2017-01-03vboot: Clear battery cutoff flags when vbnv_cmos loads backup VBNV.Hung-Te Lin
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 backs-up 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> Reviewed-on: https://review.coreboot.org/18008 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-15lib/cbmem: allow anyone to use cbmem_possibly_online()Aaron Durbin
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 Change-Id: If5a1c7815ed03874dcf141014b8ffefb82b7cc92 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>
2016-11-19commonlib/include: remove NEED_VB20_INTERNALSAaron Durbin
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. Change-Id: I038fda68b1cd05fa2e66135158e5e2d18567563a 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>
2016-11-16vboot: make TPM factory init sequence more robust.Vadim Bendebury
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. Change-Id: Id0e772448d6af1340e800ec3b78ec67913aa6289 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)
2016-11-14vboot: Add new function for logging recovery mode switchesFurquan Shaikh
BUG=chrome-os-partner:59352 BRANCH=None TEST=Compiles successfully Change-Id: I87cd675ea45a8b05a178cf64119bf5f9d8d218ca Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17408 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-11-11src/vboot: mark factory_initialze_tpm() as staticVadim Bendebury
This function is not used anywhere else in the code. BRANCH=none BUG=none TEST=reef and kevin boards (using tpm1.2 and tpm2.0 respectively) build successfully. Change-Id: Ifcc345ae9c22b25fdcfc2e547e70766021d27e32 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://review.coreboot.org/17387 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-11-10vboot: Add support for recovery hash space in TPMFurquan Shaikh
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. Change-Id: I1cacd54f0a896d0f2af32d4b7c9ae581a918f9bb 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>
2016-11-10TPM: Add TPM driver files to romstageFurquan Shaikh
This driver is required for reading and updating TPM space for recovery MRC data hash in romstage. BUG=chrome-os-partner:59355 BRANCH=None TEST=Compiles successfully for reef. Change-Id: I8edb7af13285a7a192e3d55fc6a11cfe12654bf9 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17270 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-11-10vboot: Add support for recovery mode with forced memory retrainingFurquan Shaikh
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 Change-Id: I46c10fbf25bc100d9f562c36da3ac646c9dae7d1 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>
2016-11-10Revert "vboot: Add vboot library to romstage"Furquan Shaikh
This reverts commit 21fdd8d0b2206be85dd920e94fb9657a22ab5226. I meant to abandon the original change and clicked submit instead. Change-Id: I1db29b62c5c071113d308583f094f77285c9ba1e Reviewed-on: https://review.coreboot.org/17346 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-10vboot: Add vboot library to romstageFurquan Shaikh
This library is needed for calculating sha-256 of recovery mrc data in romstage. BUG=chrome-os-partner:59355 BRANCH=None TEST=Compiles succesfully for reef. Change-Id: Ie257208c7b3ad07d00e4eb777debf19c42a2fc0c Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17271 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-11-08vboot: Wrap line in comment longer than 80 charactersNaresh G Solanki
Fix comment greater than 80 columns. Change-Id: Ie0be96868e8a99f79781c6bafc8991a955f37ffa Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com> Reviewed-on: https://review.coreboot.org/17265 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-11-07vboot: Disable vboot verification when Chrome EC disabledNaresh G Solanki
When Chrome EC is disabled, vboot hash is not available during S3 resume Hence disable vboot verification when Chrome EC is not available. Change-Id: I665f5f0e2e53da7b735de30443d323572d8a1a9c Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com> Reviewed-on: https://review.coreboot.org/17246 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-13vboot: Stop creating backup space in TPMDaisuke Nojiri
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: I9445dfd822826d668b3bfed8ca50dc9386f2b2b0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5cee2d54c96ad7952af2a2c1f773ba09c5248f41 Original-Change-Id: Ied0cec0ed489df3b39f6b9afd3941f804557944f Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/395507 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://review.coreboot.org/16997 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-09-30vboot: clear tpm when requiredVadim Bendebury
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. Change-Id: I4370792afd512309ecf7f4961ed4d44a04a3e2aa 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>
2016-09-20vboot/vbnv_flash: Binary search to find last used entryRandall Spangler
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: Ieb97563ab92bd1d18a4f6a9e1d20157efe311fb4 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: db9bb2d3927ad57270d7acfd42cf0652102993b1 Original-Change-Id: I1eb5fd9fa6b2ae56833f024bcd3c250147bcc7a1 Original-Signed-off-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376928 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16577 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-25vboot: consolidate google_chromeec_early_init() callsAaron Durbin
On x86 platforms, google_chromeec_early_init() is used to put the EC into RO mode when there's a recovery request. This is to avoid training memory multiple times when the recovery request is through an EC host event while the EC is running RW code. Under that condition the EC will be reset (along with the rest of the system) when the kernel verification happens. This leads to an execessively long recovery path because of the double reboot performing full memory training each time. By putting this logic into the verstage program this reduces the bootblock size on the skylake boards. Additionally, this provides the the correct logic for all future boards since it's not tied to FSP nor the mainboard itself. Lastly, this double memory training protection works only for platforms which verify starting from bootblock. The platforms which don't start verifying until after romstage need to have their own calls (such as haswell and baytrail). Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16318 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-24vboot/vbnv_flash: fix return value check for rdev_writeat()Aaron Durbin
The return value check was incorect and checking for failure in the success path. Fix the return value check so that it actually checks for success. BUG=chrome-os-partner:56151 Change-Id: Ie7960b89a916dec261015c97c3e0552be56b5b5d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16303 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-24vboot/vboot_common: actually provide a writable region_deviceAaron Durbin
vboot_named_region_device_rw() is supposed to provide a writable region_device. However, it was calling fmap_locate_area_as_rdev() which only provides a read-only one. Fix this. BUG=chrome-os-partner:56151 Change-Id: I6279fde32132b1b6138292c3ef771c59709e00c6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16302 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-19vboot/vbnv_flash: make I/O connection agnosticAaron Durbin
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 Change-Id: I07fdc8613e0b3884e132a2f158ffeabeaa6da6ce Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16206 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-19vboot: provide RW region device supportAaron Durbin
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 Change-Id: If8bf2e1c7ca9bff536fc5c578fe0cf92ccbd2ebc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16205 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-08-18Kconfig: rename BOOT_MEDIA_SPI_BUS to BOOT_DEVICE_SPI_FLASH_BUSAaron Durbin
Provide a default value of 0 in drivers/spi as there weren't default values aside from specific mainboards and arch/x86. Remove any default 0 values while noting to keep the option's default to 0. BUG=chrome-os-partner:56151 Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16192 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-16vboot: Move TPM-related Kconfig selects from CHROMEOS to VBOOTJulius Werner
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. Change-Id: I0145558e5127c65c6a82d62f25b5a39e24cb8726 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16229 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-31src/vboot: Capitalize RAM and CPUElyes HAOUAS
Change-Id: Iff6b1b08b8159588b964d9637b16e1e0bfcca940 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15986 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-31Remove extra newlines from the end of all coreboot files.Martin Roth
This removes the newlines from all files found by the new int-015-final-newlines script. Change-Id: I65b6d5b403fe3fa30b7ac11958cc0f9880704ed7 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>
2016-07-28bootmode: Get rid of CONFIG_BOOTMODE_STRAPSFurquan Shaikh
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and developer mode check functions to vboot. Thus, get rid of the BOOTMODE_STRAPS option which controlled these functions under src/lib. BUG=chrome-os-partner:55639 Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15868 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-28vboot: Separate vboot from chromeosFurquan Shaikh
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use of verified boot library without having to stick to CHROMEOS. BUG=chrome-os-partner:55639 Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15867 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 13:23:44 +0000