We need all the libraries to come after the objects, not before, otherwise
static and --as-needed linking fails when the linker drops the libraries.
BUG=None
TEST=`emerge vboot_reference` still works
Change-Id: Id98571a90115ab5ace68a0c795de86d7fe78f133
Reviewed-on: https://gerrit.chromium.org/gerrit/18290
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
I've found a bug in vbutil_kernel, but the names of some of the internal
variables and struct members make it hard to follow (which is probably why
the bug exists). Before I fix it, I need to rename some things so we can see
what's wrong. This does that.
BUG=none (yet)
TEST=manual
make
make runtests
Change-Id: I8646c8acd33c58ccd52668943bcee4d0664716aa
Reviewed-on: https://gerrit.chromium.org/gerrit/18146
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Similar to the canary channel, the dogfood channel images can have their
own app id that is distinct from the board app id.
BUG=chromium-os:25702, chrome-os-partner:8441
TEST=on a dogfood-channel image
Change-Id: Ic993a40d905b224072d325a69e47fdb6633c2e22
Reviewed-on: https://gerrit.chromium.org/gerrit/18039
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Scott Zawalski <scottz@chromium.org>
We need to use the .pc file to get the compiling/linking details,
so switch over to that.
While we're here, fix the hardcoded `ar` to use $(AR) from the env.
BUG=chromium-os:16623
TEST=`emerge-x86-alex vboot_reference` builds & links CgptManagerTests against newer libbase
Change-Id: I20865138fdfd1725415d737ad5fdbc4c134079a7
Reviewed-on: https://gerrit.chromium.org/gerrit/17533
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
This change prepares for modifying VbFirmwarePreambleHeader and
VbKernelPreambleHeader by adding a bunch of current-version data and tests
of that data. Once we change the structs, we'll still need to be sure that
we can still generate, sign, and verify things using the old-style structs
too so that we can release updates to existing devices.
If we changed the structs and then created the test data, we couldn't be
certain that we're still doing it right.
BUG=chromium-os:20124
TEST=manual
make
make runtests
Change-Id: I39310a0d853dbf63a8ca8ff9a0fb4440017c692a
Reviewed-on: https://gerrit.chromium.org/gerrit/17530
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Callers of vboot might print some additional information in
VbExDisplayDebugInfo(). Add a new line to the end of the buffer
so that output is aligned with the normal <tab> information.
BUG=none
TEST=set gbb flags to 1, see cursor go to next line at dev screen.
Change-Id: I8dd77404338a05bddc5f3ec54d7b65c890a60c50
Reviewed-on: https://gerrit.chromium.org/gerrit/17001
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The existing library had a bunch of dependencies which are too many to
build for the 32-bit platform. So this checkin prunes the dependency
list by building only things that are absolutely required for the
functionality used in 32-bit Post-Installer.
Made the use of libuuid restricted only to cgpt and unit tests so that
libcgpt-cc.a doesn't depend on it.
BUG=chromium-os:25374
TEST=Built 32-bit and 64-bit. Tested 32-bit post-install.
Change-Id: Idd0826fdf507a95728fee8adac9520e26f05d469
Reviewed-on: https://gerrit.chromium.org/gerrit/16433
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
CgptManager exposes the cgpt commands via a C++ library so that
the post-installer for 32- to 64-bit upgrade can link directly
against a library and thus avoid any shell dependency.
The default make target will not build libcgpt-cc.a since it
requires some dependencies that are available only in chroot.
A separate follow-up checkin to the vboot_reference
ebuild will enable emerging the libcgpt-cc.a by default.
BUG=chromium-os:25374
TEST=Tested with the new unit tests for CgptManager,
ran existing cgpt unit tests, as well as running the
cgpt commands manually. Built on both amd64 and x86.
Tested that vboot_reference is also buildable outside of chroot.
Tested that vboot_reference-firmware and vboot_reference-tests
also build fine with these changes.
CQ-DEPEND=I99f6c321e09c2425eaa8171d78685d2d731954c8
Change-Id: I59a896255b8ea2fc8b1b2150ae7c4ff9d0769699
Reviewed-on: https://gerrit.chromium.org/gerrit/15730
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Due to the limitation of servo that is unable to send U keys, dev USB boot
(triggered by Ctrl-U) is unable to be tested on FAFT. To solve it, firmware
should add an addition key combination to workaround it. Ctrl-Enter is the
one we picked.
BUG=chrome-os-partner:6759
TEST=compile the firmware and update it to Lumpy; during the dev screen,
press Ctrl-Enter to trigger USB boot.
Change-Id: I8215a241c3c07dc2f5e194c324459f106d007f47
Reviewed-on: https://gerrit.chromium.org/gerrit/15749
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
If the channel is canary, allow appid to match the value of
expected_appid_canary in the ensure sane lsb release test
configuration.
BUG=chromium-os:25437
TEST=manually tested on an image with and without the channel being canary.
Change-Id: I6bf71adbe0fc090ef777c28d24c53eaa8be18404
Reviewed-on: https://gerrit.chromium.org/gerrit/15509
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Scott Zawalski <scottz@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
BUG=chrome-os-partner:7878
TEST=none
Well, you could test it like so:
flashrom -r /dev/null -i GBB:/tmp/GBB.bin
vbutil_what_keys GBB.bin
except that the current ChromeOS image doesn't include vbutil_what_keys. It
probably should, but that's a different CL.
Change-Id: I1e5b6cf30a81a46cb5c8c5d9b10f351dafa9ca87
Reviewed-on: https://gerrit.chromium.org/gerrit/15359
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7878
TEST=manual
Run vbutil_what_keys specifying either a BIOS or disk image signed with the
Stumpy MP keys. It should identify it as such. For example:
vbutil_what_keys chromeos_1675.0.0_stumpy_recovery_dev-channel_mp.bin
or
vbutil_what_keys bios.bin
The output should contain the strings "Stumpy MP" somewhere, if the image or
BIOS is signed with the Stumpy MP keys.
Change-Id: I575b7358ced4234c918eff40cdeb17fe06ab331c
Reviewed-on: https://gerrit.chromium.org/gerrit/15271
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This check-in splits the cgpt into two layers. The top layer (cmd_* files) does
the command-line parsing and the bottom layer (cgpt_* files) does the actual
cgpt work.
This is done so that the bottom layer can be reused for the monolithic
C++ post-installer code that will be done in subsequent checkins.
BUG=chromium-os:25374
TEST=Tested with existing cgpt unit tests as well as running the cgpt commands manually.
Change-Id: I69a31eb3e867a1430cac9a694581331368aa7bb4
Reviewed-on: https://gerrit.chromium.org/gerrit/14940
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
The fix for chrome-os-partner:7715 introduced a new bug. This fixes that.
BUG=chrome-os-partner:7775
TEST=manual
Boot into recovery mode.
Insert invalid USB.
You should see the YUCK screen.
Change-Id: I868287eecd34bb0c48127bee04f573b418f5945c
Reviewed-on: https://gerrit.chromium.org/gerrit/14963
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
export them as a library to be used by post installer programs.
A matching change to vboot_reference-9999.ebuild is also required.
TEST=Built, verified library symbols with nm on x86-mario, amd64-generic.
BUG=chromium-os:25381
Change-Id: Icb23838a8cd804e0c66718c6d4d60f639ee6b72f
Reviewed-on: https://gerrit.chromium.org/gerrit/14770
Commit-Ready: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Previously, it was going to recovery only when no disks existed. That didn't
catch the case where disks exist but none of them are usable.
BUG=chrome-os-partner:7715
TEST=manual
I've added a test specifically for this, so just
make
make runtests
should verify it.
To test on actual hardware, find a disk or USB drive that has something
other than 512 bytes per LBA, and try it. It won't be bootable, but using it
shouldn't hang the system or cause weird behavior.
Once in recovery, press TAB, and you should see the reason code
VBNV_RECOVERY_RW_NO_DISK
Change-Id: I475ddd01e13fa806025a2107c260c030d098a17e
Reviewed-on: https://gerrit.chromium.org/gerrit/14816
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
On x86 platforms, the power button and lid switch events have to be handled
by coreboot SMM code, because it needs to interact with the southbridge
and/or EC, and U-Boot doesn't have a way to do that. Once the kernel takes
over, it sends an SMI to that code which tells it to start delivering ACPI
events instead of whatever pre-ACPI handling it has been doing.
U-Boot doesn't have any code to handle either case, and adding it would
either be a major undertaking (adding ACPI support to U-Boot!), or would
require creating yet another special-purpose interface just for our U-Boot
(yuck).
It's much simpler to just make vboot_reference be more aggressive about
writing to the nvram for this one case where it matters.
OTOH, ARM will need U-Boot to handle the lid switch and power button via
GPIOs since it uses only U-Boot and has no SMI handler. This change isn't
necessary for ARM, but shouldn't hurt either.
BUG=chrome-os-partner:7689
TEST=manual
1. Boot to dev-mode screen or recovery screen.
2. Press arrow keys to change locale.
3. Power off (press power button or yank A/C & battery)
4. Power on again.
The BIOS screen locale should still be set to your last choice before
powering off.
Change-Id: I9008811c3be71de47ff1c6899e81955cf0560a52
Reviewed-on: https://gerrit.chromium.org/gerrit/14721
Tested-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The VBDEBUG() is logged even for production builds (visible as
/sys/firmware/log once the system boots). Too many messages clutter it up.
BUG=chrome-os-partner:7669
TEST=manual
Boot in dev-mode, log in and look at /sys/firmware/log. You shouldn't see
more than dozen lines or so of VbAudio debug messages.
Change-Id: I00465c0092d49feaa8d94aa8a13acbfa1e07743d
Reviewed-on: https://gerrit.chromium.org/gerrit/14603
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:7428
TEST=manual
Switch to dev-mode, turn it on, see how long it takes.
With gbb.flags == 1 (factory mode), it should take 2 seconds.
(You'll see a warning on the screen if gbb.flags is nonzero)
With gbb.flags == 0 (after factory install), it should take 30 seconds.
You should hear two beeps at 20 seconds.
Change-Id: I4f14128b87d3482e291b1b40a11a6d27c72c1ad1
Reviewed-on: https://gerrit.chromium.org/gerrit/14534
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
This adds in logic to check that ReadFdtBlock within ReadFdtPlatformFamily
succeeded, returning NULL on failure.
BUG=None
TEST=Manual, run crossystem on an ARM system without a valid compatible FDT
entry and ensure (error) is returned for platform_family.
Change-Id: I6351292ff73e4bc08b028f85e72ccfe62159194a
Reviewed-on: https://gerrit.chromium.org/gerrit/14321
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
When the user hits Ctrl+U on the dev screen, we used to change the
screen only after we enumerate the USB devices, load the kernel from USB
mass storage and boot it (about 4 seconds on the current firmware).
Let's blank the screen earlier to show we got the key press.
BUG=chrome-os-partner:7563
TEST=on a Stumpy in developer, hit Ctrl+U on the dev screen with an
invalid key, then a valid key. Check which screen are displayed and how
long it takes to get a new display after the key strokes.
Change-Id: Ifc73b56055bcd50360d71c1cb6dee052d0fdf9aa
Reviewed-on: https://gerrit.chromium.org/gerrit/14395
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This extends the ReadFdtBlock function for ARM to allow for a direct path
to a FDT entry by starting the property with a '/'. This allows the
ReadFdtPlatformFamily function to use a direct path instead of stepping back
through folders, and will enable future crossystem entries to do the same.
BUG=chromium-os:24669
TEST=Manual
Change-Id: Ibddb881815947259c2532d7f5474eda5fdc9f803
Reviewed-on: https://gerrit.chromium.org/gerrit/14305
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
This implements a platform_family value within the crossystem utility,
as the platform (particularly for ARM) is not easily accessable elsewhere at
runtime.
For the ARM side this contains a table which is used to determine the platform
family based on the /proc/device-tree/compatible entry. Similarly on x86 the
table is used to check against PCI entries. Additional entries can be made
as new platform families emerge.
BUG=chromium-os:24669
TEST=Manual, verified that crossystem runs properly and returns a valid
platform_family value on various platforms (mario, alex, z600, x220, etc).
Change-Id: Id0e973902d27ead471c1243bcc6c3292acc8479d
Reviewed-on: https://gerrit.chromium.org/gerrit/13520
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
Add ability to report a single PCR value via the tpmc utility. Using
/sys/devices/platform/tpm_tis/pcrs is too slow, since it reads all
PCRs before returning. Anything wanting to read PCR0 on a time-critical
path needs maximum speed.
BUG=chromium-os:22172
TEST=install and test x86-alex.
Change-Id: I2d450961d33fa314d54b909135a74aa756279ec6
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/13891
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
The test is run on a recovery image by the signer. We care more about the
parameters on the kernel partition 4 (the SSD install kernel) than 2.
It'd be nice to have security test on the recovery kernel too and I have
marked that as a TODO for now.
BUG=chromium-os:24077
TEST=tested on a R17 and R18 mario, alex and zgb image.
Change-Id: Ia27ceaefb24dff64115f08b1cc6bbb75d1900071
Reviewed-on: https://gerrit.chromium.org/gerrit/12970
Reviewed-by: Jim Hebert <jimhebert@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Correctly handle the lack of valid dm config parameters in the kernel
command line (dm="..."). In particular, skip trying to perform a rootfs
hash update for that kernel partition.
This change has the side effect of properly signing new recovery images
with the in-flight changes recovery install changes being done as part of
crosbug.com/22530.
Also fix verification of recovery images to consider both kernel partitions
for determing the hash to compare the calculated value against.
Finally, remove dd's verbose output while signing the firmware.
BUG=chromium-os:22530
TEST=manually re-signed new (Alex) and old (Lumpy) recovery image. Verified
that recovery install works.
Change-Id: Ied9f82f2e77ed581875cec0b43ce45fd98186db2
Reviewed-on: https://gerrit.chromium.org/gerrit/12588
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
We recently fixed a bug in the sign_firmware.sh script to perform
root key replacement after signing FWA and FWB to allow
resign_firmwarefd.sh to correctly determine the preamble flag to use.
As it turns out, the sign_official_build.sh script used by the signer
for in-place firmware re-signing was using a different code path (by
directly calling resign_firmwarefd.sh).
This change makes sign_official_build script call sign_firmware.sh instead.
BUG=chrome-os-partner:6874
TEST=tried signing a vanilla lumpy image with and without the fix, and
observed the value of preamble flag used.
Change-Id: Icffb1d86fbe44f69e444da51fe251ad3427635c6
Reviewed-on: https://gerrit.chromium.org/gerrit/12471
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
If the FW_A and FW_B contents are the same, we should not resign with
DEV/NORM keyblocks.
BUG=chrome-os-partner:6942
TEST=(to sign) ./resign_firmwarefd.sh bios.bin new.bin \
../../tests/devkeys/firmware_data_key.vbprivk
../../tests/devkeys/firmware.keyblock \
../../tests/devkeys/dev_firmware_data_key.vbprivk \
../../tests/devkeys/dev_firmware.keyblock \
../../tests/devkeys/kernel_subkey.vbpubk
(to verify) dump_fmap -x new.bin
vbutil_keyblock --unpack VBLOCK_A | grep Flags
vbutil_keyblock --unpack VBLOCK_B | grep Flags
When the input (bios.bin) have DEV FW (ex, zgb/alex), then output
is A=6, B=7; when the input is old or new firmware without DEV
(ex, mario/s*y/l*y), output is A=7, B=7, and you'lll see
"Found firmware with same A/B content - ignore DEV keyblock."
meessage during resign process.
Change-Id: I10cbbf7370f35a40673b328b70c83e7d1213a45d
Reviewed-on: https://gerrit.chromium.org/gerrit/12371
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BUG=chrome-os-partner:1113
TEST=manual
With the dev-switch OFF, insert a bootable USB drive, reboot while holding
down recovery button. It should boot from the USB without prompting for
removal.
With the dev-switch OFF and the same bootable USB drive inserted, run
crossystem recovery_request=2
reboot
The BIOS screen should prompt you to remove the USB drive, then to insert it
before it will boot from the USB.
Prior to this fix, using recovery_request=2 would NOT require removal, while
other non-zero values would. NO values of recovery_request should be able to
override the removal request. Only physically pressing the button should
allow booting immediately from recovery mode with the dev-switch OFF.
Change-Id: I6d63ecb761c4b26820091cc7a97ca540b362c22e
Reviewed-on: https://gerrit.chromium.org/gerrit/12143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This changes the Makefile to set the BUILD directory only if the caller
does not specify it.
This allows U-Boot to build vboot reference and put the resulting binaries
into its own output directory.
BUG=chromium-os:16808
TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario
Change-Id: I6b0bba47e397f86a130e67c4e18fbcf5fffdfd68
Reviewed-on: https://gerrit.chromium.org/gerrit/11638
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Since x86 and amd64 boards use the same firmware and are otherwise identical
use the same implementation for crossystem on both
BUG=chromium-os:21386
TEST=emerge-x86-generic ; test crossystem works on Samsung Series 5
TEST=emerge-amd64-generic ; test crossystem works on Samsung Series 5
TEST=run unit tests on build machine with:
RUNTESTS=1 make
Change-Id: Ica516cca7ead6cb9cdfae0894bd532669ba3ba88
Reviewed-on: https://gerrit.chromium.org/gerrit/12059
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
For key generation, only generate dev firmware keyblocks, if the
--devkeyblock option is passed. For signing, re-use normal firmware
keyblock and data key if no dev keyblocks or data key are found in
the keyset directory.
BUG=chrome-os-partner:6942
TEST=manual
- tested key generation with/without the new flag
- tested signing with or without the presence of dev keyblock
Change-Id: Ic4bf72cb194461e07fcc0f6de39d4e16d1c979a6
Reviewed-on: https://gerrit.chromium.org/gerrit/12038
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
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>
BUG=chrome-os-partner:1113
TEST=manual
With the dev-switch OFF, insert a bootable USB drive, reboot while holding
down recovery button. It should boot from the USB without prompting for
removal.
With the dev-switch OFF and the same bootable USB drive inserted, run
crossystem recovery_request=1
reboot
The BIOS screen should prompt you to remove the USB drive, then to insert it
before it will boot from the USB.
Change-Id: Ie2fe4302443e14b1f85f409b54aa43a94d6c5477
Reviewed-on: https://gerrit.chromium.org/gerrit/11788
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
resign_firmwarefd.sh needs a verifiable copy of the firmware (and associated root key)
to determine the preamble flag value to use.
BUG=chrome-os-partner:6874
TEST=manually tested resigning a firmware .bin using sign_firmware.sh. Verified correct
preamble flag determination.
Change-Id: Ifb132f54f4891dec4fa7250d3a00e7b4feda24c1
Reviewed-on: https://gerrit.chromium.org/gerrit/11776
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gaurav Shah <gauravsh@chromium.org>
