History log of /external/vboot_reference/firmware/include/vboot_nvstorage.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
dc8ec103c0d0d2a4e930153a4b19c43b51d74b5d 10-Feb-2015 Julius Werner <jwerner@chromium.org> vboot1: Add vboot2 recovery reason strings and subcode to TAB display

vboot2 added a few new recovery reasons (and abolished many old ones).
In the current vboot2/vboot1 hybrid architecture used on Veyron, the
vboot1 kernel verification part controls the status display when
pressing the TAB key, which may try to show recovery reasons set by the
vboot2 firmware verification part. These currently result in the not
very helpful "We have no idea what this means", so lets hack a few more
strings into vboot1 which will be otherwise harmless. Also add the
recovery_subcode field to the display, which is used much more
extensively by vboot2 and often very useful in firguring out what really
went wrong.

BRANCH=veyron
BUG=None
TEST=Manually set a few recovery reasons and subcodes through crossystem
and made sure they get displayed correctly on my Jerry.

Change-Id: I3f3e6c6ae6e7981337841c0c5e3cd767628472c3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248391
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
782300d093a2fbf2ca24e446fb6d65f9f28e56a6 23-Sep-2014 Randall Spangler <rspangler@chromium.org> vboot2: Add previously tried slot and result to NV storage

This gives recovery mode information on two boots back instead of one,
which may be handy for debugging.

It also allows determining whether a failure of the current boot
should try the other slot or go to recovery, using only information
stored in NV storage.

Added crossystem support for printing the fields, and unit tests.

BUG=chrome-os-partner:32585
BRANCH=none
TEST=make runtests; VBOOT2=1 make runtests

Change-Id: Ia9f4186210d30217b902db7c513ae4ab8851f8f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221230
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
9e1da784487fb8cfbe4e76693e07205b66675bda 25-Jun-2014 Randall Spangler <rspangler@chromium.org> Add nvstorage / crossystem support for new vboot2 fields

This allows testing vboot2. These fields are ignored by original
vboot firmware.

BUG=chromium:370082
BRANCH=none
TEST=manual
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A

crossystem fw_tried=B
echo $? -> 1
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A

crossystem fw_try_next=B
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B
crossystem fw_try_next=beats_me
echo $? -> 1
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=B
crossystem fw_try_next=A
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A

crossystem fw_result=trying
crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A
crossystem fw_result=bupkis
echo $? -> 1
crossystem -> fw_tried=A, fw_result=trying, fw_try_next=A
crossystem fw_result=success
crossystem -> fw_tried=A, fw_result=success, fw_try_next=A
crossystem fw_result=failure
crossystem -> fw_tried=A, fw_result=failure, fw_try_next=A
crossystem fw_result=unknown
crossystem -> fw_tried=A, fw_result=unknown, fw_try_next=A

crossystem -> fw_try_count = 0, fwb_tries = 0
crossystem fw_try_count=6
crossystem -> fw_try_count = 6, fwb_tries = 6
crossystem fwb_tries=0
crossystem -> fw_try_count = 0, fwb_tries = 0

Change-Id: I1532f3384f8c05de2a7ff3f35abcc35d18049491
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205475
/external/vboot_reference/firmware/include/vboot_nvstorage.h
b64f097891e697eaf3b2794baae934f8b4d82d14 29-May-2014 Bill Richardson <wfrichar@chromium.org> Use the TPM to back up some of the nvram fields

We use a few bytes of battery-backed nvram to save some flags across
reboots. However if the battery discharges completely, these flags are lost.
There aren't any security issues with that since they reset to safe values,
but some of the flags are used to configure how the system boots in
dev-mode.

If a dev-mode user has completely replaced ChromeOS with some other OS, then
she often needs to set the dev_boot_usb and/or dev_boot_legacy flags as well
in order to boot it using Ctrl-U or Ctrl-L. If the battery dies, then those
flags are cleared, and the only way to make the Chromebook boot again is by
going through recovery, which wipes the disk.

This change uses a new NV space in the TPM to back up some of the nvram
flags. These nvram fields will be backed up:

