The new TlclGetSpaceInfo function returns more detailed information
about a defined NVRAM space. The existing TlclGetPermissions function
is now using TlclGetSpaceInfo behind the scenes.
BRANCH=None
BUG=chromium:788719
TEST=New unit tests.
Change-Id: I6c4f490d575788b696fd742a69e81e2767ec50f1
Reviewed-on: https://chromium-review.googlesource.com/937705
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Adds two new functions and their corresponding TPM commands to create
delegation families and list the delegation family table, respectively.
This isn't sufficient to meaningfully manage delegation families, but good
enough for the (ab)use case of storing flags in delegation family labels, which
we are going to do in order to strengthen encrypted stateful to guarantee
recreation of the encrypted file system after TPM clear..
BRANCH=None
BUG=chromium:788719
TEST=new unit tests
Change-Id: I31beb662784a8fff450b485c7cabc553944d7772
Reviewed-on: https://chromium-review.googlesource.com/817199
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Add the ability to take TPM ownership. This requires two new commands:
TPM_OIAP to start an auth session and TPM_TakeOwnership to establish
ownership. TPM_TakeOwnership requires an auth session and proper
command authentication to work, which is also added.
BRANCH=None
BUG=chromium:788719
TEST=new unit tests
Change-Id: Ib70144eedb0b1c7c43b26c06529d33ccbaa51a0e
Reviewed-on: https://chromium-review.googlesource.com/790414
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Trybot-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Remove 512 sector block size restriction so that UFS, with sector block size 4096
or greater, can be used. The sector block size is queried from the kernel with
ioctl(BLKSSZGET) or queried from depthcharge with VbExDiskGetInfo().
BUG=b:77540192
BRANCH=none
TEST=manual
make runtests passed.
Tested firmware on Kevin and boot to kernel from disk.
Executed cgpt show /dev/mmcblk0 on eve device and verified output was correct.
Should be tested on device with sector block size greater than 512.
Change-Id: I8165c8ee4da68180eecc8d12b3fb501cc5c60a5d
Reviewed-on: https://chromium-review.googlesource.com/1007498
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add helper functions that read a number in TPM byte order and advance
the buffer pointer in a single operation. Replace instances of this
pattern with call to the helpers. No functional changes.
BRANCH=None
BUG=None
TEST=existing unit tests
Change-Id: I96d866893ec875aafc978cbe2a55ea7f9f27542c
Reviewed-on: https://chromium-review.googlesource.com/985832
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
firmware/lib/tpm_lite.c turned off CHROMEOS_ENVIRONMENT if FOR_TEST is
enabled, resulting in a situation where code specific to
CHROMEOS_ENVIRONMENT couldn't be tested. Fortunately, AFAICS
tlcl_tests does not use FOR_TEST for anything useful any longer, so
just drop it.
BRANCH=None
BUG=None
TEST=FEATURES=test emerge-$BOARD -v1 vboot_reference
Change-Id: I7f08ef6d2343bc60a6d2982c3cc7bae0507d94d5
Reviewed-on: https://chromium-review.googlesource.com/937703
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If an aux firmware update fails enter recovery with a specific
reason code so we can identify systems that fail.
Also handle the case where the update succeeds and requests a
cold reset of the EC, first clearing the oprom flag if
necessary in order to prevent a second reset.
Unit test was added to check recovery reason for aux firmware
update failure.
BUG=b:74336712
BRANCH=eve
TEST=manual: force update to fail and ensure it goes to recovery
mode, and after successful update check that the option rom flag
is cleared before the EC reset happens.
Unit tests udpated and 'make runtests' passes.
Change-Id: I35a93892a0f8bb16eac0925ada5dfbc5c3144f8d
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/959671
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add a distinct recovery reason for aux firmware update failures
so we have some visibility into failures in eventlog.
This is used in a subsequent commit.
BUG=b:74336712
BRANCH=eve
TEST=manual: force update failure and ensure device goes to recovery
with this reason
Change-Id: I4b215444592b7c31cd25d59ad2a52b85d504e3bf
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/959669
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: caveh jalali <caveh@chromium.org>
Responses and commands share the same header structure. The
tpm_code field corresponds to TPM_CC in one case and TPM_RC
in the other. Make it uint32_t (instead of TPM_CC) in the
structure to avoid confusion when dealing with responses.
BUG=chromium:825894
BRANCH=none
TEST=build
Change-Id: I07821f35b0f539a863ee97c0a08c141d0533a4de
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/981111
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Propagate the actual error - a non-successful response
code from the tpm or communication/serializing failure -
to the caller of the Tlcl functions in TPM 2.0 case.
Currently, the callers only have special processing for
the error codes from TCG TPM 1.2 range, which are never
returned in case of communication or serialization failures
or from the actual TPM 2.0. (The only case of mapping
TPM 2.0 error codes to TPM_E_BADINDEX is preserved in this CL.)
Thus, changing the actual values returned from the functions
won't change any current behavior in the calling layers.
This CL is a preparatory work for adding special processing
for communication errors in mount-encrypted.
BUG=chromium:702724
BRANCH=none
TEST=build; test that tpmc getvf, tpmc read still work.
Change-Id: I96b20e7285e83f0038abc01e4b7175c938867e7d
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/977225
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It seems like there are some testing use cases where we want the device
to boot into the recovery installer but it is impractical to fully
simulate a user-triggered recovery. This has become impossible with the
recent change to always require manual recovery to boot an image, even
when the developer mode switch is enabled (CL:924458).
This patch adds a new GBB flag to support this use case. When the flag
is set, all recovery mode is manual recovery mode, regardless of wheter
the developer mode switch is on or not.
Since the GBB_FLAG_ENABLE_SERIAL was killed off before it ever really
worked anyway, we can safely reuse the bit reserved for it.
BRANCH=None
BUG=None
TEST=make runtests, manually confirmed on Kevin
Change-Id: I4f51dfd20b4ff04c522f53596896dccbceee52dc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/976660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The calling firmware can set ctx->flags VB2_CONTEXT_NVDATA_V2 to tell
vboot that nvdata is a 64-byte record instead of a 16-byte record, or
equivalently, set the VBSD_NVDATA_V2 flag if calling the old vboot1
API.
If calling firmware does not (which is the current coreboot and
depthcharge default), then the 16-byte record is used, and V2 fields
return explicit default values.
Added the fw_max_rollforward V2 field, which defaults to 0xfffffffe on
V1. This will be used by a subsequent CL.
Added unit tests to verify all that.
Added crossystem support, though it will only work with the current
16-byte records until firmware sets the VBSD flag and mosys supports
larger records.
(Note that because coreboot/depthcharge do not yet set the new context
flag, this CL should not change ToT firmware behavior.)
See go/vboot-nvstorage for design doc.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
Change-Id: I43072ef153dfa016c051f560892af1fbb3508e3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/942031
This was deprecated months ago in crossystem, and isn't set by
depthcharge or coreboot. Remove the flag from vboot as well, keeping
only a reminder in vboot_struct.h so we don't reuse the VbSharedData
bit.
BUG=chromium:742685
BRANCH=none
TEST=make runtests
Change-Id: Ifa928e8ec4d999c524c6f4168695859261f384c9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/947256
Reviewed-by: Julius Werner <jwerner@chromium.org>
VbLockDevice() would be inconvenient to port to 64-byte NV storage
records because it doesn't take VbSharedData flags or a vb2_context.
So, just have depthcharge call vbnv_write() directly (as it does in
other places in fastboot.c) and get rid of this API.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
CQ-DEPEND=CL:944183
Change-Id: I2aeaecf7f929cd1a1ebd1f6850d0dd96c6fabb49
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/944243
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Previously, non-manual recovery behavior would depend on the developer
mode switch: in normal mode it would get stuck at the BROKEN screen, but
in developer mode it would proceed exactly like manual recovery. This
behavior was mostly just confusing to people and it seems that we have
no real use case for it anymore. Remove the developer mode special case
so that non-manual recovery will always go to the BROKEN screen from now
on.
BRANCH=scarlet?
BUG=None
TEST=make runtests, verified manually on Scarlet and Kevin
Change-Id: Iaf33f82d7cb709a5ee309c08d1ad3015859738b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/924458
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This patch makes ec_sync_all clear OPROM_NEEDED flag when
ec_sync_phase2 updates EC and requests reboot.
Without this change OPROM_NEEDED flag will stay forever because after
reboot need_wait_screen won't be set (thus line 90 won't be reached).
BUG=b:72387533
BRANCH=none
TEST=Verify firmware screens are displayed on type-c monitor:
developer warning screen, critical update screen, recovery screen.
Change-Id: I9cc072efbf937ac438b55f3812f677612f79eaf9
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/916635
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since we're continuing to support the boot shortcuts Ctrl+D, Ctrl+U and
Ctrl+L, it makes sense to also continue to support the debug info
shortcut Tab, just in case somebody may want to use it from an external
keyboard. This does not affect the existing method to display debug info
through the appropriate menu option in any way.
BRANCH=None
BUG=b:73080278
TEST=make runtests, booted Scarlet and pressed Tab on UART.
Change-Id: Ia08404e0ffd1f8cac3d85f3b2fc4ce17a21d743d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/907759
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When switching from normal to dev mode, the EC is in RO. AP requests
warm reboot, whic causes EC to jump to RW. After sysjump, RW tries to
renegotiate PD but it's too late for type-c monitor to function
because VBIOS has already run.
This patch makes AP request EC reboot when switching to dev mode.
BUG=b:73083750
BRANCH=none
TEST=Dingdong connected to Teemo. Verify norm-to-dev screen is
displayed. make -j runtests.
Change-Id: I763cd6968406f7b904604b2588a9db6d567cbd4e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/907734
Bit 0 in the GPT partition attributes is defined to indicate whether a
partition is required by the platform. This CL adds the support for
managing this bit to cgpt.
BUG=b:70807006
BRANCH=None
TEST=Run unit tests.
Change-Id: Iaf87c828438b3df6730de502ae420fcf4c61277b
Reviewed-on: https://chromium-review.googlesource.com/902196
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This fixes a warning with GCC 6.3:
firmware/lib/vboot_ui_menu.c: In function 'enter_developer_menu':
firmware/lib/vboot_ui_menu.c:211:2: error: 'menu_idx' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
vb2_change_menu(VB_MENU_DEV, menu_idx);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TEST=Build
BUG=None
BRANCH=None
Change-Id: Idd9449322cccca66d8bd8796a444b9a8ceea9d11
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/897910
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch factors the code handling the BROKEN screen out of the
recovery_ui() function since it's already pretty much a completely
separate piece anyway. It is also rewritten to more closely match the
other UI loops and to use the same OPTIONS menu that allows language and
debug info access as the existing manual recovery UI.
BRANCH=None
BUG=b:64400036
TEST=make runtests, boot Scarlet in non-manual recovery mode and play
with OPTIONS menu. Also check manual recovery mode menu again, and
confirm that language selections and recovery reasons persist when
initiating manual recovery from the BROKEN screen.
Change-Id: Ib680c4e30d728c16a3661041d9b2987648e592e3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/892280
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Most of the UI loop input handling is essentially the same between the
developer and recovery mode interfaces. This patch factors it out into a
separate function, which reduces duplication and will make it easier to
add a third UI for non-manual recovery mode.
BRANCH=None
BUG=None
TEST=make runtests, played around with menus on Scarlet
Change-Id: I75751770a81eb373f8bc7ed0e5f5dfcb6d2bd464
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/892279
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
This patch shuffles around most of the detachable UI code to try to make
it more readable and maintainable. The goal is to get the business logic
out of the main UI loop functions as much as possible, and concentrate
the code handling each individual menu option in a single location.
This is a pure refactor and should not change behavior in any
(important) way. The adjustments to unit tests are only needed since the
old code displayed the same screen twice in certain circumstances, and
returning from the LANGUAGE menu to DEVELOPER selected the default
option Power Off, although other transitions to that screen select the
current default boot target.
BRANCH=None
BUG=None
TEST=make runtests, boot Scarlet and play with all screens.
Change-Id: Ibe05cbcb23c964d81f80de741bbd6f2231a2522d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/888082
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
The disabled_idx_mask always needs to be set according to the current
menu, so it makes sense to combine this task with the function that
changes menus. Call the new function vb2_change_menu() to indicate its
broader set of responsibilities.
BRANCH=None
BUG=None
TEST=make runtest
Change-Id: I122783cbc0b35d0d9e866f614646865c5c8a0ed0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/888081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
This patch implements the new OPTIONS menu which will function in stead
of the old basic RECOVERY menu. The TO_DEV menu is now directly
reachable through the VolUp+VolDown key combo. Cancelling any menu or
changing USB state will immediately drop back to the menuless base
screens (INSERT or NOGOOD).
Also contains some minor clean-up here and there, like decoupling code
from tests a bit more by reducing reliance on global initializers. Code
for the now obsolete RECOVERY menu will be removed in a follow-up patch.
BUG=b:67371896, b:64400036
BRANCH=None
TEST=Go through all recovery screens, trry various back-and-forth
transitions between OPTIONS, LANGUAGE and TO_DEV, in addition to
inserting/removing USB at various times.
CQ-DEPEND=CL:884840
Change-Id: I95319778e14ce07fe2ada3edf95990560ac7081a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770258
Commit-Ready: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This menu will be used by any of the legacy screens.
The idea is that when the user hits volume up/down, then
they will enter this options menu, which will allow the user
to change languages or show debug info.
BUG=b:67371896, b:64400036
BRANCH=None
TEST=None
Change-Id: I31d3e312388b56613368276ec72e5c68ded2264e
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770257
Commit-Ready: Benjamin Gordon <bmgordon@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Battery cutoff may cause the entire system to lose power, which means
that any uncommitted nvram updates will be lost. This can leave us in a
battery cutoff loop, where we never completely clear the
BATTERY_CUTOFF_REQUEST flag before actually cutting off power.
The only way to escape this potential cutoff loop is if we manage to
cleanly exit to vb2_kernel_cleanup(), where we perform a similar commit.
But this requires us to retain power for some time after
VbExEcBatteryCutOff().
BRANCH=none
BUG=b:70176744
TEST=`crossystem battery_cutoff_request=1` on scarlet, then reboot;
see battery cutoff; plug in AC and observe whether we reliably boot
on first attach
Change-Id: I1acf3aaeaf76f97f7603f79dbfef7a24a96f36dc
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/876783
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Now that vb2_shared_data / vb2_context provides all the same data to
lower-level kernel verification code that cparams did, stop passing
cparams down to those functions.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I86eb1801ee96d8b56404b74843a8d09e3122567f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852814
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The region API was a way for firmware and kernel verification to get
at various blocks of caller-provided data. In practice, we only used
it internally as a way to get at parts of the GBB. Prune it down to
access only the bits of GBB we still need, from the buffer we already
know we have.
In the long run we should use the same vb2ex_read_resource() API that
vb2 firmware verification does, but that should be done in a follow-up
CL since it'll need to be coordinated with support in depthcharge.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5715cb8d88274164a1a73ed4a56bbd93af46f9bf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852798
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Currently, firmware verification uses entirely vb2 structs, including
vb2_shared_data. This goes through an ugly translation to the old vb1
VbSharedData to pass it to depthcharge. The vboot kernel verification
maintains an equally ugly translation back to the vb2 struct
internally.
Eventually, we want to get rid of all that and use vb2 all the way
down to what crossystem picks up from the OS.
But before we can do that, we need to finish translating kernel
verification code to use the new vb2 structs. This is a step on that
path, using vb2_shared_data equivalents where present and hiding the
old vb1 shared data struct as a member of vb2_shared_data so at least
the vboot functions don't need to pass around cparams to get at it.
This will be followed by more CLs which convert more vboot internals
to use vb2 structs directly, and eventually coreboot/depthcharge CLs
which pass the vb2 structs from firmware verification directly to
kernel verification.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I5df8ce81ba3c3ac3f2cb4229db5461757cd89d8d
Reviewed-on: https://chromium-review.googlesource.com/852856
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
All screens are now drawn by depthcharge. ToT firmware does not
include a bmpblk / bmpfv section in the GBB. Remove the code paths
which are no longer used.
Also drop a few cparams parameters from functions that no longer use
it, now that those functions don't need to access the GBB.
BUG=chromium:502066
BRANCH=none
TEST=make -j runtests; build bob firmware and check recovery screens
Change-Id: I4d2d0a3ba57c34151e65c6f42581df823192a4ae
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852371
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Copy sync-related flags from cparams / vboot1 shared data to the
equivalent vboot2 structs. This removes the need for ec_sync to
access the old structs, which are on their way out.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I50ee76cf275a7fba894c2ec2c3dd83b9a8d91b53
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852489
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Vboot firmware previously supported a rather complex audio looping
library. Our original intent was to allow developers to flash a
custom beep sequence / tune as an easter egg. We never fully
supported that, but the code to allow it lived on. Get rid of that.
Vboot also previously made no assumptions about the frequency of
VbExGetTimer(), which was only used by the vboot_audio library. So it
spent 10ms every boot measuring the frequency. Which is silly now,
because depthcharge implements that as a microsecond timer. Get rid
of that measurement and define the timer as a microsecond timer.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: I350246874fb36b00149423696285cfcaca0fc526
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/847311
Reviewed-by: Shelley Chen <shchen@chromium.org>
Vboot1 code directly referenced the GBB from cparams even though now
it has access to the GBB flags via the vb2 context. Refactor all
existing code to use the vb2 context, since that takes us one step
closer to getting rid of the old vboot1 cparams.
No change in functionality.
BUG=chromium:611535
BRANCH=none
TEST=make -j runtests; build bob firmware and boot it
Change-Id: Ic4a5bf215b723a2eacbf0a4cf0eba8b1338155a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/847310
Reviewed-by: Shelley Chen <shchen@chromium.org>
Creating a unit test for testing the detachable UI menus. It'll
need access to some previously static variables that we will move
into this new file.
BUG=b:65025540
BRANCH=None
TEST=emerge-fizz vboot_reference with no errors
Change-Id: I249b152380dd55160e151506e00efd23bbbd1a5b
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/830679
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove the old vboot1 vboot_nvstorage library (VbNv*() functions) and
use the vboot2 library (vb2_nv_*()) instead. This is needed in
preparation for moving to 64-byte records; no sense in implementing
that change twice...
Should be (better be) no change in system behavior.
BUG=chromium:789276
BRANCH=none
TEST=make runtests
compare output of crossystem before/after change (should be identical)
Change-Id: I10f9975b0824263064b9a74a3c6daadcecc085d3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/794732
In Recovery Mode, when an USB key is inserted where valid OS is not
present, it shows "VB_SCREEN_RECOVERY_NO_GOOD" screen. But, once
removing that USB key, the screen should go back to INSERT screen
again.
This functionality was not working after the below Commit -
I2bab22fcbb0bb3cdfffe585eb633231ba8015fc3
This patch fixes this issue by assigning the current_menu as
"VB_MENU_RECOVERY_INSERT" every time when there is No Disk found.
BUG=none
BRANCH=none
TEST=Tested on Soraka to check that INSERT screen comes back once
Non-Valid OS Pendrive is removed from board.
Change-Id: I74efff562ba00a3e96b82ee158f9613f53c059b5
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/810824
Commit-Ready: Rizwan Qureshi <rizwan.qureshi@intel.corp-partner.google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
This patch allows a power button on a keyboard to shut down the system
when waiting for a user interaction at a firmware screen. The firmware
menu, which is implemented by vboot_ui_menu, shouldn't be affected.
BUG=b:70244028
BRANCH=none
TEST=Verify power button on Fizz can shut down the system at recovery
screen, broken screen, todev scree, and user confirmation screen using
a USB keyboard and a servo. Verify recovery button can confirm dev mode
transition. Run 'make runmisctests' successfully.
Change-Id: Icc7d7a774da19acac3d2938d5748ad2323ba4856
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/811444
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, we didn't require any action on these legacy screens, so
didn't update current_screen when displaying these. Now, will be
adding language switching and debug display for these screens, so need
to keep track of them.
BUG=b:65470853, b:67371896, b:64400036
BRANCH=None
TEST=None
Change-Id: I2bab22fcbb0bb3cdfffe585eb633231ba8015fc3
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676269
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=none
BRANCH=none
TEST=Upstream builder does not fail with uninitialized variable anymore like this:
firmware/lib/vboot_ui_menu.c: In function 'vb2_get_current_menu_size':
firmware/lib/vboot_ui_menu.c:255:15: error: 'temp_menu' may be used uninitialized in this function [-Werror=maybe-uninitialized]
*menu_array = temp_menu;
~~~~~~~~~~~~^~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: Idb1690c7b0becf3556cad379160fe152707ae843
Reviewed-on: https://chromium-review.googlesource.com/777805
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Shelley Chen <shchen@chromium.org>
Kernel verification will now roll forward the minimum allowable
version in the TPM no farther than the kernel_max_rollforward setting.
Note that CL:765573 changes chromeos-setgoodkernel so it always sets
kernel_max_rollforward to 0xfffffffe when marking a kernel as good.
That ensures that firmware with this setting will behave the same for
now as existing firmware.
BUG=chromium:783997
BRANCH=none
CQ-DEPEND=CL:765573
TEST=make runtests
Manual testing:
crossystem tpm_kernvel --> print current kernel version in TPM
- Resign the kernel with a higher version
- Reboot
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward=0
- Reboot
crossystem tpm_kernvel --> has not changed
- Wait a minute for chromeos-setgoodkernel to run
crossystem kernel_max_rollforward -> 0xfffffffe
- Reboot
crossystem tpm_kernvel --> has changed to the higher version
Change-Id: Ia32ecb7fa4078548cd311541ccbe120570cf1bc5
Reviewed-on: https://chromium-review.googlesource.com/765574
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This just adds the kernel_max_rollforward field to the nvstorage
libraries and crossystem. The firmware does not use it yet; that's
coming in a subsequent CL.
16 of the fields's 32 bits are taken from unused bytes of the kernel
field. This has no effect on existing usage.
BUG=chromium:783997
BRANCH=none
TEST=make runtests
Also manual testing. In a root shell:
crossystem kernel_max_rollforward --> Should default to 0
crossystem kernel_max_rollforward=0xfffffffe
crossystem kernel_max_rollforward --> Should be 0xfffffffe
(Note that setting it to 0xffffffff is indistinguishable from the
-1 value that the crossystem library uses to indicate error, so
0xffffffff isn't actually usable as a max rollforward limit. But
0xfffffffe is, and if we ever get so close to the limit that we
need to use 0xffffffff, something has already gone horribly wrong
with our versioning strategy...)
Change-Id: I008f412e6ed3c0b59beb9881268585af69d1ff2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/765572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Previously, we were able to exit the initial recovery graphic with
either the volume up or volume down button. However, we would only
like the user to exit the screen when they know what they are doing,
we are making it so that they can only intentionally exit (with volup
+ voldown simultaneously pressed).
BUG=b:67371896
BRANCH=None
TEST=reboot into recovery and press volume up + volume down keys.
Make sure we exit to the recovery menu screen.
Change-Id: I7dfb4a0e42c8b88e9b075e886cea1adfe248246c
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/766847
Reviewed-by: Julius Werner <jwerner@chromium.org>
When develper mode is disabled (through FWMP), don't allow user to see
the dev warning screen. Boot straight to TO_NORM and disable the
cancel option. Basically, the user will only be able to enable OS
verification, power off, or change the language. There is also no 30
second timeout during bootup.
BUG=b:65595945
BRANCH=None
TEST=Force disable_dev_boot flag to 1 and ensure the TO_NORM menu is
displayed w/o a cancel option. Scroll through options to make
sure they work as expected. Make sure debug message is displayed
indicating dev mode is disabled. Wait > 30 secs to ensure
timeout doesn't occur.
Change-Id: I7d2bcd369694e886866f9dedff05d81a40f8270a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757115
Reviewed-by: Julius Werner <jwerner@chromium.org>
