| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
Change-Id: I789caf6fd4410820b9a0c9ef4ed39ad4f4568737
Reviewed-on: https://chromium-review.googlesource.com/1354144
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename "smm store" to "smm_store".
Depends on CL:1351857.
BUG=b:120060878
TEST=None
Change-Id: Iae511ecdc6d918d06218de1b651b1e5e3821d2f1
Reviewed-on: https://chromium-review.googlesource.com/1351178
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For developers running a local build on white label models, currently
the chromeos-firmwareupdate will always fail if VPD `whitelabel_tag` is
set because the `keyset/` folder does not exist (which was created by
signer bot).
Developers in this case usually don't really care about which key to use
and will be happy with the default (DEV signed) keys, also the key
compatibility will be still checked later, so we can skip the white
label patching if no keyset folder, which would allow developers getting
same experience on WL and non-WL devices.
BUG=b:120268135
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I3992301ff4c406096e11e1ae8129f2f68b2319b5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1356688
Reviewed-by: C Shapiro <shapiroc@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The firmware name for Veyron devices are Google_Veyron_XXX and we have
to correct the names in quirks database.
BUG=chromium:910085
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I3bf3bbb32fe90ebf370c1bc51c54d0280ddb7e98
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1354147
Reviewed-by: Youcheng Syu <youcheng@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Model '%s' is not defined in manifest." is not very easy to understand
for people who are debugging devices in early stages. We should provide
better instructions. For example, running with Coral updater will now
show:
ERROR: manifest_find_model: Cannot get model name.
You are probably running an image for wrong board, or a device in early
stage that 'mosys' command is not ready, or image from old (or factory)
branches that Unified Build config is not updated yet for 'mosys'.
Please check command 'mosys platform model', which should output one of
the supported models below:
unprovisioned_meep sparky orbatrix unprovisioned_fleex grabbiter bobba
unprovisioned_bobba mimrock fleex meep yorp phaser360 sparky360 phaser
bobba360 unprovisioned_phaser bip
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ib17fcb654d1530b94c44cf21aaa28717841f11ed
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1351171
Reviewed-by: Cheng-Han Yang <chenghan@chromium.org>
Reviewed-by: Ting Shen <phoenixshen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement support for getting random bytes from the TPM in the tpm2
library. The intent is to use this to seed the kaslr-seed DT property on
ARM devices.
BRANCH=None
BUG=None
TEST=Generate some random bytes in depthcharge using this API,
and 'stop trunksd; tpmc rand <size>' with sizes (0, 1, 0xf0, and
0xf1) on the device and see the last one fail
Change-Id: Ied0dc1ead70ac4daa2cee315516160ec100039be
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327187
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a mock test to handle VB_AUX_FW_NO_DEVICE severity
BUG=chromium:896451
BRANCH=None
TEST=/mnt/host/source/chromite/bin/cros_run_unit_tests
--board=octopus --packages=chromeos-base/vboot_reference
Change-Id: Ifdabdf3cee1130a8c853d57c278f0e557ebbb96f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1299994
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a possibility that a registered device is not present at
run-time and this scenario needs to be handled a little different. Add a
new update severity to handle this situation.
BUG=chromium:896451
BRANCH=None
TEST=bootup to ChromeOS by connecting and disconnecting the USB
daughterboard
Change-Id: I8a2044ce6a10fe611ee1f47262a7b54598a53ce3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1299993
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In auto update and recovery, the firmware updater was executed with both
stdout and stderr logged. However, the logs usually comes with all stderr
first then all stdout. This makes it harder to debug because the
messages logged in out of order.
TO solve that, few macros are introduced:
INFO: for useful information.
STATUS: the most common information, usually comes with a prefix code.
And all messages should now go to stderr except the final execution
result (and those output commands, for example --manifest).
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
CQ-DEPEND=CL:1345250
BRANCH=None
Change-Id: Ie0dc6594ece10e7e15caf9c36353e2b3ec8754c5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1345611
Reviewed-by: Youcheng Syu <youcheng@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were devices shipped as "only device" (no key set) and then became
one of the "white label" family. This is now no longer valid on newer
devices but we have to support the legacy ones, for example Reks.
BUG=chromium:906962
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I437be08726ab2c46229062689bf765ac6837ca5d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1345610
Reviewed-by: Youcheng Syu <youcheng@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There may be quirks needed during image archive setup (for example
loading white label tags) so we have to move quirks setup to some
earlier place.
BUG=chromium:906962
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I1f6eddb0119c64098df75bad72809ba8366625c7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1345609
Reviewed-by: Youcheng Syu <youcheng@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
TEST=None
Change-Id: Ia9a0a7d9aabc298fcbda72371c9b1d2e6b822b17
Reviewed-on: https://chromium-review.googlesource.com/1333092
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, add (writable) at the end.
BUG=None
TEST=None
Change-Id: I34eb1e8e02ba3c837ba5fa452f9f6da64ce7b6e0
Reviewed-on: https://chromium-review.googlesource.com/1328391
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some user-space applications need to know whether Alt OS is
currently enabled or disabled. Add alt_os_enabled to
crossystem as a read-only flag for this purpose.
It is currently based off of reading VBSD_ALT_OS_SHOW_PICKER
from VbSharedDataHeader. We may want to change that to a
field dedicated to showing Alt OS state in the future
(see b/117195332).
BUG=b:117195332,b:117142023
TEST=emerge-eve vboot_reference && \
cros deploy --force --board=eve dut vboot_reference
Change-Id: Ic9a120e7d24021eb984d501f09ce4d7b6f85d730
Reviewed-on: https://chromium-review.googlesource.com/1328390
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it is impossible to programmatically enable/disable
Alt OS mode in eve. This is because only EC-RW supports the
kbatboot keyboard matrix functionality. But, as part of the
campfire boot flow, the keyboard matrix is retrieved *immediately*
after jumping into EC-RW. We need to insert a small pause in
order to allow for some entity (autotest/servo) to send a kbatboot
command, simulating the Alt OS keyboard press hotkey.
BUG=b:117140648,b:118786884
TEST=Manually use crossystem to set post_ec_sync_delay=1
Reboot, and wait for the delay to begin
Run `kbatboot 1 4 1` in EC console
Check that AP console contains:
"vb2_post_ec_sync_hooks: post_ec_sync_delay 5000 ms..."
TEST=make clean && make runtests
Note that we are only cherry-picking the changes which affect
crossystem in this CL. Firmware changes will still live in
campfire-eve branch only.
Change-Id: I1305357199d87b80b4edc4e311015106ab07de65
Reviewed-on: https://chromium-review.googlesource.com/c/1256644
Commit-Queue: Joel Kitching <kitching@chromium.org>
Tested-by: Joel Kitching <kitching@chromium.org>
Trybot-Ready: Joel Kitching <kitching@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 64d7369976b88b21d8d8a860252023776a2f119e)
Reviewed-on: https://chromium-review.googlesource.com/1328389
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For dogfood devices, we usually will only re-key from DEV to PreMP, and then
PreMP to MP. It was found that for retail devices, if WP was disabled
(unintended), user may accidentally re-key to DEV keys if they (1)
recover with a DEV-signed image, or (2) received an AU that didn't have
right signing keys.
As a result, we want to make it harder when recovering to DEV keys.
BUG=chromium:894324
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Id3f7788e6c86d12b6e37b77818a1b4c2ceda1e2f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1312596
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have one too many times being bitten by forgetting to reboot
my DUT between running this tool and trying to flash a new kernel.
Make the script remind me of this requirement.
BRANCH=none
BUG=none
TEST=ran script, saw new output
Change-Id: I5c4738317087ec7654b13c1c9c3cd67273ba3bf1
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1330016
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present we allow the user to press a keypad number to boot into another
bootloader but there is no indication which one is which.
Add a new screen for this. It is entered via Ctrl-L and shows the
available bootloaders, along with the number to press for each. The
contents of the screen is rendered by the bootloader, as usual.
This is supported by two new screens, one for the keyboard UI and one for
the menu UI. Also a new function, VbExGetAltFwIdxMask(), is added to find
out what bootloaders are available.
Note: This CL combines changes for both UIs. The changes may be easier to
review separately.
CQ-DEPEND=CL:1273269
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: Ib3227545dc677c8f9587944753e32f3b49647360
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1273268
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We recently expanded the kernel size from 16M to 64M for the generic
amd64 image and that's causing problems for this script. Let's drop the
check for a maximum size as we have other sanity checks for reading the
kernel command line and modifying vboot headers later on anyway.
BRANCH=None
BUG=chromium:905093
TEST=deploy_chrome for amd64-generic image
Change-Id: Id08ad0a1feb28fda850c611e1e993d15b32e502d
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1336109
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are devices, especially during or after RMA, may have WP states
not synced; for example
HW = 1
SW (AP) = 0
SW (EC) = 1
In this case, we can still update host firmware but not EC. This happens
more often on EC that needs an extra reboot to change WP states.
As a result, we do want to check real programmer again before updating
optional images.
BUG=chromium:902546
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I9a526cde19a1ab3c41afecb4f7247bd941edc3f4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1322295
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If some system that firmware RW sections were damaged, the firmware
string may become '\xFF' (flash erased content). We do not want to see
that as version string, and this will help FAFT testing.
BUG=chromium:899901
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I947ec3c8286a022163abf01ae1d8ab5747aacf08
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1317050
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To simplify the migration plan, we want to support the legacy arguments
used by FAFT:
--noupdate_ec => --host_only
--noupdate_pd => --host_only
--nocheck_keys => --force
--update_main => ignore
BUG=chromium:882445,b:118509893
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I31652806085937fe5ca2f2facc7321021977cbb7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1310253
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is important that we lock the TPM before calling this function. We have
several places where the function is called. Reduce the risk that the TPM
is no locked by running all calls through a single point. Drop the
vb2_exit_altfw() function as it is not needed now.
We rely on being able to call RollbackKernelLock() multiple times since it
ignores subsequent calls and does not attempt to lock the TPM twice.
With the menu UI this causes a small change in behaviour: when starting
legacy firmware fails the screen flashes AFTER the beep instead of before.
Hopefully this difference is not important.
Future work will unify the two UI more.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I0ee0b52eb57c30c1e1bb4a7e60e11d060025ab17
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1292248
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having vboot_ui be the common file between that and
vboot_ui_menu, create a new file.
For now just move over vb2_error_beep(). The other common functions are
being removed in future CLs.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: Iff6917642ff79ea0b5cce60b383876b6f7174d20
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1310794
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases we use a a single high beep to signal an error. It does not
seem important to distinguish this from any other kind of error, so just
use the existing case.
All beeping now goes through vb2_error_beep(), except for one beep in
vboot_audio.c.
We could move vb2_error_beep() to vboot_audio.c, but the beeps seem to be
a part of the UI rather than the audio system. Of course,
vb2_audio_looping() arguable is also...
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I55807b4548987a621e8bbced97e7710d6cd6d5fb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1292247
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In chromium:895549, we want to have consistent behavior of
'tpmc def' between TPM 1.2 and TPM 2.0.
In TPM 1.2, define space command will undefine the existing space,
and create a new one. So we make the 'tpmc def' act as this by
default.
Also, provide a option for whom may want to define a new space
only if it is not defined yet. It will return TPM error code
at that case.
BUG=chromium:895549
BRANCH=None
TEST=unit test; manually test:
# For TPM 2.0 use AUTHREAD|AUTHWRITE
tpmc tpmversion | grep 2.0 && export PERM=0x40004
tpmc tpmversion | grep 1.2 && export PERM=0x1
# Define the space
tpmc def 0x1020 0x1 "$PERM"
# Redefine the space, default will overwrite
tpmc def 0x1020 0x1 "$PERM"
# Expected: Success
tpmc def 0x1020 0x1 "$PERM" --no-overwrite
# Expected: output error for the space is already defined.
# For TPM 2.0, it should output:
# command "def" failed with code 0x14c
# the TPM error code is unknown to this program
# For TPM 1.2, it should output:
# The space is existing but --no-overwrite is set.
Change-Id: I9b4e742f2935578443ebcc69e91d0aebc84deed8
Reviewed-on: https://chromium-review.googlesource.com/1298098
Commit-Ready: Meng-Huan Yu <menghuan@chromium.org>
Tested-by: Meng-Huan Yu <menghuan@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For TPM 1.2, the undef command only works when NvLocked is not set
which is usually set before boot, even for recovery mode.
For TPM 2.0, it will automaticly choose the correct authorization
according to the TPMA_NV_PLATFORMCREATE attribute of that index.
BUG=chromium:895549
BRANCH=None
TEST=No test for TPM 1.2
Manually test for TPM 2.0:
1. Boot with platform hierarchy is disabled, then
# perm: TPMA_NV_AUTHREAD | TPMA_NV_AUTHWRITE
tpmc def 0x1020 0x10 0x40004
tpmc getp 0x1020 # check the space exists, expect success
tpmc undef 0x1020
2. Boot with platform hierarchy is enabled, then run
# perm: TPMA_NV_AUTHREAD | TPMA_NV_AUTHWRITE |
# TPMA_NV_PLATFORMCREATE
tpmc def 0x1020 0x1 0x40040004
tpmc getp 0x1020 # check the space exists, expect success
tpmc undef 0x1020
Change-Id: I1d814287fda3e7c11933eca7334fdc3ab1ebf895
Reviewed-on: https://chromium-review.googlesource.com/1298097
Commit-Ready: Meng-Huan Yu <menghuan@chromium.org>
Tested-by: Meng-Huan Yu <menghuan@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For TPM 1.2, to undefine the space is just define a size 0 space.
And all operation should be done under physical presence is set
if NvLocked is set. Iirc, NvLocked is usually set before boot.
For TPM 2.0, support to undefine space regardless platform hierarchy
state. We will use platform authorization when TPMA_NV_PLATFORMCREATE
of that space is set. Otherwise, we will try to use owner
authorization with NULL password.
For owner authorization with customized password is still not
supported in UndefineSpace since it is also not support in
DefineSpaceEx.
BUG=chromium:895549
BRANCH=None
TEST=vboot_reference unit test passed and added new link test for TPM 1.2.
For TPM 2.0, there is no unit test, but passed manually test
with tpmc in the following commit.
Also passed depthcharge unit test for TPM 2.0 and TPM 1.2 board.
Change-Id: I06dcc70c63a88a04d19f3b248666ff2492a1d2b0
Reviewed-on: https://chromium-review.googlesource.com/1291131
Commit-Ready: Meng-Huan Yu <menghuan@chromium.org>
Tested-by: Meng-Huan Yu <menghuan@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Icelake platform, the pinctrl (gpiochip) driver label is "INT3455:00",
hence declare it properly.
TEST=run 'crossystem wpsw_cur' and see '0' rather than an error
on dragonegg platform.
Change-Id: I34e24478934a8fbaf9777a8340672697f7642ba3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1307200
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In mosys, $(mosys platform name) currently returns the board (family) name
while the real model name needs $(mosys platform model).
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ie3355ca94d577e88a2140567b9284da40c0b39c5
Reviewed-on: https://chromium-review.googlesource.com/1301013
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have two different types of beep each with its own meaning:
- two high beeps: not allowed
- single low beep: allowed but it failed
Add an enum to cover this and update all callers. In VbTryUsb() there is a
delay after the beep but that does not seem to be needed, so drop it.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I824d088d1a51aeb5a35b5978a05533e8eabcf8f6
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1292246
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream Linux supports a new ioctl API for GPIO chips, via new
/dev/gpiochip* device nodes. This new API supports name lookups, which
is a much nicer way than the index-based stuff in /sys/class/gpio/. We
can finally use this instead of our custom, downstream "chromeos_arm"
driver.
GPIO line names are defined in a 'gpio-line-names' property in the
Device Tree. For now, we have exactly one board using this, and we're
calling it 'AP_FLASH_WP_L'. We will need to ensure future devices use
this same naming.
Per others' suggestions, I'm avoiding using libgpiod, because it's a
relatively new library (with breaking changes in v1.0 as recently as
this year), and vboot_reference is used by plenty of other projects. And
it wasn't that hard to hand-roll the ioctls.
Side note: the chromeos_arm device is not guaranteed to be found at
/sys/devices/platform/chromeos_arm any more (especially on kernel
>=4.14), so this is a handy excuse to just kill use of the driver
entirely.
BRANCH=none
BUG=chromium:897992
TEST=`crossystem wpsw_cur` on 4.14 kernels (with this API) and older
kernels (without this API)
Change-Id: I7553801fb0e97c8a0aa6f4341d297ad0071c3dac
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1298274
Reviewed-by: Douglas Anderson <dianders@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Storing backup files inside /mnt/stateful_partition should be done only
on DUTs running ChromeOS. For chroot or other environment, we should
just store in current folder if available.
Also fixed that the warning message when backup files can't be generated
should be printed using "warn" instead of "warning".
BUG=None
TEST=./make_dev_ssd.sh -i image --edit_config --partitions 2
Change-Id: Ie81e810951e7fc72f350de847440a8f0372bc9be
Reviewed-on: https://chromium-review.googlesource.com/1300893
Commit-Ready: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to make the firmware updater package more consistent file
contents (for example, we don't want time stamps, and better if the
files are always physically located in same order) we want to create and
manipulate the ZIP based package directly using updater.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ie4c5aafe51f633729de2879c73bf7074a695151f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286173
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `programmer` cannot be decided in `load_firmware_image` and is always
specified (and managed) by an outer context, and should be preserved
even when we call `free_firmware_image`.
This helps reloading or removing loaded images at runtime.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I22f698d4a7118197379e11556b18f70ecd023ca2
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1295209
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The legacy firmware updater can update explicitly only some type of
images by using `--[no]update_main`, `--[no]update_ec`,
`--[no]update_pd`.
Since software sync is introduced, usually it does not make sense to
only update EC or PD; instead the real request is to "ignore provided EC
and PD images and update only host".
The new `--host_only` argument provides an easy way to ignore images in
command line (`--ec_image`, `--pd_image`) and archives (`ec.bin`,
`pd.bin`).
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Idf403680880cd58a00867172ccec97fd60c1b826
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1295210
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For backward compatibility, we need to support the 'output' mode in legacy
firmware updater. The output must select right files according to system
model, and apply all white label transform if needed.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ib433647317fa97387aa4a7f8f2101b47e6ca2123
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1282084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For white label devices, we have to select and patch key files (root key
and vblock) by VPD (`whitelabel_tag` or `customization_id`). The white
label tag VPD will be processed and converted to a "signature ID" for
key selection.
To support that, updater has to fetch current (system) image if the
matched model is following white label (so we can read VPD from it).
For developers who want to load and use particular files, they can use
--signature_id to override VPD values.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I3630bae28d1a8493b56d0e5efd29f3c61a470379
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1278420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For devices using Unified Build, we have to select and load images from
archive by model configuration (setvars.sh). The system model can be
retrieved by $(mosys platform model), but for developers who want to
simulate or get images for particular platform, a command line argument
--model is needed.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I8f4a6735b34bc694a05808b001c7309623b2afa3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1278419
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use this in a few places, so add a constant.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I7182d0ac52c23c01397de08683ad83b818486f91
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286221
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code is used in both the keyboard and detachable UIs. Make it into a
common function and export it.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I1e2cf67ec3fce9bc78ad412ddcc34e0eaecab5eb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286220
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present we have all the logic for this feature in VbTryLegacy(). In
preparation for adding a new menu for alternative firmware, split the
logic into two pieces: preparing to start alternative firware, and
cleaning up afterwards if nothing booted.
Also export these functions so that they can be used by the detachable
UI.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I560634ebb03a7f02a488defa32b83e51001d018e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286219
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In RMA or factory reinstall flow, we will want to make sure device will
next boot into developer mode, which was usually enforced by GBB flags.
In updater4, this is done by updater using flags defined in target
image. We should keep same behavior.
BUG=b:117866155
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Idb6337d453d606dbf88b2a2b82961f21125b7fef
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1288211
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For devices not using Unified Build, the firmware updater may contain a
single set of firmware images. To make the manifest more consistent for
both cases (Unified Build or not), we want to change to model name to
be the platform name from FWID if available.
This does not make sense because for these devices, usually platform =
board = model, and it helps to make sure programs parsing manifest won't
try to use the hard coded name 'default' (which does not always work in
Unified Build).
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I6d56336f3b30981e3e936fa63dec7dd45d74b31a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1278418
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present the condition for this is checked in one place in
boot_legacy_action(). We need to be able to check it in more than one
place, so put it in a variable when entering developer mode. This matches
how the keyboard UI works.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: Iaf01b827095b0a1139a36af6834eba4dbf7fb150
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286218
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to reuse this code for the altfw feature. Move it up in the file
to permit this without needing forward declarations.
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I02e6cdfb1ea7d5b48e272a778976cdaf50378235
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286217
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For white label projects, the firmware updater has to select correct
root key and corresponding vblock files per different LOEM. In Unified
build, multiple models may share same firmware base image, with
different key files (per OEM). As a result, we have to apply the key
files before using the firmware image files.
This change adds the "patch" information when building manifest, and
prints the correct key hash in `--manifest` mode.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ib5e31af5262a0989a5a474d0683c83121f24cc78
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1270323
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The firmware updater packages used to rely on a pre-generated VERSION
file to report what files were included and their image versions. Its
format was hard to parse, and may be out-dated if people repack without
updating VERSION file.
The firmware updater today has the ability to read and parse version,
key hash, ... etc everything we need, so it seems more reasonable to
just let firmware updater scan updater package and print the information
in JSON format, so it will be very easy to fetch latest information.
To make sure the output is purely JSON, the start and end messages are
now sent to stderr instead of stdout.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ifa468fbb3adf798c7931f015258e6c6ce93de993
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1260804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are going to have more command line arguments that must be passed to
updater_setup_config, and it is better to manage so many variables in a
struct.
Also, revised the order or argument processing so that simple settings
are now processed first, then complicated ones or those with dependency.
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I03ac036d26e49cdf924c03d6e86a272ce89fc2aa
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1265575
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A firmware update is usually released as a package with multiple images,
instructions, signed vblocks and other files. To work with that, a new
argument '--archive' is added.
The --archive accepts a directory or file, and will determine the
correct driver automatically. For resources (for example --image) in
relative path, updater should find files from archive.
Note in current implementation, only ZIP is supported for file type
drivers (and need the system to have libzip already installed).
BUG=chromium:875551
TEST=TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I6a91cbe73fb4ee203c5fa4607f6651a39ba854d5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1253229
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|