block_devmode
dev_boot_legacy
dev_boot_signed_only
dev_boot_usb
fwupdate_tries
loc_idx

Because writing to the TPM space is slow and limited to an unspecified but
finite number of cycles, we only back up the fields when specifically
requested by the new backup_nvram_request flag. This flag will be set by
crossystem whenever it is used to change any of the fields listed above. The
backup will be attempted at the NEXT boot (because the TPM is locked after
booting), and the backup_nvram_request flag will be cleared if the backup
was successfull.

Note that this CL is for Top of Trunk only. The firmware will create the
required TPM spaces on systems that have never been booted, but we don't yet
have a secure or reliable method to update existing systems.

FYI, on Link, determining that the TPM's backup NV space doesn't exist adds
about 6ms to the boot time. If it does exist, the backup_nvram_request flag
is cleared automatically so it won't check until it's set again.

BUG=chromium:362105
BRANCH=ToT (only!)
TEST=manual

Testing this is a long and involved process. Read on...

First, there are host-side tests for it. In the chroot:

cd src/platform/ec
make runtests

Second, to test on a completely NEW system that was first booted with a BIOS
that contains this CL, do this:

Enter dev-mode
Use crossystem to set values for the fields listed above
Confirm that "backup_nvram_request" is set to 1
Reboot
Use crossystem to confirm that "backup_nvram_request" is now 0
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Use crossystem to confirm that the backed up fields are still good, while
the others have been reset to default values
Switch to normal mode
Remove the battery and the AC
Reattach either battery or AC so it will boot again
Look at the bios info in chrome://system to see what crossystem says
Confirm that the dev_boot_* flags are all 0, while the others are restored

Third, to set things up to test this on an existing system (I used Link),
you have update the BIOS, delete both the Kernel and Firmware NV spaces in
the TPM, then reboot so that the BIOS will create the Backup, Kernel, and
Firmware spaces. It will only do that if they're all missing.

Open it up, disable write-protect, attach a servo, etc.
Switch to dev-mode, log in.
Run make_dev_firmware.sh

Reboot in recovery mode, and insert a USB stick with a test image on it.

NOTE: In order to fiddle with the TPM, we'll *always* have to boot in
recovery mode, since that's the only time the TPM is left unlocked. That's
NOT the same as pressing Ctrl-U at the scary boot screen. The rest of
these steps assume you've booted in recovery mode and are running from the
test image on the USB stick.

Run

make_dev_ssd.sh --remove_rootfs_verification --recovery_key

Reboot (recovery mode)

Run

mv /etc/init/tcsd.conf /etc/init/tcsd.conf.disabled

Reboot (recovery mode).

Run "tpmc getvf". It should say

deactivated 0
disableForceClear 0
physicalPresence 1
physicalPresenceLock 0
bGlobalLock 0

Run "tpmc geto". It should say

Owned: no

Now you'll need to build the "tpm-nvtool" utility. In the chroot:

cd src/third_party/tpm/nvtool
make

Copy that to the DUT, in /usr/local/bin.

Now run

tcsd
tpm-nvtool --list | grep Index

You may see a number of spaces, but you should at least see these:

# NV Index 0x00001007
# NV Index 0x00001008

Run

tpm_takeownership

It will prompt you for two passwords (and confirm each one). Respond with
something you can remember like "google".

Run

tpm-nvtool --release --index 0x1007 --owner_password "google"
tpm-nvtool --release --index 0x1008 --owner_password "google"

Verify that it worked with

tpm-nvtool --list | grep Index

Power off.

Using servo, flash the new BIOS that has this CL in it.

Power on, normally this time (not recovery mode). If all goes well, it
should create the correct NV spaces and boot into the SSD. Copy tpm-nvtool
into this image too, and run

tpm-nvtool --list | grep Index

You should now see at least these spaces:

# NV Index 0x00001007
# NV Index 0x00001008
# NV Index 0x00001009

Now you're ready to test the backup/recover feature.

Change-Id: I00031fa0774720147327e2ae0f37e26b34b86341
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202138
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
0c3ba249abb1dc60f5ebabccf84ff13206440b83 29-Mar-2013 Bill Richardson <wfrichar@chromium.org> Massive refactoring of external header files.

