If volume up + volume down + power buttons are held down for 30
seconds, then indicate to AP that HW_REINIT is requested by the
user. Since recovery mode is triggered by holding down the three buttons
for 10 seconds, button_check_hw_reinit_required checks for 20 more
seconds only.
BUG=b:37682514
BRANCH=None
TEST=Verified that:
1. If volume up, volume down and power are held for 30 seconds, AP
sees the hw reinit request.
2. If either of the buttons is released before 30 seconds, AP does not
see the hw reinit request.
Change-Id: I3a53966dcdcb84d73f160578411b6c0f62225b95
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/487002
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
AP will use that command to tell base EC that it believe the current
FW is functionning correctly, and that the rollback region can
be unlocked for an update on the next reboot.
BRANCH=none
BUG=b:35586219
BUG=b:35587171
TEST=- Flash hammer ToT image with rollback version 0
> flashwp true; reboot
> flashinfo => all flash is protected
- Update CONFIG_ROLLBACK_VERSION to 1
$ make BOARD=hammer -j
- Flash new RW
$ sudo extra/usb_updater/usb_updater2 -w
$ sudo extra/usb_updater/usb_updater2 -r
$ sleep 0.5
$ sudo extra/usb_updater/usb_updater2 -s
$ sudo extra/usb_updater/usb_updater2 build/hammer/ec.bin
> rollbackinfo
rollback minimum version: 0
RW rollback version: 1
- Tell RW to unprotect rollback
$ sudo extra/usb_updater/usb_updater2 -u
$ sudo extra/usb_updater/usb_updater2 -r
> rollbackinfo
rollback minimum version: 1
RW rollback version: 1
Change-Id: Ib52253e9b8bba872688d6f601d9bfad8862be25f
Reviewed-on: https://chromium-review.googlesource.com/489889
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Starting with
be294d4ef "hammer: Only define required options for RO and RW"
we do not define CONFIG_RWSIG for the RW section. However,
we want CMD_UNLOCK_RW to be usable when EC is in RW section, to
unlock itself in prevision for an update on the next reboot.
BRANCH=none
BUG=b:35587171
TEST=Update hammer using usb_updater2
Change-Id: I7ae001363697bc3e17d4a59b21413d35101228cb
Reviewed-on: https://chromium-review.googlesource.com/489888
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The existing commands do not really need longer response code.
Future commands can always reply with more data as needed.
BRANCH=none
BUG=b:35587171
TEST=Update hammer using usb_updater2
Change-Id: I37cb8ac444d58216a7d98c9090043b06d95c74e1
Reviewed-on: https://chromium-review.googlesource.com/489887
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, usb_port_power_dumb allows fixed number of ports (2)
and usb_port_power_smart allows less than 4 ports. This change
removes the limitation and makes them accept variable number of
ports.
BUG=chromium:715178
BRANCH=none
TEST=Verified usbchargemode returns consistent charge_mode across
sysjumps on Electro.
Change-Id: I7675c65ba03d3e6f7f53b2fe48cbe510231d945a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/481077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is useful for debugging, to understand if the RW rollback
version is ahead of current rollback version.
BRANCH=none
BUG=b:35586219
TEST=Flash hammer, rollbackinfo in EC console
Change-Id: I2634199845f1b35447e0938a35b862f79cb24ffa
Reviewed-on: https://chromium-review.googlesource.com/489886
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The virtual battery "energy" readings were totally broken. Rather
than reporting things in units of "10 mW" they were reporting things
in units of "10 uW". That's because they were doing this math:
result = mV * mA / 10
Said another way:
result = (V / 1000) * (A / 1000) / 10
result = (V * A) / (100000) / 10
result = W / 1000000 / 10
result = uW / 10
Aside from the fact that clients were expecting things in "10 mW"
instead of "10 uW", we got even more random results. That's because
we return to the client in a 16-bit variable, so we were kinda
randomly truncating things.
Doh.
BRANCH=ToT
BUG=chromium:717304
TEST=power_supply_info
Unfortunately when you try to report sane values for "10 uA" in a
16-bit result, it doesn't work too well (
Change-Id: I8075dffd7ab6b372be5b8fdf293acc96c5878036
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/492546
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 01ceab68cd6b542f8c6355425e6ac6da698e0ebf)
Reviewed-on: https://chromium-review.googlesource.com/492568
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
If charging current is set to 0mA during charging, reference of
charge current feedback amp (VREF_CHG) is set to 0V. Hence the DCDC
stops switching (because of the EA offset). To eliminate this issue,
disable/enable charger depending on the charging current is zero
or non-zero respectively.
BUG=b:37413065
BRANCH=reef
TEST=test 'ectool chargecontrol normal/idle/discharge' are working
Change-Id: Id31876afe365a476fb906e059ab519b7a0c9a7c6
Signed-off-by: james_chao <james_chao@asus.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/486101
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 6da9ed8786e90ee91b39934180fe84e01ac30260)
Reviewed-on: https://chromium-review.googlesource.com/489812
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
According to the new MCU secure update model, EC should wait for host if
reset source is reset-pin.
BRANCH=none
BUG=b:37584134
TEST=on rose, toggle reset pin from host. EC should stay in RO, showing
[0.426089 Hard pin-reset detected, disable RW jump]
in console.
Change-Id: Ie1908cb0744773e2e3ca8b3d8c627b8a9ef4567f
Reviewed-on: https://chromium-review.googlesource.com/485199
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Add a new host command EC_CMD_RWSIG_CHECK_STATUS for getting rwsig
status and rw firmware hash. This command is used to check the RW
signature of newly updated RW image.
A new subcommand is also added to ectool.
BRANCH=none
BUG=b:37584134
TEST=on rose board `ectool rwsigstatus` works
Change-Id: I33d8709f5248d3a4b8bedb36ded84a93dc8c971f
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/485079
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Split i2c.c code in two (i2c_slave.c and i2c_master.c). i2c_slave.c is
used when EC has no i2c device connected (i2c master code not needed)
but EC is connected to AP via i2c.
BRANCH=none
BUG=b:37584134
TEST=1. Compile rose board with CONFIG_I2C and CONFIG_CMD_HOSTCMD. Then
make sure EC_CMD_GET_PROTOCOL_INFO works.
2. On Kevin and Elm, cherry-pick to firmware branch respectively,
build and flash ec, i2c function works.
Change-Id: I1f95ad277713c5e30913e0a010ca03dfd9ec248c
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/484999
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
On "normal" EC, we do protect RW as part of software sync, which would
call flash_command_protect (which indirectly calls flash_protect_at_boot).
Here, we don't want to (and can't) rely on the host to tell us to protect
the RW, so we need to protect it ourselves before jumping to RW.
This does feel a little redundant with rollback_lock though, since ALL
will protect both RW and ROLLBACK: a later CL will fix that up.
BRANCH=none
BUG=b:35587171
TEST=flashwp true; reboot; RO protects all flash before booting to RW
Change-Id: I820cabb01d1ca4aa47b81fc013a1670134a6be09
Reviewed-on: https://chromium-review.googlesource.com/476453
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add support for 4 extra commands that are required to update
hammer:
- UPDATE_EXTRA_CMD_IMMEDIATE_RESET
- UPDATE_EXTRA_CMD_JUMP_TO_RW: Tells the RWSIG task to jump
to RW as soon as possible (assuming the image verifies)
- UPDATE_EXTRA_CMD_STAY_IN_RO: Tells the RWSIG task to not
jump to RW, and stay in RO, to leave enough time for
AP to update RW.
- UPDATE_EXTRA_CMD_UNLOCK_RW: Tells EC to unlock the RW
section so that it can be updated (on next reboot).
BRANCH=none
BUG=b:35587171
TEST=Test RO+RW update
cd extra/usb_updater; make
# Jump to RW
sudo ./usb_updater2 -j
sleep 0.5
# Update RO, then reboot
sudo ./usb_updater2 ../../build/hammer/ec.bin
sleep 0.5
# Update RW (first tell RO to not jump to RW)
sudo ./usb_updater2 -s
sudo ./usb_updater2 ../../build/hammer/ec.bin
TEST=Test RW update only, with RO protected
On EC console: flashwp true; reboot
cd extra/usb_updater; make
# Tell RW to unprotect RW and jump back to RO
sudo ./usb_updater2 -w
sudo ./usb_updater2 -r
sleep 0.5
# Update RW, then reboot
sudo ./usb_updater2 -s
sudo ./usb_updater2 ../../build/hammer/ec.bin
Change-Id: I5e8df7bdb4f06f2ac7b47de53dcde69c5002f578
Reviewed-on: https://chromium-review.googlesource.com/458470
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@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>
Power button pulse is disabled by the host whenever it wants to treat
the power button as an input and not trigger SMI. Clear this setting
whenever there is a chipset state transition to default pulse
enabled.
BUG=b:37277943
BRANCH=None
TEST=make -j buildall
Change-Id: Id0cb3748bf7e25ad9111170116113151d9bed69e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/476090
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
The led is control by HOOK_SECOND, but if dut press ALT+VOL_UP+H, enter
hibernate mode when system in s0, there is no one second to turn off the
power led, so the power led is still on when system enter hibernate.
BUG=b:36328757
BRANCH=gru
TEST=press ALT+VOL UP+H, the power led turn off and system enter
hibernate mode.
Change-Id: I72d18876aa5468131bae7ad42203982d123db8ba
Signed-off-by: james_chao <james_chao@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/476850
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Before entering standby mode, bit 7 (cable_det) or analog_ctrl_0 is
cleared. This allows a new cable detect event to trigger the EC to
put the ANX4329 into normal mode. However, in some cases such as when
in S3/S5/G3 chipset power states a port will be in sink only mode and
therefore won't attach when a sink only adapter is connected to the
port. This results in the an indefinite toggle of standby<->normal
mode transitions. This constant toggle floods the EC console and more
importantly prevents the ANX4329 from remaining in standby mode and
the power consumption remains at ~9.5 mW instead of ~1.2 mW when no
adapter is connected.
This CL adds logic around clearing the cable_det bit so that it's only
cleared if both CC lines are open or if an Emark cable is
attached. Emark cable is determined from the presence of Ra on one CC
line and no Rd on the other CC line. The special consideration for an
Emark cable is reqiured because when an Emark cable is connected, the
USB PD auto toggle state may require some number of iterations until
the attach event is recognized.
In order to support handle cases where the drp mode is changed via
either the EC console command or host command, added a call to
tcpm_set_drp_toggle whenever the drp state is updated. Since the drp
mode is updated upon chipset resume events, the chipset resume hook in
board.c for anx74xx_cable_det_handler() became redundant and hence it
was removed.
BUG=b:35775019,b:35586188
BRANCH=reef
TEST=Tested the following cases:
- Sink, source adapters in chipset S0. Verified that adapters
connected as expected. Also, used Emark cable to connect to both USB
PD chargers (source) and Pixel phone (sink).
- Run 'lidclose' on EC console then connect Type C -> A adatper
[3490.370125 TCPC p0 reset!]
[3490.389588 TCPC p0 Low Power Mode]
It no longer toggles indefintely and after running 'lidopen' verified
that port 0 is now in SRC_DISCOVERY.
- In S3/G3 connected USB PD charger with regular and Emark typeC
cable. Verified that port 0 is in SNK_READY state.
- use 'pd dualrole sink' and test with Type C -> A adatper. Verified
that tcpc wakes up, but goes into standby mode until entering 'pd
dualrole on'.
- When sink only adapter is connected in S3/G3, measure power level
~1.2 mW as opposed to ~10 mW in S0.
- Repeated similar tests on port 1 (parade tcpc) to verify that
adapters connected as expected.
Change-Id: Ib8de666f72723934186fee7869f9dda01381c7a8
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463991
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
(Optionally) split rwsig verification into a separate task. This
allows us to initialize other components (e.g. USB) while the
verification is in progress, speeding up the boot process to active
USB in RO case.
After CONFIG_RWSIG_JUMP_TIMEOUT, the EC will jump to the RW section
if no action is taken by the AP (such as a forced request to jump
to RW, or starting an update).
Note: This comes with a ~36ms boot time regression, as other code
gets to run before verification starts.
BRANCH=none
BUG=b:35587171
TEST=Flash, board boots to RW after 1s
TEST=Change jump timeout to 5s, add 5s delay in check_signature,
add console command to manually abort/continue rwsig verification.
'rwsig continue' works => Board jumps to RW after check_signature
is completed (or immediately while waiting for timeout)
'rwsig abort' works => Board does not jump to RW.
Change-Id: Ica5732b9298bb4d3b743cae2ba78df259db915ef
Reviewed-on: https://chromium-review.googlesource.com/468709
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is done at RO stage. If the rollback region is unprotected, update
it to match the version in the RW image.
If the rollback region is protected, we can't do that update, so we wait
for RW to unlock that region (presumably after AP has verified that image
is somewhat functional) before updating it.
BRANCH=none
BUG=b:35586219
TEST=flashwp true; reboot => hammer reboots twice
flashinfo shows RO+rollback protected:
Flags: wp_gpio_asserted ro_at_boot ro_now rollback_at_boot rollback_now
Protected now:
YYYYYYYY YYYYYYYY Y....... ........
TEST=Hack version.c to add "+1" to rollback_version, check that RO updates
ROLLBACK info block on first boot.
TEST=Use hack above, convert rwsig to separate task, add 5000 ms delay in
rwsig just before rollback information is updated. Then:
Quickly type: flashwp true; reboot; flashwp all; reboot
=> Wait for system to jump to RW
rollbackinfo => minimum version 0
flashwp norb; reboot; wait for jump to RW
rollbackinfo => minimum version 1
Change-Id: I78e502315c611c5edaf34b8d70a12fedd3e57bdf
Reviewed-on: https://chromium-review.googlesource.com/452816
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added a new static variable disable_dts_mode. By default, DUT port
will attempt to connect as a DTS source. However, if disable_dts_mode
is set via a console command, the DUT port will connect as a regular
source device. Charging behavior is identical between the two modes.
In DTS mode, Rp is presented on both CC lines. When it's disabled Rp
is presented only on CC1. Added tables to support the appropriate VNC
and RD voltage thresholds.
BUG=b:36908939
BRANCH=servo
TEST=Tested with new console command 'dts on|off'. If new mode equals
the current mode, no action is taken. If the mode is different, then
verified that DUT port connects as DTS following 'dts on' and regular
SRC following 'dts off'. Verifed this when the command is issued when
connected to the DUT or disconnected. Validated that the H1 console is
present for DTS mode and not present when DTS mode is disabled.
Change-Id: Ie649709d6b2bbe947708d05eac42fde61d2677a8
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/468447
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Follow-up to CL:456520, addressing a few more comments.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I692afa7c911882f00d92b8e6d83889c52821e171
Reviewed-on: https://chromium-review.googlesource.com/468506
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement actual rollback protection. First, we add a new field
in the version structure, which is an incrementing integer
(we'll start by shipping images with version 0, and gradually
increase the number as required). This allows us to release
new versions of the EC without necessarily bumping the rollback
protection.
For the rollback protection block itself, it contains 2 sub-blocks
of equal size (normally, 2k), that are individually erasable.
The rollback code looks at both, and takes the most restrictive one
to determine the desired rollback minimum version. The blocks
are also allowed to be erased (full of 1's), in which case the
rollback minimum version is assumed to be 0.
We also add an FMAP entry, in case we later decide to allow the
signer to increment the rollback version.
Also note that, like any version_data struct change, this change
breaks compatibility between old and new RO/RW.
Follow-up code will take care of auto-updating the rollback block
as required, and properly manage block protection.
BRANCH=none
BUG=b:35586219
TEST=Flash hammer
rollbackinfo => 1 version 0 block, 1 empty block, RW verifies
correctly.
rollbackupdate 0; rollbackinfo => No change
rollbackupdate 1; reboot => RO refuses to jump to RW
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
Change-Id: Ia969afb481a93deb912b9153bdd95ace01ad8fa7
Reviewed-on: https://chromium-review.googlesource.com/452815
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On keyboard-less design, we will implement a special debug mode,
based on button sequences, to transmit sysrq events to the AP.
This implements the new MKBP event to send sysrq, and a console
command to test it. Later CL will implement debug mode itself.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I71d3f77497baf8cc7fac65cd040ce20513b507bc
Reviewed-on: https://chromium-review.googlesource.com/456520
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When the charge ramp task starts, it starts up in the DISCONNECTED
state. From this state, it's possible to set the input current limit to
0 mA. However, upon task start, we shouldn't take any action until we
have valid values from a new charge supplier or a supplier leaving.
This commit changes the charge ramp task to not touch the input current
limit until the charge ramp state changes or the desired input current
changes at least once.
BUG=b:36468002
BRANCH=gru,master
TEST=Flash kevin EC RW or build AP FW that contains the fix that will by
sync'd by EC SW sync. Make sure WP is asserted to prevent PD
communications in RO. Unplug battery. Plug in AC, verify that system
can boot up to UI on AC alone.
TEST=make -j buildall
Change-Id: I351917bce7902c49d1bb842a0cc83dd161d75b6f
Reviewed-on: https://chromium-review.googlesource.com/461382
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463927
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The default for servo_v4 DUT port is to be SRC to charge the DUT, but
a UFP data role so that the DUT's usb mux gets connected.
BUG=b:35586526
BRANCH=servo
TEST=Connect to Electro and verify that servo_v4 data role is that of
UFP and that electro is getting an IP address from the enet port on
servo_v4.
Change-Id: I8f2e4242777bf879598852004096f683d68c091c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452725
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous boards that implemented tcpc layer on chip didn't support
variable Rp values. However, servo_v4 can present any of the 3
possible Rp values and therefore the voltage thresholds that are used
to determine a no-connect or Ra attach status need a way to be set
based on the Rp value that's current attached to a given CC line.
- Added port and cc line selection to both the CC_NC and CC_RA macros
and now check if they are already defined before being defined in
usb_pd_tcpc.c.
- Defined each of these macros in board.h to use a function that's
able to select the threshold based on the current Rp configuration.
BUG=b:35586526
BRANCH=servo
TEST=Tested with servo_v4 against Electro and verified that it
connects when a charger is and is not connected to CHG port which
exercises the differnt Rp combinations that servo_v4 presents.
Change-Id: I1a31e430c0f290486f0fa8a50bdafdddf20d23ca
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/451962
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The pstate structure is written using the low-level
flash_physical_write() function. As a consequence, it is supposed to
meet the CONFIG_FLASH_WRITE_SIZE alignment constraint.
Add a build-time assertion to avoid silent failures.
Slightly decrease the maximum size of the serial number string, so the
structure has a natural 32-byte alignment which is compatible with a
large number of platforms (including STM32L4 which requires 64-bit
alignment).
Of course, this change is not fully backward-compatible.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:571477 b:35648258
TEST=on STM32L442, build and run 'flashrom --wp-enable' without failure.
Change-Id: Ia8f82790a61a6c7d2cf9bfeb95bfdaf7b8c52d11
Reviewed-on: https://chromium-review.googlesource.com/458201
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
The upcoming move of the Cr50 firmware update to the background
requires postponing the activation of the newly uploaded Cr50 image to
a later point in time, when the AP is ready to switch to start using
the new Cr50 image.
The suggested way of achieving it is as follows: when downloading the
new image, the current Cr50 code modifies the header's 'image_size'
field, setting its top bit to 1. This both makes the size invalid and
guarantees that the new image would not verify on the following Cr50
restarts.
When the AP is ready to switch to running the new Cr50 image, it will
send a vendor command, which would trigger the currently running Cr50
image to restore the other image's size field. This vendor command
would also communicate the timeout for the Cr50 to wait before
rebooting, if there has been at least one header (ro or rw) restored.
Rebooting the Cr50 would trigger rebooting the AP, resulting in the
entire system running the updated firmware.
Response sent to the AP will indicate if there has been a header
restored and the reboot is indeed upcoming, this would allow the AP to
quiesce the state of the device to handle the reboot gracefully.
BRANCH=cr50
BUG=b:35580805
TEST=with the rest of the patches applied observed the system properly
after the new header version was restored.
Change-Id: Ia1edee67b6aa8f458810d5dc2931477cfaab1566
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
PS8751 does not restore all register contents when resuming
from low power mode. This change makes tcpm call board_init
when it stops auto-toggling so that register contents can be
restored.
BUG=b:35585399
BRACH=none
TEST=On Snappy, the board_init funciton is called every time a device
is plugged in and register contents are restored.
Change-Id: I50c51334f43c02e3c4d8453e1e966bf6eb3ce769
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/454139
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Let's split the usb headers in 3 different parts, instead of having
usb_descriptor.h pull in usb_hw.h and usb_api.h.
- usb_api.h: EC functions related to usb (e.g. connect/disconnect)
- usb_descriptor.h: common USB names and structures
- usb_hw.h: Functions required for interactive with EC's USB HW
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
Change-Id: I37ead61e3be5e7ae464f1c9137cf02eaab0ff92e
Reviewed-on: https://chromium-review.googlesource.com/454861
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Change-Id: I35f0aa87f5ab1371dbd8b132f22b9d0044358223
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450859
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to make pass through charging safe, there must be a mechanism
to signal the CHG port manager that Vbus is available and in a steady
state. When a typec only charger is used for the CHG port, then it's
steady state is SRC_DISCOVERY. Need a way to differentiate the TypeC
only charger from a USB PD charger that's also going through
SNK_DISCOVERY.
In addition, to allow a DTS device to support PD messaging, can't
stay in SRC_ACCESSORY state. This CL makes a modification to the
USB PD state machine so that if a debug accessory is detected and
CONFIG_USB_PD_DTS is defined, then the state machine will advance to
SRC_STARTUP and prepare for messages similar to when a UFP attach
is detected.
BUG=b:35586526
BRANCH=servo
TEST=Manual Built for both Plankton and Reef, verified that Reef
connects as both SNK and SRC.
Change-Id: I9aea0341cd9b6e6773023f0923a9a18a86fc4627
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448987
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Pass "full_build_string" to ccprintf() as expected. I believe that this
code only worked previosly due to blind luck; the compiler allocated
"full_build_string" on the stack in such a way that it was available at the
end of the call frame for ccprintf().
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: Ib307547a4c4d6300ccf018b33aee4db7a4f364f8
Reviewed-on: https://chromium-review.googlesource.com/451084
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
pdcontrol suspend command will be used to prevent tcpm from putting
the chip into sleep while firmware update is taking place. Currently
the command suspends or resumes port 0. This patch makes the command
apply to ports individually.
pd enable console command now takes a port number:
pd <port> enable/disable.
This patch also replaces CONFIG_USB_PD_COMM_ENABLED with _DISABLED.
When it's defined, PD communication is disabled at startup.
Plankton undefines CONFIG_USB_PD_COMM_ENABLED enable, intending to
disable PD communication at startup. Therefore, this patch defines
CONFIG_USB_PD_COMM_DISABLED in its board.h.
BUG=b:35586859
BRANCH=none
TEST=From AP console:
localhost # /tmp/ectool pdcontrol suspend 1
[600.188013 TCPC p1 suspended!]
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: SUSPENDED, Flags: 0x0020
localhost # /tmp/ectool pdcontrol resume 1
[678.516613 TCPC p1 resumed!]
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
From ec console:
> pd 1 disable
Port C1 disable
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
> pd 1 enable
Port C1 enabled
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
Change-Id: Ia0cc4904ac52adc4b89de20918968c8df78b9c80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447968
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Using -O3 optimization level rather than -Os results in a large speed-up
for a minor code size increase for the RSA code with our current GCC
toolchain.
Add the CONFIG_RSA_OPTIMIZED option to do it on platforms which are not
too size-constrained.
On cortex-M4 based STM32L432, I'm measuring a 37 to 40% speed increase
(depending on CPU frequency) for a 200 bytes code size delta.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manual: benchmark RSA2048 with F4 exponent on STM32L432:
-Os -O3
@16Mhz 185163 us --> 111942 us
@80Mhz 39286 us --> 24582 us
Change-Id: I8c2e4b757f037f4f645fb73ba0faaaa471b24896
Reviewed-on: https://chromium-review.googlesource.com/445218
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
