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 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>
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>
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>
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>
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>
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>
This reverts commit 552ae43be0.
vboot should set up dev switch value in output flag of VbInit, instead
of exposing TPM getter to U-Boot.
BUG=chrome-os-partner:10947
TEST=build okay for Snow and Alex
Change-Id: Iee884dbf758fef0cacfed6bcbab373ab5ec5aa25
Reviewed-on: https://gerrit.chromium.org/gerrit/26556
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Firmware needs to be able to read virtual dev switch to set up device
tree blob which is passed to kernel and eventually read by crossystem.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BUG=chrome-os-partner:10947
TEST=With this change, U-Boot can read virtual dev switch.
Change-Id: Ifac2ec3d39b8e9c1100031fdef085c28bb8b37c7
Reviewed-on: https://gerrit.chromium.org/gerrit/26394
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
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>
The VbExTrustEC function should be implemented in the BIOS, not the vboot
library. Also, weak references don't seem to work with our linker, so we'll
have to just require it always.
BUG=chrome-os-partner:9953
TEST=none
This must go in with a simultaneous change to U-Boot. The only test is
whether or not everything continues to compile.
Change-Id: I8a5ccb167eec3bcacbe892cf0bdcfe550a1f57d6
Reviewed-on: https://gerrit.chromium.org/gerrit/25557
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
And enable dev_boot_usb by default.
And disable rollback checks.
The first flag is necessary for factory to build with keyboard
controlled dev mode. The other flags are really handy for development
on systems where you've defeated firmware WP and are installing custom
firmware.
BUG=chromium-os:31844
TEST=make && make runtests
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I9d837fee676cb0186ea98f13005ad60a9ab86393
Reviewed-on: https://gerrit.chromium.org/gerrit/25265
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Since the "ownership" permament flag does not indicate if the TPM is
currently owned, the state of TPM Ownership must be read via a Capability
read of TPM_CAP_PROP_OWNER. This adds the "getownership" function.
BUG=chromium-os:22172
TEST=x86-alex build & manual test
Change-Id: I2fc9e933e891ba40190d008436b22496dced1c93
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/24784
Reviewed-by: Will Drewry <wad@chromium.org>
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>
Fixes build failure seen in u-boot for tegra2 seaboard:
.../vboot_fw.a(vboot_api_kernel.o): In function 'VbConfirmChangeDevMode':
(.text+0x84): undefined reference to 'SetVirtualDevMode'
BUG=None
TEST=`emerge-tegra2_seaboard chromeos-u-boot` works again
Change-Id: If374a78218fc8a7921ff8dddde163138969e0876
Reviewed-on: https://gerrit.chromium.org/gerrit/24948
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
BUG=chrome-os-partner:9706
TEST=manual
Currently, Link is the only platform that enables this feature.
To enter dev-mode:
Boot into recovery mode using the magic key chord. At the Insert screen,
press Ctrl-D. You'll be asked if you want to enter developer mode. If you
then press ENTER, it will reboot with dev-mode enabled. If you press SPACE
or ESC, it will return to the Insert screen.
If you enter recovery mode through any other means, or if dev-mode is
already enabled, pressing Ctrl-D at the Insert screen will have no effect.
To return to normal mode:
Reboot. At the Dev screen, press ENTER or SPACE. It will reboot to
recovery mode and ask you if you want to return to normal mode. If you
press ESC or power off, you'll still be in dev-mode. Press ENTER or SPACE,
and it will reboot into normal mode (of course, if you've messed up your
images while in dev-mode, you'll just come right back to recovery mode
again).
You can also request a direct return to normal mode by running
crossystem disable_dev_request=1
and rebooting.
Change-Id: I435905855a6c39932ee466cc046bdc4c4c860f98
Reviewed-on: https://gerrit.chromium.org/gerrit/24160
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:9706
TEST=none
No test yet. The entire boot/dev-mode/recovery flow depends on this working.
This is only part of the process, which will eventually be tested through
FAFT.
Change-Id: Iea6eaf59d4f349590cf9b920e4effb6a2641b2dc
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23657
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When linking tools that need OpenSSL functions on the target, the
resolution of SHA* functions was being redirected to the firmware
cryptolib instead of the OpenSSL implementations, which was causing
OpenSSL calls to crash. This renames the internal implementations
to avoid the collision.
BUG=None
TEST=make runtests passes, mount-encrypted runs on target again.
Change-Id: Ica4fb04faf203ae3b4118c540f18d40239753810
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23305
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If VbInit() is instructed to look at a virtual dev-mode switch, then it will
use value contained in the TPM's firmware space instead of a hardware GPIO
to determine if developer mode is enabled.
This change just makes it look. It doesn't provide a way to actually set
the value in the TPM. VbInit() isn't being told to look yet, either. Those
changes are coming.
BUG=chrome-os-partner:9706
TEST=none
The usual sanity-check applies:
make
make runtests
But to actually test that this stuff is working IRL requires special tweaks
to other components and monitoring the serial debug output from both EC and
CPU. We'll save the hands-on tests for when it's all done.
Change-Id: Ie485ad2180224e192238bf2a5dbf95bbcb9130f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/23067
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
This macro is only defined by the EC firmware build process, and is used to
cut down the amount of compiled code. A future CL will refactor the library
to make this unnecessary.
BUG=chrome-os-partner:7459
TEST=manual
make
make runtests
Change-Id: I41d0b4b282ec7147e8d6f508531af32e74f2d19e
Reviewed-on: https://gerrit.chromium.org/gerrit/22313
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This just adds the vbutil_ec tool (and a simple test of the library
functions related to it).
BUG=chrome-os-partner:7459, chromium-os:27142
TEST=manual
make
make runtests
Change-Id: I2a2c4e7cfb8ac6ce2229c5de4252a5cc89321fa5
Reviewed-on: https://gerrit.chromium.org/gerrit/21868
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Omit this check because this check is not really necessary and it is
dealing more harms than goods to ARM boards.
While body load address is configurable, it is not quite possible to fix
all the build scripts and runtime scripts to carry this address; so in
reality all scripts use the default body load address.
The problem is, this default address is not friendly to ARM boards, and
it virtually makes this check fails on ARM boards.
BUG=chromium-os:28077
TEST=emerge-{daisy,x86-alex} vboot_reference
TEST=load_kernel_test -b 1 chromiumos_image.bin
TEST=run verified boot on Daisy
Change-Id: I1a1cc0aedf254e2a2b680046812ab7154f26dea7
Reviewed-on: https://gerrit.chromium.org/gerrit/20947
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
When the filesystem resizing process starts, it has the TPM open,
which means it can collide with tcsd after the main process exits.
Additionally, improve the debugging around TPM usage for better timing
analysis.
BUG=None
TEST=lumpy build & manual testing
Change-Id: I7028131015fb972c99e8b3d035f58346f08fbd06
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19535
Reviewed-by: Elly Jones <ellyjones@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>
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>
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>
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>
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>