This reduces the number of exported header files to the minimum needed by
the existing userspace utilities and firmware implementations.

BUG=chromium:221544
BRANCH=none
TEST=manual, trybots
CQ-DEPEND=CL:47019,CL:47022,CL:47023

sudo FEATURES=test emerge vboot_reference
FEATURES=test emerge-$BOARD \
vboot_reference \
chromeos-cryptohome \
chromeos-installer \
chromeos-u-boot \
peach-u-boot \
depthcharge

Change-Id: I2946cc2dbaf5459a6c5eca92ca57d546498e6d85
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47021
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
5ca4ea087a3d67c2a639e8b9254f51f076bf85fa 05-Feb-2013 Randall Spangler <rspangler@chromium.org> EC software sync uses precomputed hash if available

This removes the need to load the EC code at all when the precomputed
hash matches.

BUG=chrome-os-partner:17606
BRANCH=spring
TEST=wouldn't that be nice

Change-Id: If4438b9db8b1449b8fd4d90ef3acb3bbec5e09a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42567
/external/vboot_reference/firmware/include/vboot_nvstorage.h
a2db67d204c0dd3d152ff54958bf42c5dbe394ff 25-Jan-2013 Randall Spangler <rspangler@chromium.org> Reformat header files to kernel style

No code changes, just reformatting.

BUG=none
BRANCH=none
TEST=make runtests

Change-Id: Id5bac79545e9803d19b45da160c535f7e06465c6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42016
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
699ebf398f84bb0a6138856c38db1d693e581f85 17-Dec-2012 Bill Richardson <wfrichar@chromium.org> Add recovery_subcode field to nvstorage and crossystem

This just adds a one-byte field in the nvstorage region for use in debugging
hard-to-catch errors. There's no official meaning or expectation for this
field. It's just a handy place to emit some information.

BUG=chrome-os-partner:11534
BRANCH=parrot
TEST=manual

Just change the value and ensure that it persists across a (working) reboot.
It's only updated at specific points under very exacting error conditions,
so all we really want to test is that it works as a place to store some
extra info.

crossystem recovery_subcode
crossystem recovery_subcode=14
reboot
crossystem recovery_subcode

The recovery_subcode byte is at index [6] of the VbNv.raw bytes that appear
when you press TAB, so you can find it there too:

VbNv.raw: 60 20 00 00 00 00 0e 00 00 00 00 00 00 00 00 65

Decimal 14 == 0x0e

Change-Id: I1930b8f81a03ab838dbee99a8d72c35a444efdfd
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39803
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
640b1c420748049c796b3f9d59406e38ff8f4774 22-Nov-2012 Bill Richardson <wfrichar@chromium.org> Add more recovery_reason codes

There are several places where the same recovery_reason was used to report
slightly different points of failure. Let's create some new codes instead.

Remember that recovery mode is handled by RO firmware, so if an updated RW
firmware uses one of the new error codes, pressing TAB at the recovery
screen will say "We have no idea what this means". That's not a bug. This CL
deprecates the original codes, so the fact that the RO firmware doesn't
recognize it just means it's a new code reported by a new RW BIOS.

BUG=chromium-os:36562
TEST=manual
BRANCH=parrot

Run

make && make runtests

It should pass. You can test some of the error cases on actual hardware by
using

crossystem recovery_reason=86
reboot

and pressing TAB at the recovery screen. For that example you should see the
message

recovery_reason: 0x56 TPM lock error in rewritable firmare

Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df
Reviewed-on: https://gerrit.chromium.org/gerrit/38652
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
d2852eabf6da8bd36ba898c9b375f0480fab02d2 29-Oct-2012 Luigi Semenzato <semenzato@chromium.org> Add recovery reason for failure to correct TPM error

The TPM on snow devices may boot in an unusable state. The workaround
is to detect this early and reboot. The workaround code prevents
an infinite reboot loop by counting the number of reboots and entering
recovery mode with this reason after a small threshold has been reached.

BUG=chromium:156655
TEST=no test! Not even compiled!
BRANCH=none

