| Age | Commit message (Collapse) | Author |
|---|
|
This commit just moves the vboot sources into
the security directory and fixes kconfig/makefile paths.
Fix vboot2 headers
Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There's an occasional issue on machines which use CMOS for their
vbnv storage. The machine that just powers up from complete G3
would have had their RTC rail not held up. The contents of vbnv
in CMOS could pass the crc8 though the values could be bad. In
order to fix this introduce two functions:
1. vbnv_init_cmos()
2. vbnv_cmos_failed()
At the start of vboot the CMOS is queried for failure. If there
is a failure indicated then the vbnv data is restored from flash
backup or reset to known values when there is no flash backup.
BUG=b:63054105
Change-Id: I8bd6f28f64a116b84a08ce4779cd4dc73c0f2f3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of having each potential caller deal with the differences
of cmos_init() and init_vbnv_cmos() when VBOOT is enabled put the
correct logic within the callee, cmos_init(), for handling the
vbnv in CMOS. The internal __cmos_init() routine returns when the
CMOS area was cleared.
BUG=b:63054105
Change-Id: Ia124bcd61d3ac03e899a4ecf3645fc4b7a558f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21549
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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 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>
|
|
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>
|
