This will be used in subsequent CLs to support PD software sync. For
now, only devidx=0 is used.
This changes the external vboot API, so must be checked in at the same
time as changes to the u-boot and depthcharge implementations. For
now, those implementations should simply check if devidx=0 and fail if
it's not.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:208195,CL:208196
Change-Id: Iad3be9d676ac224c4582669bcd67176b39f75c73
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208210
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For displaying GBB images on panels with different dimension, X86 has VESA mode
and VBIOS to scale automatically but ARM does not have such mode settings. If we
install a larger panel on ARM platforms, current firmware will render the
screens in left-top corner and leave black borders in right-bottom corner.
To render images correctly, vboot library has to send out the expected dimension
(similar to the VESA mode) so display provider can scale or shift images.
BUG=chrome-os-partner:28494
TEST=emerge-nyan vboot_reference
CQ-DEPEND=CL:199051,CL:199045
BRANCH=none
Change-Id: I6d60f755ca2bcbd3135631d7624a8a4a4cff68b1
Reviewed-on: https://chromium-review.googlesource.com/199043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
We don't allow ENTER from a USB keyboard as the confirmation
in the switch from normal to developer mode.
For devices that have a physical recovery button, we require
a recovery button press instead. For other devices, we
require that ENTER be pressed on the internal keyboard.
This prevents an "evil keyboard" attack in which a USB keyboard
(or other USB device pretending to be a keyboard) sends a
control-D/ENTER sequence shortly after every boot (followed
by more evil keys). In that situation, when users power-on in
recovery mode, they will be forced to dev mode even if it
was not their intention. Further attacks are easy at
that point.
TESTING. On a panther device:
1. powered on with recovery button pressed -> booted in recovery mode
2. pressed control-D on external USB keyboard -> got to ToDev? screen
3. pressed ENTER -> system beeped
4. pressed recovery button -> system rebooted in DEV mode
... all as expected
Also:
1. powered on with recovery button pressed and HELD recovery button
2. pressed control-D -> system beeped
BUG=chrome-os-partner:21729
TEST=manual (see commit message)
BRANCH=none
CQ-DEPEND=CL:182420,CL:182946,CL:182357
Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7
Reviewed-on: https://chromium-review.googlesource.com/182241
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
TEST=Built and booted Peppy. Ran flashrom from user space and
verified the EC firmware was updated after reboot.
CQ-DEPEND=CL:172651, CL:172652, CL:178324
BRANCH=none
BUG=chromium:325286
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ia73da70dbf3abb5ced48666e86715c8d24a431a0
Reviewed-on: https://chromium-review.googlesource.com/172635
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: If2b8bbe467fdbd643239d8d9b5d7aa98df4d286f
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167361
At present reading data from storage in Vboot is a little fragmented. For
the firmware image, we expect the boot loader to handle this. For the disk
we have a block-level API. For the GBB (which also sits in the firmware
image) we expect the entire thing to be read before Vboot is called.
Add the concept of a region, and an API to read from a region. At present,
and most pressing, is reading from a GBB region. In the future this could
be extended to other parts of the firmware or even the disk.
Move all access to the GBB into this API so that the boot loader can provide
either a GBB region in one large contiguous chunk, or a function to deal with
read requests from vboot.
The call to VbExRegionRead() is behind a flag since not all boot loaders
support it yet.
The main change for boot loaders which don't support this new API is that
vboot will do more behind the scenes. For example, it will allocate memory
for chunks of data that it reads from the GBB, rather than just accessing it
directly. This approach is considerably simpler than trying to pass char **
everywhere and have vboot decide whether something needs to be allocated or
not.
The tests are updated, mainly to include setting up a GBB structure
accessible from VbCommonParams, which is now required by the firmware and
kernel functions. In normal operation this is set up at the start of
VbLoadFIrmware() and VbSelectAndLoadKernel() but for tests which call
children of these functions directly, the GBB structure must be set up
manually by the test.
BUG=chrome-os-partner:21115
BRANCH=none
TEST=manual
FEATURES=test sudo -E emerge vboot_reference
Change-Id: I2c19e9dc2ed602d0642bbf4f7d27f79fe9fad873
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/63336
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This tells the boot loader the number of firmware types that are supported,
so that it can declare arrays of that size.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
Build for pit, link, daisy
Change-Id: Ib10e559af29b8dfe78268eb6e0465a245427313e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66095
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
In many cases format strings in vboot_reference do not match their
parameters, which causes all kind of ugly results when examining debug
output.
Enforce proper format verification.
CQ-DEPEND=CL:65396
BRANCH=pit
BUG=none
TEST=manual
. compiled cleanly in vboot_reference, observed debug printouts
making sense.
Change-Id: I58d5ba1f9097ef9922fbaeb7a9946aadf5eb8617
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65394
This is used by vboot to retrieve the precomputed hash of the expected
EC image, which requires reading less data from EEPROM than getting
the entire EC image.
BUG=chrome-os-partner:17606
BRANCH=spring
TEST=none; just a new API not used yet
Change-Id: I226643144280acabba147d345ef1f83a77a91fbc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42566
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>
We have to define the function we need here, so that we can implement it in
U-Boot, then we can come back here and try to use it. Grr.
BUG=chrome-os-partner:11215
BRANCH=link
TEST=none
This just defines the function prototype. No change to test.
Change-Id: I38a19baa54c59c9744d20f743eb53260f2d19852
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We need to know not only whether the HW WP pin is asserted, but whether the
flash chip has configured its software protection registers to actually
protect anything. This flag can be used to indicate that.
BUG=chrome-os-partner:13265
BRANCH=link
TEST=none
This just adds the flag. Nothing actually sets the flag yet, so there's
nothing to test.
Change-Id: Icba9945fb56eb3a4681486c630cbbdc9232485ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31642
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We need to alert user his change has been accepted for 5 seconds.
BUG=chrome-os-partner:11078
TEST=emerge-daisy vboot_reference-firmware vboot_reference chromeos-u-boot chromeos-boogimage
Change-Id: I6a3b13e7543479fbd6543d759093ecf501fb1d04
Reviewed-on: https://gerrit.chromium.org/gerrit/29982
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@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>
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
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 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>
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>
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>
Nothing uses this yet; this is just a placeholder so the u-boot code
which sets the flag based on the FDT can go in.
BUG=chrome-os-partner:11087
TEST=if it builds it works
Change-Id: Ie04e3330bcda5c07d34a49391627316bd6232b5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26874
Reviewed-by: Simon Glass <sjg@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>
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>
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>
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>
This adds a flag to the list of values returned by VbInit(). When
this flag is set, the BIOS may be asked to boot something other than
ChromeOS. If this requires some sort of special preparation, the BIOS
should do it.
BUG=chromium-os:22454
TEST=none
There is no test for this. It requires a change to the BIOS in order
to do anything differently, and we haven't yet decided whether the
BIOS should pay attention to it.
Change-Id: I5d89e7cd5b745ee74b8ace7fa613c0db03eebefd
Reviewed-on: https://gerrit.chromium.org/gerrit/11714
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
As shipped, H2C only loads the option ROM for the built-in video, and that
only when it needs display the BIOS warning screens.
By setting a flag in the GBB, you can allow all option ROMs to be loaded:
Note that we'll never enable this ourselves (and there's a factory test to
ensure that*) because it executes non-verified code. But if a customer wants
to void their warranty and set this flag in the read-only flash so they can
install and use other PCI devices, they should be able to do so.
BUG=chrome-os-partner:6148
TEST=none
The only way to test this is to use a BIOS that was compiled with serial
debugging enabled, so there's nothing for QA to do. If you have such a BIOS,
you can see the difference like so:
flashrom -r oldbios.bin
gbb_utility -s --flags=2 oldbios.bin newbios.bin
flashrom -w newbios.bin
<reboot>
When bit 1 of the GBB flags is 0, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
When bit 1 of the GBB flags is 1, you'll see these lines in the serial
output:
LoadOpRomImage-->GetSystemConfigurationTable Status = Success
LoadOpRomImage-->GetH2cBootMode Status = Success
LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!!
This happens in any boot mode (normal, developer, recovery).
--
*The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in
src/platform/factory_test_tools
Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a
Reviewed-on: https://gerrit.chromium.org/gerrit/11505
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This enables us to support playing sounds in the background if the BIOS
allows it, so we don't have to block while beeping is happening. The new
declaration is:
VbError_t VbExBeep(uint32_t msec, uint32_t frequency);
If the audio codec can run in the background, then:
zero frequency means OFF, non-zero frequency means ON
zero msec means return immediately, non-zero msec means delay (and
then OFF if needed)
else:
non-zero msec and non-zero frequency means ON, delay, OFF, return
zero msec or zero frequency means do nothing and return immediately
The return value is used by the caller to determine the capabilities. The
implementation should always do the best it can if it cannot fully support
all features - for example, beeping at a fixed frequency if frequency
support is not available. At a minimum, it must delay for the specified
non-zero duration.
Currently, VbExBeep() is called only when displaying the dev-mode screen.
BUG=none
TEST=manual
I've tested on x86 and ARM, all timeouts and noises work as before.
Note that ARM and coreboot will require a corresponding change to their
VbExBeep() implementations, which will have to be handled with separate,
simultaneous CLs.
Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d
Reviewed-on: http://gerrit.chromium.org/gerrit/8234
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The vboot library needs to decompress the images so that it can handle those
that are special cases (like rendering the HWID). This means that 1) it
needs access to the BIOS' native decompression routine, and 2) that
VbExDisplayImage() only needs to handle the uncompressed native-format image
and doesn't need to know about how the image is packed in the GBB.
BUG=chromium-os:19134
TEST=manual
This requires a change to vboot_api.h, which requires a (simultaneous)
matching change to the BIOS, at least for U-Boot, which builds separately.
I've made that change and run the "vbexport_test display" command from the
modified U-Boot, but that also requires a change to the way U-Boot is built
so that I can get at the U-Boot commandline.
Change-Id: I449fb467cd3a68e742f27ec41b95d52685459d89
Reviewed-on: http://gerrit.chromium.org/gerrit/6129
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This also fixes one place where TPM error codes were getting lost.
BUG=chromium-os:18132
TEST=make && make runtests
Change-Id: I83c74e1103805f166d1dc7448be7d67bd46d15b3
Reviewed-on: http://gerrit.chromium.org/gerrit/4659
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The old (v2.0) parser is compatible with new (v2.1) structs. That is,
this won't break existing firmware or vbutil_firmware.
A new (v2.1) parser parsing an old (v2.0) struct will return 0 for the
flags.
This will be used to support the RO-normal code path in a subsequent CL.
BUG=chromium-os:17304
TEST=added unit tests; make && make runtests
Change-Id: I73bcd8acd3330b0d7d143061b5ef838e6d79cf1a
Reviewed-on: http://gerrit.chromium.org/gerrit/4030
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Pressing Tab at a firmware screen now displays real data, including
the recovery reason, HWID, and contents of VbNvStorage.
Entry point start/end time tracking in VbSharedData now refers to the
new wrapper APIs.
Added capability for calling firmware to request recovery mode (for
example, if it's unable to initialize RAM, can't find the SSD, etc.).
Previously, calling firmware had no (good) way to do this other than
faking the recovery button being pressed.
BUG=chromium-os:17018
TEST=emerge on x86 and tegra2_seaboard
Change-Id: I7d377f279842b30a10d945d13571c41c464633f1
Reviewed-on: http://gerrit.chromium.org/gerrit/3814
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
New APIs for the wrapper funtions (VbSelectFirmware() and
VbSelectKernel()) and the APIs for the firmware services they need.
BUG=none
TEST=none
Change-Id: Id8ddc456d062095b12495dd534e21342b5490aee
Reviewed-on: http://gerrit.chromium.org/gerrit/2195
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