Change-Id: Ica2f14f8f7df8c46b7cbe5dbd578ba93c8f3a78c
Reviewed-on: https://gerrit.chromium.org/gerrit/36790
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Luigi Semenzato <semenzato@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
a2326ee152ab5b8aee924ccf794cee38d54909bd 24-Aug-2012 Stefan Reinauer <reinauer@chromium.org> Add CTRL-L in dev screen to support a "legacy boot option"

This option is disabled per default and can be enabled with
crossystem dev_boot_legacy=1
or by setting the GBB flag
GBB_FLAG_FORCE_DEV_BOOT_LEGACY 0x00000080

BUG=chrome-os-partner:6108
TEST=crossystem dev_boot_legacy=1
boot to dev mode screen, press CTRL-L, see SeaBIOS start
(other CLs needed)
BRANCH=link
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>

Change-Id: I593d2be7cff5ca07b8d08012c4514a172bd75a38
Reviewed-on: https://gerrit.chromium.org/gerrit/31265
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
29e8807ea045e119e3adeaec40c5f8421901b6fb 19-Jun-2012 Randall Spangler <rspangler@chromium.org> Add clear TPM owner request

This adds two new flags to crossystem:
clear_tpm_owner_request
clear_tpm_owner_done

The first one requests that the firmware clear the TPM owner on the
next boot. When the firmware does this, it will set
clear_tpm_owner_request=0, and set clear_tpm_owner_done=1. The OS can
use the done-flag as a hint that trusted things guarded by the TPM are
no longer trustable.

BUG=chromium-os:31974
TEST=manual

crossystem
// both flags initially 0
crossystem clear_tpm_owner_request=1
crossystem clear_tpm_owner_done=1
// request=1, done=0; done can be cleared but not set by crossystem
reboot
tpmc getownership
// owned=no
crossystem
// request=0, done=1
crossystem clear_tpm_owner_done=0
crossystem
// both flags 0 again

Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I49f83f3c39c3efc3945116c51a241d255c2e42cd
Reviewed-on: https://gerrit.chromium.org/gerrit/25646
/external/vboot_reference/firmware/include/vboot_nvstorage.h
584e0d2070aca1a5e091442cb9bad0726451ad95 26-Jul-2012 Randall Spangler <rspangler@chromium.org> Add more specific recovery reasons for EC software sync.

Software sync will, of course, work perfectly, so these will never be needed.

BUG=none
TEST=none (hey, it all works perfectly)

Change-Id: I0014dfb99507c5eb00de73b77edb7538b598658f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28495
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
d4faa060cc6445cf532e3f9c9cd785e0726f1b82 17-Jul-2012 Randall Spangler <rspangler@chromium.org> Partial EC software sync implementation

Doesn't check the EC hash, but does jump to the correct image, for now
assuming the hash is good.

BUG=chrome-os-partner:11087
TEST=manual

- Power+refresh. System boots. EC is in RO (verify via 'ectool version')
- Create a BIOS signed *without* RO-normal.
- Power+refresh. System boots. EC ends up in A.
- ectool eventgetb. Event 0x2000 IS present, indicating EC has rebooted
- ectool eventclearb -1
- Power button to shut down, then power button to power back on.
- ectool eventgetb. Event 0x2000 is NOT present.
- crossystem recovery_request=123 && reboot. System reboots to recovery mode
and EC is in read-only (verify via EC console 'sysinfo')
- Power off and on. System boots. EC ends up in A again.

Change-Id: I39682d1bf7215c62a4b20613d029e78194b98826
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27574
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
17b8224ea582b2ba90b30a3e8e2d913e49c7818a 27-Jun-2012 Bill Richardson <wfrichar@chromium.org> Add bits to request and acknowledge Option ROM loading.

For fastest boot, we don't want to load the VGA Option ROM every time, but
only when we need it. Coreboot does that loading, but it can't always know
when it's needed (with keyboard-based dev-mode, coreboot can't tell if we're
in dev-mode or not). By the time we get to U-Boot, it's too late, so we need
two extra bits - one for vboot to tell coreboot to load the Option ROM and
another for coreboot to let vboot know it's been done.

