| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ignore a power button push until after we have seen it released,
to avoid shutting down immediately if the power button is held
down on startup.
BUG=b:116819414,chromium:670492
BRANCH=grunt
TEST=manual:
1) Press and hold esc+refresh+power.
2) Depthcharge shows INSERT screen and does not power off.
3) Release esc+refresh+power.
4) Press and release power.
5) Depthcharge powers off.
TEST=test_that --fast -b grunt $grunt_ip firmware_ECLidShutdown
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I7421a4b1a1b8a7894f0e7d1c7927ffc52d9faac0
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1256023
Reviewed-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`futility` used to print debug messages to stdout, but there is a side
effect that stdout may be buffered and then flush later than stderr.
For example, when calling futility via ssh, we will see flashrom
messages before any of futility's own messages.
Also, many people want to get flashrom verbose messages (-V).
With this change, when calling ERROR and DEBUG, we will always output to
stderr. This also enables better parameter type checking.
`-d` and `-v` both contribute to verbosity, that will be converted to
-V's when calling flashrom.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I1d22a8054fc43cdc5e6c7415e131cc9826fbff0c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1251145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Can we make futility support stdin like flashrom? I typically flash with:
ssh root@DUT flashrom -p host - < foo.bin"
Yes we can:
ssh root@DUT futility update -i - < foo.bin
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ib1ee5d4c882620e3b6f56fd5e4692b4829cf025a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1251141
Reviewed-by: Raul E Rangel <rrangel@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'SMM store' must be preserved during firmware update. On newer systems,
this can be done by preserving FMAP section 'SMMSTORE' (CL:1221210).
For Eve, the SMM store did not have its own FMAP section and needs to be
reserved by explicit cbfstool calls.
BRANCH=None
BUG=b:70682365
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: Ica043f51de0170b5c40f61d059437b9572025e2e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1250464
Reviewed-by: Joel Kitching <kitching@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many developers need to reflash or update firmware using servo, and the
firmware logic has been complicated enough that simply calling
'flashrom -w image.bin -p $SERVO' will usually destroy many important
settings, for example HWID, VPD, and other data provisioned in factory.
It should be more convenient if we can use 'futility update' against
servo. The '--programmer' provides first step - to override the flashrom
programmer so we can read and write via special programmer (like servo).
With this change, developers can reflash using:
futility -p $SERVO -i $IMAGE --force --wp 0
BRANCH=None
BUG=b:116326638
TEST=make futil; sudo tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: Iad4819ff8258086e1abb58fefd462d94050754d0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1239817
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By b/116298359#comment3, we know the tpm_fwver may be zero if the
firmware slot has been just created and no successful boots since last boot.
This is very common for factory and recovery so we should consider 0 as
"success".
There is still possible in early or proto builds, the device may have
vboot data structure changed so the updater calling vboot library cannot
get tpm_fwver properly. Also for people who wants to re-key their
devices with DEV firmware, we should allow waiving all TPM checks by
--force.
Also, in order to test that correctly, override_properties_from_list
should accept negative values to simulate failure in getting tpm_fwver
from VbGetSystemPropertyInt.
BRANCH=None
BUG=b:116298359
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: I09c91af36ceec340e393fb68999bea8d1907267d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1239814
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a generic way of selecting an alternative bootloader to run from the
developer-mode menu. This enables keys 1-9 to select a particular numbered
bootloader.
Adjust VbExLegacy() to take a numeric parameter to signal which boot
loader to run.
CQ-DEPEND=CL:1228875
BUG=chromium:837018
BRANCH=none
TEST=FEATURES=test emerge-grunt --nodeps vboot_reference
Change-Id: I02eab1b87e21a6401ec42317c4c1fa1bd2767b53
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1060854
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ideally we should fail if `tpm_fwver` can't be retrieved, but if an user can
run the updater then his system is already up so it's more likely to be a
vboot library issue (especially in early proto devices) that the crossystem
values were not reported correctly.
As a result, it seems more reasonable to skip checking TPM anti-rollback if
`tpm_fwver` can't be retrieved.
BRANCH=None
BUG=b:115764295
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: I7b6bf72531edb334a465c730fe8b3fbafa469b3a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1238099
Reviewed-by: Joel Kitching <kitching@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The '--factory' is an alias to '--mode=factory_install' and was widely used
in several documents. Also moved WP check to end of argument parsing so
'--mode=factory --wp=0' can set WP correctly.
BRANCH=None
BUG=b:115764295
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: I7987d77c577414efb03941442e3125f35ac5ad98
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1233373
Reviewed-by: Joel Kitching <kitching@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In --mode=factory, we should fail if write protection is enabled.
Also added an unit test for the case.
BRANCH=None
BUG=b:115764295
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
Change-Id: I6c693e470a034554b1f4a3cb16cfbf974ae6f54b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1226587
Reviewed-by: Marco Chen <marcochen@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many device may have some minor difference in early builds, for example
(board id) rev 0 and rev 1 may have GPIO pins connected to different
components. Usually the firmware should read board identifier and do the
right mapping, but sometimes the firmware may be totally incompatible and
no way to workaround (for example even the CPU may be different).
The min_platform_version is introduced so we can prevent updating to
incompatible systems, by reading $(mosys platform version).
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I418fee1aad884551b38ac25c340b2797b8503596
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198815
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On recent Intel platforms, flashing to SI_ME may get corrupted due to ME
execution in parallel. If we lock SI_ME immediately (by writing the new
SI_DESC), the device may fail to boot due to ME execution failure.
As a result, a quirk is added so the firmware updater will never lock
SI_ME. The Flash Master values are always unlocked when updating SI_ME,
and after system reboot, a board-postinst script should check ME status
and reflash SI_DESC only if SI_ME looks all good.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I584aa373797e2b4c2608f07aac21c16cdb34a5c4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198807
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some devices may have shipped with a smaller image that the real flash may be
larger, especially if the device's original flash has been EOL'ed.
The quirk 'enlarge_image' allows changing image size according to current_image
size by padding 0xFF (flash default value).
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I84373cfa9bcbd98a2cd96a7dd4bed27a6f724cf3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198806
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The firmware updater usually needs to apply many special rules for particular
device, previously done by the 'updater_custom.sh' script.
In futility updater, we want to support that by a 'quirks' system, that
the updater package can declare a list of needed quirks and send to updater
as `futility update --quirks LIST`.
Currently only a dummy "test" quirks is defined.
The real quirks will be added in follow up changes.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ic935d69a54473f2347964e7c161ffcdc0af43ec6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For devices that do not have update tag provisioned in legacy CBFS, we
need a way to push and enforce the updater to complete first migration.
The '--mode=legacy' provides a short cut to do
"flashrom -p host -w image -i RW_LEGACY"
Devices that need newer (or latest) legacy firmware should invoke
firmware updater in their initialization or setup process, to enforce
updating RW_LEGACY.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I87db067ad134e82bbbdc937bd2880c6731ec892b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1198808
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the RW is not signed by RO root key then verified boot will fail and enter
recovery mode. This may happen when user is trying to flash a DEV (or
PreMP) signed firmware on a MP-signed device, with write protection
enabled.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I1cee0b5f42f1f403d9baa5f9b2659f75511fbcb8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183659
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In verified boot, the key versions stored in TPM will be checked before
being able to load and run a signed RW firmware. This is also known as
anti-rollback check.
To prevent user installing an incompatible RO (even RW) and then being
not able to boot, we should check TPM key versions (by `tpm_fwver`
system property) before starting to update.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I6d50a6e475001d76fbcbe680a3f8b10f62354096
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1189249
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A safety check so people won't accidentally flashed wrong firmware image and
then being not able to boot.
The platform is decided by extracting the first component (delimited by dot
'.') of firmware ID. For example, platform for "Google_Link.123" is
"Google_Link".
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I90a1631f6b3e9a675fe1990cf9c204d763faf54c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1189248
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are still many devices running vboot1 and we need to support them as
well. There is no way to determine if a firmware is vboot2 or not, so we
can only rely on the system property "fw_vboot2".
If fw_vboot2 is 0, then we should always update section B and compare content
with section A.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Iefdcb81099914c2183c627a33eb73678d1269bc1
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1184952
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In try-boot updating flow, we have to first check if RO content needs to be
changed or not, and do full (ro+ro) update if WP is disabled. Also, before
starting to update RW-A or RW-B, we should also check if the active system
already has same firmware contents.
An --force is also added to allow skipping the check.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ie2f75f9aab4696c75aedafbf45e418ee98a2a4b4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183654
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When updating RO (or going to compare with contents), we need to
preserve (copy) section data from system active firmware image.
The `preserve_images` will try to preserve a list of known sections in
full update (`--wp=0`) mode, so we VPD data and HWID won't be lost.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh
BRANCH=None
Change-Id: I85c4ba972853dbc0fc101bee269c0effe70988b1
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183653
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In vboot2, to try one RW (unused) section on next boot, we have to:
- Find mainfw_act
- Select and update to the "other" slot
- Set system property fw_try_{next,count} values to try in next boot.
The new '--try' (-t) option can trigger the mode if available.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
futility update --emulation FILE -i IMAGE -t --sys_prop 0; # Updates to B.
futility update --emulation FILE -i IMAGE -t --sys_prop 1; # Updates to A.
BRANCH=None
Change-Id: I4b4662616a7181d2f37307238b7b80ae82369768
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1188017
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the system property 'mainfw_act'.
In both vboot1 and vboot2, the try-rw update process will need to figure out
what is current (active) firmware slot, which is the "mainfw_act" system
property.
BUG=chromium:875551
TEST=make futil; tests/futility/run_test_scripts.sh $(pwd)/build/futility
futility --debug update -i IMAGE --sys_prop 0;
futility --debug update -i IMAGE --sys_prop 1;
BRANCH=None
Change-Id: Ie745726107bff416549ba095a3defdd4cc98d32d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183652
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic is same as --mode=recovery,--wp=1 in legacy firmware updater.
An debugging option '--wp' is introduced so user can easily switch between FULL
UPDATE (--wp=0) or RW UPDATE (--wp=1).
BUG=chromium:875551
TEST=make futil; futility update -i IMAGE --wp=0;
futility update -i IMAGE --wp=1;
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ic7d8aa8b327296988ebf80a8e737e8893b7870ea
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1188016
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When updating firmware, we may need to get some system environment
status, like which firmware slot was selected and boot (active), or
setting cookies so the next boot will be using right (updated) slot.
In verified boot, these status are manipulated by "system property"
using API Vb{Get,Set}SystemProperty{String,Int}. The user land tool is
`crossystem`.
In order to run the firmware updater for testing and debugging, we need
an easy way to toggle getting real system status, or fetch from
predefined values. A new 'system_property' structure is introduced
and included as part of `updater_config`.
Each property can be access by `get_system_property(property_type)`
function. If the value was not fetched yet, the function will call
corresponding 'getter' function defined in property and then cache it.
A new parameter '--sys_props` is also introduced so we can easily
override them from command line so the updater will not get status from
running system.
The --sys_props takes a list of integers, eliminated by space or comma.
For example,
"1,2,3" => overrides [0]=1, [1]=2, [2]=3.
"1 2,3" => overrides [0]=1, [1]=2, [2]=3.
"1, ,3" => overrides [0]=1, [2]=3.
BUG=chromium:875551
TEST=make futil; futility update -i IMAGE
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ia2e06a953da1480da9a94f7f397802caa7468efa
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1188015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic is same as --mode=factory or --mode=recovery,--wp=0 in legacy
firmware updater.
BUG=chromium:875551
TEST=make futil; futility update -i IMAGE
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ifbfc4fb76f954483e779c8b508377d07561b67da
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183651
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To help debugging and testing, we may want to run updater against an
image file instead of modifying real system firmware.
The --emulate allows running with all checks and reading, and outputs
to given file.
BUG=chromium:875551
TEST=make futil; futility update -i IMAGE --emulate IMAGE2
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: Ic52fe60a1468f29245cade70f859513d8d117c9c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1184953
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To manipulate the firmware contents on device, we need to access the
flash chipset (usually via SPI) on system. The `host_flashrom` provides
a way to call external program "flashrom" for reading and writing
firmware. So the `update_firmware` can now load "system current
firmware" using flashrom.
Note in the future we may want to statically link the flashrom as
library so there won't be external dependency.
BUG=chromium:875551
TEST=make futil; futility update -i IMAGE
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I52f2d4fe4fe4dd660f762a5a75e3367820717e19
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183650
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add `find_firmware_section` and `firmware_section_exists` utility
functions to manipulate FMAP based sections easily. It is used by
parsing of image version strings, which helps indicating the firmware
versions going to be updated.
BUG=chromium:875551
TEST=make futil; futility update -i /build/eve/firmware/image.bin
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I458fa8c31c45dbbd29614c3d6ccd586e46a3ed0b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183649
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To specify images, we want to read them from files specified from
command line:
-i: AP (host) firmware image.
-e: EC firmware image.
--pd_image: PD firmware image (deprecated).
BUG=chromium:875551
TEST=make futil; futility update -i /build/eve/firmware/image.bin
tests/futility/run_test_script.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I3c2dbe3d3ce4619aa7e044a154be3aba7ab9181c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1183648
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A reference firmware updater for all systems running vboot using FMAP for
layout. The updater is currently a dummy implementation and will be completed
with incoming changes.
BUG=chromium:875551
TEST=make futil; build/futility/futility update;
tests/futility/run_test_scripts.sh $(pwd)/build/futility
BRANCH=None
Change-Id: I57bec91c178749b79a19789f9599f5f9048fced8
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1182701
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a command to cgpt to
change the GUID of the drive.
BRANCH=none
BUG=None
TEST=Compiled and ran utility to verify that GUID changes.
Also verified that the new and existing tests completed
successfully.
Change-Id: Ia8a815447509626312e2b06c6f293901290c73c3
Signed-off-by: Matt Delco <delco@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1171834
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Port CL:1009444 to ToT.
Adds (enable|disable)_alt_os_request flag for AltOS boot flow.
BRANCH=none
BUG=b:70804764
TEST=1. make runtests
2. Manually, set and get new flags via crossystem
Change-Id: Ie7fe2620f736335f11c39cbfe37b3fdf400ff926
Reviewed-on: https://chromium-review.googlesource.com/1014840
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Ting Shen <phoenixshen@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem files were found with:
find . -name '*.c' -o -name '*.h' | xargs grep '^ [^*]'
and edited manually.
Ignores utility/ and cgpt/, since they seem to globally adhere
to a two-space tab convention.
BUG=None
TEST=make clean runtests
TEST=emerge vboot_reference depthcharge
Change-Id: I5a678484a119c8f1911f717e1968bdb4f1a0810f
Reviewed-on: https://chromium-review.googlesource.com/1160131
Commit-Ready: Joel Kitching <kitching@chromium.org>
Tested-by: Joel Kitching <kitching@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an oversight from a previous CL:1007498 that removed the 512 block
size restrictions.
BUG=b:77540192
BRANCH=none
TEST=manual
make runtests passed.
Change-Id: I75b3ffebcc25afdde3774bcbb4a9600215a04436
Reviewed-on: https://chromium-review.googlesource.com/1031193
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generated with the following commands.
$ mkdir tests/devkeys/uefi
$ ./scripts/keygeneration/uefi/create_new_uefi_keys.sh tests/devkeys/uefi lakitu
$ rm -f tests/devkeys/uefi/{pk,kek,db,dbx}/*.rsa
BUG=b:62189155
TEST=See the following commit.
BRANCH=none
Change-Id: I996081c30fbfa89d07dba9252128dc214530e71f
Reviewed-on: https://chromium-review.googlesource.com/994179
Commit-Ready: Edward Jee <edjee@google.com>
Tested-by: Edward Jee <edjee@google.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 a TlclDefineSpaceEx function that allows to pass additional
parameters when creating NVRAM spaces, i.e. owner authorization as
well as PCR bindings.
BRANCH=None
BUG=chromium:788719
TEST=New unit tests.
Change-Id: I73404c05528a89604fea3bcb1f00741fb865ba77
Reviewed-on: https://chromium-review.googlesource.com/814114
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Trybot-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Trybot-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a TlclReadPubek library function to read the public endorsement
key.
BRANCH=None
BUG=chromium:788719
TEST=New unit tests.
Change-Id: I5f23b76b88198d656f4ba5782d2b4f25aaa082b1
Reviewed-on: https://chromium-review.googlesource.com/790413
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, ec.bin generated by cros_sdk contains and is signed by the
dev keys in the platform/ec/<board> directory. This patch copies these
dev keys to vboot_reference.
BUG=b:73249665
BRANCH=none
TEST=make runtests
Change-Id: Id2a0b16dc6d404a6bea902fd5a401d6fc7caa2bf
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/940665
Reviewed-by: Wai-Hong Tam <waihong@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assorted addtional tests to improve coverage of the firmware libraries.
BUG=none
BRANCH=none
TEST=make runtests
Change-Id: Iaf707bd54ca5dc10745eb19dfa9e9afbf0d74112
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/927608
Reviewed-by: Julius Werner <jwerner@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>
|