X86 (coreboot) uses 800x600 resolution while ARM systems (uboot) initialze LCD
as its maximum size, so we must refine the bmpblk build scripts to generate
output with different scaling parameters.
BUG=chrome-os-partner:11078
TEST=make # got ARM bmpblock and verified to work on daisy.
Change-Id: Ib9e9a0dc3b6695cef451772391f207a5b57977df
Reviewed-on: https://gerrit.chromium.org/gerrit/29606
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
To support rendering messages in multiple resolution profiles, we need to keep
the images in its original format.
BUG=chrome-os-partner:11078
TEST=./text_to_png # images were converted correctly.
Change-Id: I6e13331eddfa4c40b17b67b5cf56b5a0284e3b34
Reviewed-on: https://gerrit.chromium.org/gerrit/29605
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
NOTE: Only the "launch countries" have a full set of updated
text strings...and those strings were translated via
translate.google.com and need fixing-up prior to use in a
real product.
BUG=chrome-os-partner:11078
TEST=install bmpblock_x86.bin into a firmware image with
gbb_utility -s -b bmpblock_x86.bin image.bin
Verify the four firmware screens are displayed correctly.
Original-Change-Id: Ib8ff142e9a938a6a3bf949153594cc013c8bb311
Reviewed-on: https://gerrit.chromium.org/gerrit/28574
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
(cherry picked from commit 7c41920b754cb0d18da9a125f76d3f1ef90e04f4)
Change-Id: I534beaea5be95b549a6305d4b2911abeb983e034
Reviewed-on: https://gerrit.chromium.org/gerrit/29603
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This is to avoid confusion with the canonical common.mk file that is
a CrOS build system.
BUG=chromium-os:33327
TEST=`cros_run_unit_tests --board x86-alex -p vboot_reference` still works
Change-Id: I4b6719d58a4a8ab44b62c23c0e2c45b154374958
Reviewed-on: https://gerrit.chromium.org/gerrit/29578
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Since we've moved away from flag-files in session manager to
enable certain dev/test-mode features, our strategy of checking
for those flag files on the signer fell behind. This test adopts
a scheme that any use flag starting with "test_" or "dangerous_"
is blacklisted from release signing.
BUG=chromium-os:32430
TEST=ran the script against both a 'base' and 'test' image
from the builder/ToT. Passes/fails as expected.
Change-Id: I54d6ef17d52371c7543d5705e0939e000db85e51
Reviewed-on: https://gerrit.chromium.org/gerrit/29034
Reviewed-by: Chris Masone <cmasone@chromium.org>
Tested-by: Jim Hebert <jimhebert@chromium.org>
Commit-Ready: Jim Hebert <jimhebert@chromium.org>
Some EC's are slow to program their firmware. This could happen at any boot
as part of software sync. This adds the VB_INIT_FLAG_EC_SLOW_UPDATE input
flag to VbInit(), so that vboot knows to display the EC-is-being-programmed
screen when that flag is set.
BUG=chrome-os-partner:12255
TEST=none
This isn't activated yet by anything, so there's nothing to test.
Change-Id: Id4d12e463fcdee017b7c52b53a2facefc33b745f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29370
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The encrypted partition has been plagued with TPM problems, which means
systems that have a wedged TPM, or interrupt the TPM Ownership, Lockbox
creation, etc, all fail to keep the encrypted partition across a reboot.
As a result, we're forced to write the encryption key to disk initially,
and then throw it away once the system key from NVRAM can be used to
encrypt it.
On most systems that have a sane unowned TPM, the key will only be on
disk until the first login finishes and Cryptohome can Finalize the
NVRAM area. For all the other systems, they will continue to run, but
with their encryption key effectively in the clear. Technically, this
is not a regression from R21, so at least we can move forward and work
to improve this in the future.
Some attempt is made to wipe out the key, but this is especially ugly for
SSDs, since doing a "shred" just means the blocks will get moved around.
When ext4 supports "secure delete", we can move to that instead.
BUG=chromium-os:32951
TEST=alex build, manual testing
Change-Id: I9b9a0190ea0f47a277a150eb0882e4a507ff2927
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29123
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
This is more reliable than reading them through FDT/ACPI, since it reflects
the positions as shown to verified boot code.
Notes:
1. This affects ALL platforms with virtual dev switches (x86 AND arm)
2. The fix should have no effect on older platforms, but I haven't tested those.
BUG=chrome-os-partner:11805
TEST=manual
1. boot in normal mode.
devsw_boot = 0 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
2. boot in developer mode.
localhost ~ # crossystem
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 0 # Recovery mode reason for current boot
recoverysw_boot = 0 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
3. boot in developer-recovery mode using keyboard combo.
devsw_boot = 1 # Developer switch position at boot
recovery_reason = 2 # Recovery mode reason for current boot
recoverysw_boot = 1 # Recovery switch position at boot
wpsw_boot = 1 # Firmware write protect hardware switch position at boot
4. disable WP and reboot. wpsw_boot should be 0.
Change-Id: If4156b5e14c6923c5b331c7e5feaabbffe1dad37
Reviewed-on: https://gerrit.chromium.org/gerrit/29199
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The SHA256 constants and some algo definitions are currently in the
.data segment, this wastes precious RAM on the EC where read-only data
are stored in flash only.
BUG=chrome-os-partner:12271
TEST=sudo emerge vboot_reference &&
emerge-daisy vboot_reference vboot_reference-firmware chromeos-ec
and manually check the content of the .data segment in the EC binary.
Change-Id: I67b8c0f2843312651e8ac287cea2f8cb5f075453
Reviewed-on: https://gerrit.chromium.org/gerrit/29273
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Some systems take a long time to program the EC firmware (because it's
behind a really slow I2C bus or something). This could happen at any boot as
part of software sync. If it's necessary to reprogram the EC on a slow
system, we need to display a BIOS screen to the user so he/she doesn't think
it's bricked.
This CL is just to add a new default bitmap so we'll have something to
display when we need it. Nothing actually uses it yet.
BUG=chrome-os-partner:12254
TEST=none
There should be no user-visible changes. We don't invoke this screen yet.
Change-Id: Icb922f933e2e921472dbdff7a26a3ca4d58fbba3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29241
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
It was checking for /dev/dm-0, which isn't the case anymore. It now
always attempts to remove rootfs verification from the command line;
this is harmless (no-op) if it's already removed.
BUG=chromium-os:31558
TEST=manual
/usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
reboot
touch /opt/google/chrome/chrome
Change-Id: I62dc138e8d1d09bdcb16be3faab74d32c5f7675a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28506
Reviewed-by: David James <davidjames@chromium.org>
We're still working out the correct behavior for the keyboard-based
dev-mode. Before this, we rebooted into recovery mode before asking if you
wanted to return to normal mode, so if you said "no, stay in dev-mode" you'd
still be at the recovery screen.
But now the confirmation for returning to normal mode happens at the
dev-mode screen, so you never get to the recovery screen (unless normal mode
won't boot, in which case you get there automatically).
BUG=chrome-os-partner:11707
TEST=manual
First, clear the GBB flags so that you can actually test the virtual dev
switch:
/usr/share/vboot/bin/set_gbb_flags.sh 0
reboot
It should come up in normal mode.
Activate keyboard-based dev-mode as before:
- three-finger salute
- Ctrl-D at the recovery screen
- Press ENTER when asked
Now, at the DEV screen, try to leave:
- Press SPACE. It should ask if you want to go to normal mode.
- Press ESC (no). You should be back at the DEV screen again.
- Press ENTER. It should ask if you want to go to normal mode.
- Press ESC (no). You should be back at the DEV screen again.
- Press SPACE. It should ask if you want to go to normal mode.
- Press ENTER (yes). It should reboot into normal mode.
Change-Id: I99af6e7b97fb61f943bd14c8c7166571b5ccf106
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28872
BUG=chrome-os-partner:11887
TEST=manual
Boot with dev mode on. Boots normally.
Boot with dev mode on, hammering on ENTER key as soon as you release power.
Dev mode screen is shown.
Keep hammering. Dev screen will stay up as long as you do this.
Wait >2 sec.
Press ENTER. System reboots to TONORM screen.
Change-Id: I18e35b23c18a65637a84d3d1964b291e0cb5e8c5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28995
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
When factory install happens, mount-encrypted is running on a tmpfs,
which can be detected via a W_OK check on the root filesystem.
BUG=chrome-os-partner:12033
TEST=alex build, manual test
Change-Id: I7bf5eaa244a50dd2a0de51760c964e970fa8e3aa
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28960
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Force mode of created key file to 0600, and make sure there is enough
room in the decryption buffer for any possible change to the decryption
algo.
BUG=None
TEST=alex build, manual testing
Change-Id: I89dceec22683ff66b5e1f61a63f14a1db1c4e2ee
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28892
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Developers testing firmware preamble flags (usually for turn on/off RO-NORMAL
bits) need a easy way to change existing firmware, without hacking FDT source /
looking for complex script.
Also included some minor improvements:
* Always enable FORCE_DEV_BOOT_USB and DISABLE_FW_ROLLBACK_CHECK. These are
flags most developers need when leaving official signed normal firmware.
* --bmpfv is deprecated because our latest firmware now always include
official bitmaps in updater, no more DEV bitmaps.
BUG=none
TEST=./make_dev_firmware.sh -f bios.bin -t new_bios.bin --preamble_flags 0
./make_dev_firmware.sh -f bios.bin -t new_bios.bin --preamble_flags 1
Change-Id: I7ee72d32b4b7fa28f2be635fd8c7bb678852e132
Reviewed-on: https://gerrit.chromium.org/gerrit/28792
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
And space at TONORM screen no longer confirms disabling dev mode
Added Ctrl+Refresh as an alias for tonorm screen request. U-boot will
need to be enhanced to support that. Until then, many FAFT tests will
break.
BUG=chrome-os-partner:11887
TEST=manual
1. Boot to DEV screen
2. Press Enter. Nothing happens.
3. Press Space. Goes to TONORM screen.
4. Press Space. Nothing happens.
5. Press Enter. Reboots with dev mode disabled.
Change-Id: I7f61c4001c668ac916f50f931a79a107752c83b5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28851
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This could wrap before the assignment:
uint64_t = uint32_t * int;
Instead:
uint64_t = uint32_t;
uint64_t *= int;
BUG=chrome-os-partner:11643
TEST=none
Nothing to test or verify. If the security guys approve, it's fixed.
Change-Id: Ib7c9774998332ac1a29c4551bc039eaa999ee681
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28841
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
If the config file is specified in the parameter list but we aren't able
to open (or read) the file, vbutil_kernel should return an error instead
of crashing with a Segmentation Fault.
BUG=chromium-os:33087
TEST=manual
Invoke vbutil_kernel with a bogus path for the config file (--config).
Change-Id: I32dab7c381b9094f4015a554bc59989f1bb329ef
Signed-off-by: Lucian Cojocar <cojocar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28740
Reviewed-by: Randall Spangler <rspangler@chromium.org>
"cgpt show" output table can be incorrect for large hard drives due to
the number of digits in the start/size parameters. Fix by adding extra
printf padding.
BUG=chromium-os:33082
TEST=emerge, "cgpt show -q /dev/sda" on large HDD platform.
Change-Id: I21008322739f5cd4a34372a4436a71259565c6e7
Reviewed-on: https://gerrit.chromium.org/gerrit/28730
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Tammo Spalink <tammo@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Shawn Nematbakhsh <shawnn@chromium.org>
So if the EC reboots when the lid is closed (for example, it wakes
from hibernate because the AC adapter was inserted), it won't leave
the AP powered on.
BUG=chrome-os-partner:11087
TEST=manual
Reboot EC with lid closed ('reboot hard').
Should finish software sync and shut down.
Reboot EC with lid open. Boots.
Hibernate EC and wake with lid open. Boots.
Hibernate EC and wake with power button press. Boots.
Reboot into recovery mode. Boots. Press power button; shuts down.
Reboot into recovery mode. Boots. Close lid; shuts down.
CQ-DEPEND=*22578
Change-Id: I09d5331222aa10b73518f9f574ec5a32d8e6ac23
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28525
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
Necessary for updating snow EC
BUG=chrome-os-partner:11087
TEST=force an EC update by loading a slightly old EC and then a new BIOS
Change-Id: Id00257f8a67c08077a5b396cf120a056a7601671
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28436
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:11087
TEST=manual
1. Update EC to a new version
2. Rebuild EC code and chromeos-bootimage
3. Update BIOS (AP) RW firmware
4. Reboot. EC should get updated to the version in the BIOS iamge.
CQ-DEPEND=28414
Change-Id: I227d9bf7cc1f4984d6eb13b5372bcf4181ad0df5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28415
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
vboot is passing in an index but the function expects an enum.
BUG=chrome-os-partner:11765
TEST=manual
Build with serial enabled, watch what happens. Before, it does this:
ec.c: VbExEcGetExpectedRW: Unrecognized EC firmware requested.
VbEcSoftwareSync() - VbExEcGetExpectedRW() returned 65536
VbSetRecoveryRequest(34)
After this change, it should get a little further:
ec.c: VbExEcGetExpectedRW: EC-RW image offset 0 size 0.
ec.c: VbExEcGetExpectedRW: EC image has bogus size.
VbEcSoftwareSync() - VbExEcGetExpectedRW() returned 65536
VbSetRecoveryRequest(34)
Sigh.
Change-Id: Ideb5f9d70bc5f3f202a8e04a6ec718e1d674d526
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28341
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a Cr48 was upgraded from pre-R12, it will lack an NVRAM lockbox area
with no way to create one (TPM password has been thrown away already).
Detect this case and allow fallback to the other system key methods. If
it is a Cr48 running a modern OOBE, treat it like any other device and
require a modern NVRAM lockbox area.
BUG=chromium-os:32766
TEST=mario build, verified OOBE doesn't repeat, simulated pre-R12 uses UUID.
Change-Id: I2acf7ad8c5d16b1f314ba16c673fa3979a40f3de
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28231
Reviewed-by: Elly Jones <ellyjones@chromium.org>
Since /var has moved to the encrypted partition, use the real system
mount location for /var so it doesn't matter which filesystem it is bind
mounted to.
BUG=None
TEST=link build, tests pass
Change-Id: I2831949f3c1cf71765d97720b5ca64b869ec1fa4
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28033
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
EC FMAP has changed its section names because B partition has been removed. The
signing tool should now use area names "FW_MAIN" and "VBLOCK".
BUG=chrome-os-partner:11360
TEST=emerge-link vboot_reference
Change-Id: I41ff17257b5e2c8a0f4adb11088e121f94e93923
Reviewed-on: https://gerrit.chromium.org/gerrit/27970
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
On kernels prior to 3.1, the "allow_discard" option does not exist.
Allow for this by attempting to set up the table twice if the
allow_discard attempt fails.
BUG=chrome-os-partner:11529
TEST=link build, boots 3.2 ok, falls back when option is invalid.
Change-Id: I904d3770543ebdeb0eace9ffa8e6c654cf97976d
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28024
Reviewed-by: Elly Jones <ellyjones@chromium.org>
This changes the signature of the function above so that it takes an additional
parameter that specifies which EC image vboot wants. This is better than making
U-Boot decide because U-Boot doesn't really keep track of which version it is
(it peeks at internal vboot data) and vboot does.
Also, some consts were removed from the image pointer pointer. The pointer
itself will be changed in the body of the function to tell vboot where the EC
has been loaded, and the contents of the buffer will be changed because U-Boot
will have to actually load the EC there.
BUG=chrome-os-partner:11148
TEST=Built vboot_reference, vboot_reference-firmware, chromeos-u-boot, and
chromeos-bootimage for Daisy and Link and saw them complete successfully with
and without the signature for U-Boot's version of this function being updated.
That works because the function isn't actually being used yet.
Change-Id: I2814c8210eb5b3d965bb8bbf23c0f283f9e44c90
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/27755
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
For factory images, we want to be able to retain /var across reboots
without interacting with the TPM, and ultimately hold the test suite
in a pre-built image so we can avoid needing to wipe the entire
filesystem when switching modes.
BUG=chrome-os-partner:11392, chrome-os-partner:9419
TEST=link build, manual testing
Change-Id: I58aab24455670697e3df494632d5105dde75ee85
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27793
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Jon Salz <jsalz@chromium.org>
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>
This gives the AP a chance to save NvStorage data first.
BUG=chrome-os-partner:11087
TEST=none yet; API isn't used yet
Change-Id: Iae7a24958fb076039795b92d9edb73d7e6ebfc6f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27525
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
As kernel has adjusted the value of /sys/class/gpio/gpio${PORT}/ with
active_low stuff before returning it to user, crossystem should not do
another adjustment.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:11297
TEST=On Snow, run crossystem and see wpsw_boot equals to wpsw_cur.
Then invert /sys/class/gpio/gpio${PORT}/active_low value, and
see wpsw_boot does not equal to wpsw_cur.
Change-Id: I09fec89788bc4393775d5cf9763b8cebeb645ad4
Reviewed-on: https://gerrit.chromium.org/gerrit/27252
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For the record, zero is a valid GPIO port number. Unfortunately
firmware uses port zero to denote that a GPIO port is not exist.
So crossystem should not attempt to read GPIO port zero, but
return error instead.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:11296
TEST=On Snow, run crossystem and see devsw_cur and recoverysw_cur
are "(error)"
Change-Id: I70b15824f613df1e46bf152515ad4e9362c9f066
Reviewed-on: https://gerrit.chromium.org/gerrit/27251
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org>
Tested-by: Cheng-Yi Chiang <cychiang@chromium.org>
On some systems, we require the VGA option ROM to be loaded before VbInit()
is called so we can display BIOS screens. If that hasn't happened, we
request it and reboot. Alternatively, if we don't need the option ROM
(normal mode) but we've already loaded it, we un-request it and reboot just
in case there are security vulnerabilities that might be exposed.
Not all systems need preloaded option ROMs. There is an additional input
flag that indicates whether this matters or not.
BUG=chrome-os-partner:8789
TEST=manual
Using keyboard-based dev-mode, switch between normal and dev mode and back.
It should work as expected.
Change-Id: Id1d662014d47ab648c73db4b1647520801f3a0b8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