BUG=chrome-os-partner:8789
TEST=manual

The only visible change is that crossystem will now have an "oprom_needed"
flag that can be set or cleared. Nothing actually pays attention to it yet,
though.

Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I521a6afdfb8ea17a8148b32eeb858844c981de9c
Reviewed-on: https://gerrit.chromium.org/gerrit/26272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
c0e3742996a84d3c503cfa002b09a0831bcb2c32 08-Jun-2012 Randall Spangler <rspangler@chromium.org> Remove unused test fields from VbNvStorage

Confirmed via codesearch that these fields are not used outside of
vboot_reference itself, and the only use inside vboot_reference is one
test which checked that the test error generation itself worked.

BUG=chromium-os:31668
TEST=make && make runtests

Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic393e126ca2853f7aaff19ffd6fcdbdb1c47689f
Reviewed-on: https://gerrit.chromium.org/gerrit/24895
Reviewed-by: Simon Glass <sjg@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
35d073362603c2c3f63974d04b4af9548297e208 25-May-2012 Bill Richardson <wfrichar@chromium.org> Add DISABLE_DEV_REQUEST flag to nvram.

This just creates the bit. It doesn't actually do anything yet.

BUG=chrome-os-partner:9980
TEST=manual

crossystem disable_dev_request=1
crossystem
crossystem disable_dev_request=0
crossystem

Change-Id: I0e92a6b5ef5074ee5eae2d6d469c1c9826faecb3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23752
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
7272a6951107251a5c9b26330c506319a92a54b3 17-Nov-2011 Bill Richardson <wfrichar@chromium.org> Dev-mode allows booting self-signed kernels by default.

When you enter dev-mode,

Pressing Ctrl-U to boot from USB is DISABLED.
Booting any self-signed kernel from the SSD is ENABLED.

This replaces the "crossystem dev_boot_custom" argument with
"crossystem dev_boot_signed_only", which has the opposite polarity.
So if you want to dev-mode to only boot official kernels, you have to
explictly set it that way. If you leave dev-mode and then come back,
it will go back to the conditions shown above.

BUG=chrome-os-partner:5954
TEST=manual

Just run the factory flow. It was broken; this should fix it (except for any
workarounds that were added while it was broken; those may need to be
reverted).

Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805
Reviewed-on: https://gerrit.chromium.org/gerrit/11853
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
fa9d7782e837848a1aeb0e95295fa48ac23f7a26 09-Nov-2011 Bill Richardson <wfrichar@chromium.org> Dev-mode only boots official kernels by default

Although we're now using a single unified BIOS, it is pretty nice to be able
to get a shell in developer mode while still using verified boot for the
kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode
user to install a special dev-mode BIOS. We don't do that, but we DO require
setting a special flag with "crossystem" to accomplish the same thing.

In order to allow booting a self-signed kernel, you must boot in developer
mode, open a shell, and run this:

crossystem dev_boot_custom=1

Special note to internal developers: If you're in the habit (as I am) of
booting directly from a USB stick in dev-mode, you'll have to run this:

crossystem dev_boot_custom=1 dev_boot_usb=1

Just using dev_boot_usb=1 is no longer enough, because the USB kernel is
signed using the recovery key and by pressing Ctrl-U, we validate it with
the kernel data key. That worked before this change because any self-signed
kernel was fine, and that's how the USB key was treated. Now it actually
requires a verified signature until you enable dev_boot_custom=1 also.

BUG=chrome-os-partner:5954
TEST=manual

Boot once in normal mode, which clears the special flags. Then switch to
developer mode. You should be able to boot and get a root shell.

Run

crossystem dev_boot_usb=1

Obtain a USB recovery image that's keyed differently. For example, if you're
testing with dev-keys, use a PVT-signed image or vice-versa.

Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode
screen, press Ctrl-U. You should hear a single beep, but it should not boot.

Press Ctrl-D to boot from the hard drive, log in to a shell and run

crossystem dev_boot_custom=1

Repeat the previous test. This time when you press Ctrl-U, it should boot
the recovery image. Turn the system off before it does anything.

