History log of /external/vboot_reference/firmware/lib/vboot_nvstorage.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/lib/vboot_nvstorage.c
782990277ac7d6730db4c43c2b5632de93396921 20-Jun-2014 Bill Richardson <wfrichar@chromium.org> Split libvboot_host.a into external and local libraries.

We've been creating and linking against a library called "libvboot_host.a"
for two different reasons. The main purpose is to build the vboot_reference
tools found in the utility/ directory. But there are some external userspace
programs that would also like to use some functions in this library.

This change establishes libvboot_host.a as the library for use by external
userspace programs only, and creates a new libvboot_util.a library that's
only used inside this source tree to build the vboot utilities.

BUG=chromium:231567
BRANCH=ToT
TEST=manual

Build and run the local tests:

make runalltests
make clean

Build Link firmware and all the utilities:

emerge-link chromeos-base/vboot_reference \
sys-boot/depthcharge \
sys-boot/coreboot \
chromeos-base/chromeos-ec \
chromeos-base/chromeos-firmware-link \
chromeos-base/chromeos-cryptohome \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-login \
chromeos-base/verity

Build Lumpy utilities, which include the 32-bit cros_installer:

emerge-lumpy chromeos-base/vboot_reference \
chromeos-base/chromeos-login \
chromeos-base/verity \
chromeos-base/update_engine \
chromeos-base/chromeos-installer \
chromeos-base/chromeos-cryptohome

Change-Id: Ie81ff1f74a6356cb8fab7d98471139d7758c4f19
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207016
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
7993f257af87c7c38cdc71b76bc67cde6c3cdbca 30-Jan-2013 Randall Spangler <rspangler@chromium.org> Reformat to kernel style

No code changes, just reformatting.

BUG=none
BRANCH=none
TEST=make runtests

Change-Id: Id690c8334147970784db5ac54933ad1f5a58dcc1
Reviewed-on: https://gerrit.chromium.org/gerrit/42263
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
feac077c1d96d81f9c1c0b5253d0223b0a2d9448 16-May-2012 Bill Richardson <wfrichar@chromium.org> Add checksum to TPM RollbackSpace regions for FW and kernel.

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

make
make runtests

You can also test it by clearing the TPM, then manually looking at the TPM
regions. In dev-mode, clear the regions and you'll see something like this:

localhost ~ # tpmc read 1007 a
1 0 0 0 0 0 0 0 0 0
localhost ~ # tpmc read 1008 d
1 4c 57 52 47 0 0 0 0 0 0 0 0
localhost ~ #

Go back to normal mode and reboot, and you'll see something like this:

localhost ~ # tpmc read 1007 a
2 0 1 0 1 0 0 0 0 4f
localhost ~ # tpmc read 1008 d
2 4c 57 52 47 1 0 1 0 0 0 0 55
localhost ~ #

The important things are that the first number is now 2, instead of 1, and
the last number is not zero (it's a checksum, so it'll vary depending on the
other numbers, which will themselves vary according to the firmware and
kernel versions).

Change-Id: Ia4040311c2a4b2819792549b883377c8b6b89d48
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/22856
Reviewed-by: Randall Spangler <rspangler@chromium.org>
/external/vboot_reference/firmware/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
b416714a10cc8b8048009ca2ab0f3fa1dc4ac24b 01-Mar-2011 Randall Spangler <rspangler@chromium.org> Add crossystem support for nvram_cleared and kern_nv

Fix try_b processing

And move key block flags check up in LoadFirmware(), which speeds up
boot when the dev switch is off because it doesn't do a signature
check and then throw it out.

BUG=12282
TEST=build firmware, try by hand

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

Change-Id: I10474e9e0ae324906dfe02a351347d04ce847f67
/external/vboot_reference/firmware/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c
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/lib/vboot_nvstorage.c