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>
Some functions of vboot are disabled for sandbox because sandbox could not
support them. This has changed, so remove the sandbox #ifdefs in the code.
Some printf() strings cause warnings on sandbox - mostly that uin64_t is
not 'long long' on a 64-bit machine. The existing format strings in U-Boot
do not seem to take account of this, so add casts to remove the warnings.
Also add a few more debug strings to make it easier to see what is happening
in the vboot flow.
BUG=chrome-os-partner:21115
BRANCH=pit
TEST=manual
crosfw -b sandbox -V
See there are no warnings.
Change-Id: I86f90a693e4bd23fcacf6d48297dd32229348dd4
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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
%L is, in some standard libraries like U-Boot's, a synonym for %ll which is
for long long integers, required by the C99 standard to be at least 64 bits.
For practical purposes that basically means %ll should be used with 64 bit
values. Since %L seems to be non-standard and, at least in U-Boot's case, %ll
is recognized in the same way, %ll seems preferable.
BUG=chrome-os-partner:8339
TEST=Booted ChromeOS using depthcharge and U-Boot. Booted with
depthcharge/libpayload which does not support %L and saw a number where %L had
been printed.
BRANCH=None
Change-Id: Id51fb5c9295e0dd65b42a5c0738eb34c8210a2b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/32660
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>
Based on the compile-time constants, I don't think we were in any danger,
but I've added the checks anyway. It never hurts to be certain!
BUG=chromium-os:22786
TEST=none
Change-Id: I469dda19b4589e484a41ca9bae1e107787f3cf4d
Reviewed-on: https://gerrit.chromium.org/gerrit/11516
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