That's it.

Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69
Reviewed-on: https://gerrit.chromium.org/gerrit/11442
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
ad03a439bc97523e03d19aa1dcd568744d60889c 22-Jul-2011 Randall Spangler <rspangler@chromium.org> Cleanup and preparation for inside-wrapper TPM refactoring.

Add recovery reason for already in recovery and need to reboot to
recovery to let the TPM init.

Add vboot_struct fields.

Fix type for keyblock flags param to SetTPMBootModeState().

BUG=none
TEST=make && make runtests

Change-Id: I4035bdb377aaebaca03a43799be57977166da739
Reviewed-on: http://gerrit.chromium.org/gerrit/4599
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
daa807c51ef6d5bf6599e649d1777432bea8a3e5 11-Jul-2011 Randall Spangler <rspangler@chromium.org> Add support for dev_boot_usb flag

BUG=chromium-os:17433
TEST=make && make runtests. Additional manual tests:

0. Insert a valid dev-signed USB key.

1. Boot with dev switch off.
`crossystem dev_boot_usb` should print 0.

2. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.
Ctrl+U at dev screen should beep, but not boot USB.

3. Type `crossystem dev_boot_usb=1`. Should succeed.
`crossystem dev_boot_usb` should print 1.

4. Reboot system.
At the dev mode warning, press Ctrl+U
System should boot from USB key
`crossystem dev_boot_usb` should print 0.

5. Flip dev switch off.
`crossystem dev_boot_usb` should print 0.

6. Flip dev switch on.
`crossystem dev_boot_usb` should print 0.

Note that this does not apply to Cr-48, Alex, or ZGB.

Change-Id: Idf85fdd642f38f531c89e5fa5b1679e84936d4da
Reviewed-on: http://gerrit.chromium.org/gerrit/3875
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
9619112a574b975476667545e3a326052fa0c50b 08-Jul-2011 Randall Spangler <rspangler@chromium.org> Vboot wrapper - add recovery reason, refactor timing

Pressing Tab at a firmware screen now displays real data, including
the recovery reason, HWID, and contents of VbNvStorage.

Entry point start/end time tracking in VbSharedData now refers to the
new wrapper APIs.

Added capability for calling firmware to request recovery mode (for
example, if it's unable to initialize RAM, can't find the SSD, etc.).
Previously, calling firmware had no (good) way to do this other than
faking the recovery button being pressed.

BUG=chromium-os:17018
TEST=emerge on x86 and tegra2_seaboard

Change-Id: I7d377f279842b30a10d945d13571c41c464633f1
Reviewed-on: http://gerrit.chromium.org/gerrit/3814
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
7adcc60e6f5f6db081b9ad6e02288335502a0d77 25-Jun-2011 Randall Spangler <rspangler@chromium.org> Vboot wrapper API - crossystem and header files

Header file changes for wrapper API implementation

Crossystem support for reading recovery reason from VbSharedData, and
explicit support for version 1 VbSharedData structs.

BUG=chromium-os:16970
TEST=make && make runtests; run crossystem on Alex and make sure it still reports recovery_reason in recovery mode.

Change-Id: I15195b899583e425d3c9e8df09842d764528e2cb
Reviewed-on: http://gerrit.chromium.org/gerrit/3203
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
9243e616d727c3e57525f8dec2b5f22840900451 10-May-2011 Randall Spangler <rspangler@chromium.org> Add more specific recovery reasons for RW firmware invalid

BUG=chrome-os-partner:3698
TEST=manual

1. Run the firmware key/version autoupdate test; this rolls forward your stored TPM version numbers.
2. Put back the original firmware.
3. Reboot.
4. Press TAB at recovery screen.
5. Should see Recovery Reason 0x14.

Change-Id: I7791f594dbd8919e74d1e6b97b99775cf1e73d1d
Reviewed-on: http://gerrit.chromium.org/gerrit/567
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/include/vboot_nvstorage.h
cabe6b3514f3228b350a7d07d6cc7cb39eecaaf6 18-Mar-2011 Randall Spangler <rspangler@chromium.org> Use VbSharedData instead of VbNvStorage for fwb_tries and kernkey_vfy

