This will be used by the updater to first check that the touchpad
FW on AP side matches the one for which we stored hashes on EC
side.
This guarantee that we do not accidentally try to flash an
incorrect FW, which would render the touchpad non-functional.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=./usb_updater2 -t
includes output of
sha256sum A459C-1211_ForGoogleHammer_3.0.bin
Change-Id: Id30ab2d7c7d7e2d0f25cc893f685d218c44c022e
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/641736
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Make use of the generated touchpad firmware hashes to validate
the blocks before writing them to the touchpad.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=./usb_updater2 -p SA459C-1211_ForGoogleHammer_3.0.bin works
TEST=./usb_updater2 -p SA459C-1211_ForGoogleHammer_4.0.bin fails
Change-Id: If5d2be57b63e16ee81aa9acaf840c5084f9b92de
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616371
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Based on the passed TOUCHPAD_FW parameter to the make command, the
build system generates hashes for the touchpad FW.
To generate the hashes, gen_touchpad_hash splits the touchpad FW
in blocks of CONFIG_UPDATE_PDU_SIZE, that are hashed individually
(SHA-256), and then stored in the EC image.
This will allow the USB updater code to verify the integrity of
the touchpad firmware being flashed.
When no FW is provided, zeros are output, which do not match
any valid data.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=Using variations of
make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_4.0.bin \
BOARD=hammer -j
make BOARD=hammer -j
Check that TPHASH touchpad_fw_hash.h is only regenerated when
the parameter changes.
Change-Id: Ie347270aa9c00342de13489c9422e45e681b94c2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615321
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the field, we want to update touchpad FW using the same USB
update protocol as the main EC FW.
To distinguish between EC FW update and touchpad FW update, we
use a virtual address, defined by CONFIG_TOUCHPAD_VIRTUAL_OFF,
that does not map to anything on the EC chip.
Also, this will allow us to verify hashes of each block of the
flashed touchpad firmware, so that we can ensure its integrity
before flashing it into the touchpad. A stub is implemented in
update_fw.c:contents_allowed.
BRANCH=none
BUG=b:63993173
TEST=With follow-up CLs, ./usb_updater2 -p 144.0_2.0.bin
Change-Id: I4de1d7d138fc01fe1552a4173c8ef208ecb834a7
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593373
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
There is a window where the rollback information in RW could
potentially be updated during RW signature verification. We make
sure this cannot happen by:
- Preventing update over USB while RWSIG is running
- When system is locked, only update rollback information if
RW region is locked: this guarantees that RW cannot be modified
from boot until RW is validated, and then until rollback
information is updated.
Also, remove rollback_lock() in rwsig_check_signature:
rwsig_jump_now() protects all flash, which also protects rollback.
This reduces the number of required reboots on rollback update.
BRANCH=none
BUG=b:35586219
BUG=b:35587171
TEST=Add long delay in rwsig_check_signature, make sure EC cannot
be updated while verification is in progress.
Change-Id: I7a51fad8a64b7e258b3a7e15d75b3dab64ce1c94
Reviewed-on: https://chromium-review.googlesource.com/479176
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
cr50 and hammer/common code are such different chips that reusing the
same first_response_pdu does not make much sense.
Instead, we can use 2 different headers, the updater knows which
response to expect based on USB product ID.
In the common code answer, we can reply with the EC version string,
as well as rollback information and key version ID, which will
be required for reliable updating.
BRANCH=none
BUG=b:35587171
BUG=b:36375666
TEST=usb_updater2 can update hammer, and read its version, rollback
version and key version.
Change-Id: I20b04070606767c71df3e6286d53e238e13375c0
Reviewed-on: https://chromium-review.googlesource.com/476452
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
rw_sections is defined in the exact same way on all common code
boards, let's remove it, and hard-code the values in update_fw.c
instead.
Take this as an opportunity to fold set_valid_section in
fw_update_start (this will be useful later on, as we also
want to return the inactive region version).
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
TEST=Can update hammer over USB using usb_updater2
Change-Id: I4dd3224f17f89c1851c379255f1195dc54528b3d
Reviewed-on: https://chromium-review.googlesource.com/476451
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Let's move to protocol version 6, which provides most of the new features
we want to update generic EC firmware.
Note that this matches chip/g version as of commit 0e5497db6,
plus the following uncommited chip/g patches (CL:458364):
c73af7dd2 chip/g/upgrade: Clarify pdu/frame terminology
baea0a8c7 chip/g/upgrade: Rename SIGNED_TRANSFER_SIZE to UPDATE_PDU_SIZE
d6e41b75c chip/g/upgrade: Remove cr50-specific upgrade subclass and
protocol
3dc0b9a25 chip/g/upgrade: Rename upgrade to update
13436f9b9 chip/g/upgrade: Split rdpu initialization to a separate function
fab9a0936 chip/g/upgrade: Minor formatting fixups
8161ef7c0 chip/g/upgrade: Fix valid_transfer_start logic
bd6d79434 chip/g/upgrade: Fix logic for short USB packets within frames
b09e252ed chip/g/upgrade: Improve error handling
Then:
diff -u include/update_fw.h chip/g/upgrade_fw.h
diff -u common/usb_update.c chip/g/usb_upgrade.c
diff -u common/update_fw.c chip/g/upgrade_fw.c
Only shows chip/g specific differences.
BRANCH=none
BUG=b:36375666
BUG=b:35587171
TEST=make buildall -j
TEST=Can update hammer over USB using usb_updater2
Change-Id: I5b0f0281d844972dab572955d5495f808127e523
Reviewed-on: https://chromium-review.googlesource.com/458321
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This copies the generic USB update code into common
so it can be used on other platforms. There should be
no functional change. cr50 folks want no change to their
code so vbendeb@chomium.org will refactor this back
together at a later date.
BUG=chromium:571476
TEST=none
BRANCH=none
Change-Id: I710afb22940013e7db5d8694898b90c0ae245777
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362131
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
