These were macros that were never used, or that were only set to one thing and
could be substituted up front.
I left in code guarded by the HAVE_ENDIAN_H and HAVE_LITTLE_ENDIAN macros even
though those are never defined because they guard a reportedly significantly
faster implementation of some functionality, at least according to a comment
in the source. It would be a good idea to enable that code path and see if it
really does make a big difference before removing it entirely.
BUG=None
TEST=Built for Link, Daisy, and the host with FEATURES=test. Built depthcharge
for Link and booted in normal mode.
BRANCH=None
Change-Id: I934a4dd0da169ac018ba07350d56924ab88b1acc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/45687
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This makes it more obvious which modules and VbEx*() functions must be
implemented to call these entry points.
This change only moves functions between modules and adds two
link-test binaries; it doesn't change any functionality.
BUG=chromium-os:39262
BRANCH=none
TEST=make && make runtests
Change-Id: If3edf0b1989b631f0e7ad18de7ccdad8315181b5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/44076
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the need to load the EC code at all when the precomputed
hash matches.
BUG=chrome-os-partner:17606
BRANCH=spring
TEST=wouldn't that be nice
Change-Id: If4438b9db8b1449b8fd4d90ef3acb3bbec5e09a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/42567
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>
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>
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: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 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 is part 2 of the wrapper API refactor. It adds stub
implementations for the host, and changes the host-side utilities to
use them. Firmware implementation is unchanged in this CL (other than
a few updates to macros).
BUG=chromium_os:16997
TEST=make && make runtests
Change-Id: I63989bd11de1f2239ddae256beaccd31bfb5acef
Reviewed-on: http://gerrit.chromium.org/gerrit/3256
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