Change-Id: I5ed3509a9d4e578cd2e98f493dab59bc2fbd5827

R=dlaurie@chromium.org
BUG=chrome-os-partner:2748
TEST=manual

crossystem fwb_tries=3
(reboot)
crossystem tried_fwb
(should print 1)

crossystem fwb_tries=0
(reboot)
crossystem tried_fwb
(should print 0)

In dev mode...
Boot a kernel signed with the same key as in the firmware
crossystem kernkey_vfy
(should print sig)
Boot a kernel signed with a different key than the firmware
crossystem kernkey_vfy
(should print hash)

Review URL: http://codereview.chromium.org/6711045
/external/vboot_reference/firmware/include/vboot_nvstorage.h
99ca3466ba097cceacaff0129e9060578a8fcb20 15-Mar-2011 Randall Spangler <rspangler@chromium.org> LoadFirmware() and LoadKernel() handling for test errors

Change-Id: Icecfcab8f5cc30e80da7a2d77a1b1729f5094fee

R=wfrichar@chromium.org
BUG=13107
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6673048
/external/vboot_reference/firmware/include/vboot_nvstorage.h
b17e8d353c50d46f0e5f29578f6294003692ea1d 15-Mar-2011 Randall Spangler <rspangler@chromium.org> Add VB test error func/num

Change-Id: Ibe253963f0424935554fe91f166ef5040a723c6f

BUG=13107
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6698032
/external/vboot_reference/firmware/include/vboot_nvstorage.h
95c4031ce903258036beeed0705d25c7e9d25da0 10-Mar-2011 Randall Spangler <rspangler@chromium.org> This is necessary to pass additional information about whether firmware A or B is being run. This change also passes the GBB directly into LoadFirmware() and LoadKernel().

Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60

BUG=chrome-os-partner:1657
TEST=manual - see below

make && make runtests

Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified)

build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin

build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk

And make sure the firmware with this change actually boots to USB and SSD.

NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change

Review URL: http://codereview.chromium.org/6626045
/external/vboot_reference/firmware/include/vboot_nvstorage.h
640fb51d866e7ac8a92f61a2f69145bfe6b13699 03-Mar-2011 Randall Spangler <rspangler@chromium.org> Reapply patch from http://codereview.chromium.org/6594092/

(somehow that never got committed)

Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38

BUG=12282
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6610019
/external/vboot_reference/firmware/include/vboot_nvstorage.h
92e378e453c7c7186a06d9021fb64eb7985937f5 25-Feb-2011 Randall Spangler <rspangler@chromium.org> rename tried_fwb constants

Change-Id: Ib8018bfe29eed50766c699d832efe4f1afcabb1a

BUG=none
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6597015
/external/vboot_reference/firmware/include/vboot_nvstorage.h
172602829dc0d79ed65d7ed81225389f090b981f 25-Feb-2011 Randall Spangler <rspangler@chromium.org> Add NV storage fields for firmware flags

1) Did firmware attempt RW slot B before slot A?

2) Did firmware check the kernel keyblock signature, or just its hash?

Added crossystem support as well.

BUG=chrome-os-partner:1657
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6597011

Change-Id: I0d743ae87cedd938ba988170793717d3fdbd8ce9
/external/vboot_reference/firmware/include/vboot_nvstorage.h
9e162cdaa7433dff01d3e47ba3a47cb8b39ff3a1 22-Feb-2011 Randall Spangler <rspangler@chromium.org> VbNvStorage cleanup and comments

BUG=12282
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6469059

Change-Id: I912b53ae33d65305353a747cc0bdd2b1ea62a04f
/external/vboot_reference/firmware/include/vboot_nvstorage.h
b944534edd3799b3353f73bcb8ee90161d640c2b 18-Feb-2011 Randall Spangler <rspangler@chromium.org> Add NV storage API to vboot reference

BUG=chromium-os:12282
TEST=make && make runtests

Review URL: http://codereview.chromium.org/6532040

Change-Id: I57099de54ed56aa722f1944568bbb58b71b14379
/external/vboot_reference/firmware/include/vboot_nvstorage.h