Add config option, CONFIG_CMD_PD_FLASH, and undef by default. This subcmd in
the 'pd' command is large (500 bytes) and can be performed from host via
ectool.
Additionally the python script, util/flash_pd.py, is likely outdated or needs
adjustments for various timing related nuances.
Note, as flash command contained subcmd 'version' have added that under
'pd <port> vdm vers' to keep that functionality by default.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34489
TEST=manual,
run 'pd 1 flash signature' get 'parameter 1 invalid'
run 'pd 1 vdm vers' w/ zinger in port 1 see version string returned.
Change-Id: If282933c1d29febb43b5cf476a121be6b5a1071b
Reviewed-on: https://chromium-review.googlesource.com/238291
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Change PD receive timeout to 1.8ms. The max packet ever received
should be ~1.59ms, so this should be safe.
BUG=chrome-os-partner:33693
BRANCH=samus
TEST=load onto zinger and samus and connect a bunch of times.
also tested with PD communication disabled on samus and verified
that zinger sends source cap 50 times (each with 4 retries) and
then stops.
Change-Id: If82b2905d6f9118956229682d7f259fb94da0258
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238305
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a source gets an invalid request, send reject, but still go to
SRC_READY state and keep the old power contract in place.
BUG=chrome-os-partner:34987
BRANCH=samus
TEST=load onto zinger. on samus add custom code to always send an
invalid request. note that zinger still transitions to SRC_READY,
samus still transitions to SNK_READY, data swap is still performed,
discover identity is still performed, and samus still draws 5V/3A.
Change-Id: I1213688f2b205636b3657afb1a4d8f7929bfe7ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238250
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add new state to wait for getSinkCap response. We use the READY states
in the PD state machine to indicate that we are not waiting on a response.
This assumption is necessary for VDMs to know whether or not it is ok
to send. This CL fixes a bug in that assumption.
BUG=chrome-os-partner:33861
BRANCH=samus
TEST=load onto zinger. without this change, under the right circumstances
it was possible for a collision between a VDM (response to discover identity)
and an incoming response to the getSinkCap. This would cause the discovery
identity response to get dropped. with this change, when discover identity
response is queued it is delayed until after the getSinkCap response.
Change-Id: I16f4d5272e68bf699d0aecba12bdf6d6b8ff7fc7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238239
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Send a reject to getSourceCap if device is only a Sink.
Send a reject to getSinkCap if device is only a Source.
BUG=chrome-os-partner:34979
BRANCH=samus
TEST=make -j buildall
Change-Id: I53711fd88235c1c98d40fa2c59d48306e9ee7ba2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238231
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When battery is full and system is not in S0, then stop charging
and allow battery to power the system. Once battery is no longer
full and requests current, allow charging again. This is to work
around power consumption issues in our AC input path. The charge
override port is stored upon entering S3 and restored going back
to S0 so that the charge override port is not affected by this.
This also fixes lightbar so lightbar checks if battery is full
instead of checking raw percentage. The lightbar is also changed
to use the last tap direction if no charger is plugged in. And
the lightbar tap for battery threshold for turning green is
lowered to 95%.
This also moves some samus_pd board code out of interrupt handlers
and in to deferred functions to minimize time in interrupts.
BUG=chrome-os-partner:34640, chrome-os-partner:34847
BRANCH=samus
TEST=load onto samus. use battfake command from pd console to
set battery percentage. when system is in G3, see that
batt = 100% stops charging, and when batt < 100% it starts
charging again.
tested that we receive host command from EC with battery
information every time battery changes SOC.
Change-Id: Ia8e0721508e34ee3630f5e5b0c2f431a00329caf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236411
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change delay between sending hard reset and cutting VBUS
from PD_T_SINK_TRANSITION (35ms) to the new timeout
PD_T_PS_HARD_RESET (15ms).
BUG=chrome-os-partner:34985
BRANCH=samus
TEST=make -j buildall
Change-Id: I1dfcdc790ae748aa56350814d8c40d376eba68fc
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238230
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Increment retry counter to 3 (4 total attempts)
BUG=chrome-os-partner:35054
BRANCH=samus
TEST=load onto zinger. on samus run "pd enable 0" to disable
pd communication. plug in zinger and note 4 total source cap
packets sent every 100ms.
Change-Id: Ifc02db5f47d2ee72dad08e3973a0fb84d3ca46f9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238079
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
define CONFIG_CMD_BATDEBUG to enable console commands.
If the battery is larger than 6Ah or smaller than 150mAh, scale the parameters
transparently to the user using macros.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Custom console commands for the fuel gauge
I also used a Logic16 from Saleae and the fuel gauge on hadoken.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I959d51c3188336e4ad0983528ad7e53a2955a764
Reviewed-on: https://chromium-review.googlesource.com/234285
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Add absolute threshold on delta_z_inner for tap for battery to guarantee
that we have at least some minimum absolute change in z that has started
the tap for battery.
This change makes it such that if the accel readings are really steady
for a while, then a sudden noisy signal doesn't trigger tap for battery.
BUG=chrome-os-partner:34592
BRANCH=samus
TEST=use tapinfo on to observe tap values and do a double tap of varying
intensities. note that it should be just a little less sensitive to weak
taps.
Change-Id: I95367bc7f99b888e15e9ac3a2bc8c9cca32d30d6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237666
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Double the output data rate setting for accels for tap
for battery because with the lsm6ds0 sensor, the current
ODR does not guarantee that we get fresh data every time
we do a read.
BUG=chrome-os-partner:34592
BRANCH=samus
TEST=load onto samus, go to G3, use tapinfo on to see
ODR set to 476000Hz. add printf to lsm6ds0 to print when
data is not ready, and see that without this change, the
printf is hit once a minute or so, and with this change,
the printf is never hit, meaning new data is always ready.
Change-Id: Ib09cba0d70642f59df8a35b5b6bb4fd7b9a4fa3d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237665
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Ports should have source roles by default, and should go back to being
sources once we stop charging from them.
BUG=chrome-os-partner:31195
TEST=Manual on Samus. Connect Samus to dual-role port. Set override
port, verify that Samus charges. Attach dedicated charger, verify that
the dual-role port becomes a charge source again. Also pass unit tests.
BRANCH=Samus
Change-Id: Icf153117229cbf0f71d4bdeb888f73299acd5eeb
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237452
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Set charge state machine voltage to just above the battery voltage
when AC is disconnected. Also send new current before sending new
voltage to charger when there is a change. These changes reduce
input current spikes caused by current inrush into the battery and
thereby decrease chance of overcurrenting power supply on connect.
BUG=chrome-os-partner:33862
BRANCH=samus
TEST=load onto samus instrumented with input current probe. when
AC is attached note that initial current spike is much lower with
this change.
Change-Id: I7760cd2b709c6b3536cf2a9449bb1f46800ce10a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237245
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This conversion is needed in files outside of system.c, so add a new
function.
BUG=chrome-os-partner:34599
TEST=Manual on samus_pd. Run "pd 0 info" and verify "Image RW" is
printed.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia905ba9cf985f3714fa75c81670b8a39e9608f3d
Reviewed-on: https://chromium-review.googlesource.com/236980
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Previously, handle_vdm_requests could dispatch another VDM message
via send_validate_message prior to main task returning to vdm state machine
(pd_vdm_send_state_machine). While it hasn't been problematic to-date it would
make honoring VDM specific timers or PDO priority difficult.
CL changes behavior so that if VDM being handled requires another VDM to be sent
its copied to the one entry queue (queue_vdm) where it will be
serviced upon VDM state machine entry later.
With this simplification, CL expands interlocks between PDO & VDO.
VDOs are only sent when source/sink is in the ready state & no
incoming packet is on the CC line. PDOs aren't sent when the VDM
state machine is busy.
CL also simplifies VDM console output to come only from request handler which
could save a few bytes.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=manual,
1. dingdong/hoho still enter mode.
2. Can still update fw.
Change-Id: I2fe8643a6975205b2d0f510f4f1baf2d74c1e190
Reviewed-on: https://chromium-review.googlesource.com/235680
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
The current power request function avoids redundant requests by
checking if we have previously requested vSafe5V or the max we
can request. But, if the max voltage that we can request changes,
then sending another max request is not redundant. This CL modifies
the request function to check for redundant requests by checking
the max voltage that can be requested, so if the max voltage
changes, then a new request is allowed.
BUG=none
BRANCH=samus
TEST=on pd console:
pd 0 dev 5
pd 0 dev 12
pd 0 dev 20
all send new request immediately.
Change-Id: Ifcdcc3eac9e566714f6dc609e46bbb0b94426499
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236882
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This addition allows the AP to query whether the PD device is currently
running from RO or RW FW.
BUG=chrome-os-partner:34599
TEST=Manual on Samus. Run 'ectool --name cros_pd infopddev 0' and verify
that correct RO/RW status of Zinger is printed. Verify that the output
matches the index printed by "pd 1 hash" on samus_pd console.
BRANCH=Samus
Change-Id: I4266cae931f5c7855ca0531717c4a18b138b2d62
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Modify board_set_active_charge_port to return status indicating whether
the selected charge port was rejected. If rejected, zero out its
available charge and attempt to select a different charge port.
Also, reduce the length of related console prints.
BUG=chrome-os-partner:34677
TEST=Manual on Samus. Plug C-to-Arec into port 1, verify that charge
manager does not select port 1 as active and charging icon is not seen
in OS.
BRANCH=Samus.
Change-Id: I56e3337f90c04b93ef7cc9873af6ee0f4b1ffc7d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236361
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON to be defined at the board
level to be the minimum battery percentage required for power-on. If the
battery level is below the threshold, or if the battery is missing,
power button presses will be ignored.
BUG=chrome-os-partner:31127
TEST=Manual on Samus with subsequent commit. Verify that AP continues
to boot normally when charge level exceeds
CONFIG_CHARGER_MIN_BAT_PCT_FOR_POWER_ON. Verify that power button
presses are ignored when the charge level is below the threshold, and
we return to G3.
BRANCH=Samus
Change-Id: I0ff3f7ddabf38080332470e172c8b2e307bf1655
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236021
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Added check for collision just before transmitting on CC line.
To check for collision, RX monitoring is left on all the time
(except when in the act of receiving or transmitting, or in
between receiving and sending a goodCRC), and a
simple check for RX transmission started is used to see if the
CC line is idle or not.
RX monitoring is also changed to only trigger on 3 edges within
20us, as per the PD spec.
When a collision is detected by seeing that CC is not idle, the
transmitting packet is dropped.
BUG=chrome-os-partner:30135
BRANCH=samus
TEST=load onto samus and zinger. make sure we negotiate and make
sure custom VDMs succeed. enabled pings and made sure we stay
alive with pings for a few min.
Also added code to pd_rx_handler to toggle a test point on EVT
board to verify the timing of when we get RX interrupts:
Change-Id: I22d172163319437d3d901e019eda79d4d592f6b8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226118
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a rate limiter to host commands so that a host that is continuously
sending host commands doesn't watchdog the EC.
BUG=chrome-os-partner:33905
BRANCH=samus
TEST=loaded onto samus and tested remote update of zinger 10 times.
also tested EC + PD software sync.
Change-Id: Ia024179c46b2180ee97ea1902de343306142311c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235530
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Ryu sensor hub has asymectric RO/RW images. The first one is very limited
(not i2c master, no sensor drivers, gesture recognition).
Image size is alter to offer more space for the RW firmware image,
compiled with ryu_sh board.
To write RO image and basic RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w /tmp/ryu_sh_loader/ec.bin
To write the expected RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w -i EC_RW:/tmp/ryu_sh/ec.bin
BRANCH=ToT
BUG=chrome-os-partner:33908
CQ-DEPEND=CL:231970,CL:233233
TEST=load on Ryu, confirmed limited operation.
Change-Id: Ib976e2b048935adfb9b2b072c071db5be2bc1c09
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231984
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add high (and low) battery temperature warning which sends host
event to AP. After 30 seconds of out of range temp readings force
shut off AP and hibernate the EC.
BUG=chrome-os-partner:27641, chrome-os-partner:33111
BRANCH=samus
TEST=make buildall, and write unit tests to test this condition.
Change-Id: I95b7d9d753c17e4b76218a9845aa63dd1b96a500
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235645
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On samus it is possible to have AC plugged in but have the battery
discharging. So, add a new variable to charge state machine for
battery charging status and use that where necessary. For example,
the low battery shutdown code should now be based on whether or
not battery is charging rather than if AC is present.
This also changes the hibernate behavior when battery is low. The
change is to wait 30 seconds in G3 of low battery with no charging
before hibernating because for some chargers, like a USB PD charger,
the charger may increase it's current limit after a little bit of
time.
BUG=chrome-os-partner:34485
BRANCH=samus
TEST=test on samus. use low power charger and make sure that
ectool battery shows the "DISCHARGING" flag. use zinger and see
"CHARGING" flag. also use power_supply_info to make sure that
the battery state accurately reflects reality.
Change-Id: I8ac0267dd393071c4ca1fa24fbc9a13bf27848a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235491
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Fix bug where if we have a non-PD aware charger, we constantly send
host events to notify EC of an input current limit change. This was
unintentionally broken when adding code to constantly monitor the
CC line pull-up strength and adjust the current limit accordingly.
BUG=none
BRANCH=samus
TEST=plug in a non-PD aware charger and make sure it sets the correct
input current limit and that it is not constantly sending host events
that the limit has changed.
Change-Id: I7d835769ebc768043a9a46f50721987dce0384f5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235414
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
For the transmitter to clear CHARGE_DONE, charging must be enabled.
Therefore, we should always enable charging when the lid is just closed.
BRANCH=ryu
BUG=None
TEST=Test on Ryu p1.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I44f3d7c9e413a63be66ccf9695fea5411b2067b6
Reviewed-on: https://chromium-review.googlesource.com/231121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a PD charger is attached and immediately becomes our charge port, we
will request PD_REQUEST_MAX twice. Remove this needless re-request by
storing the previous request, and only re-requesting from
PD_STATE_SNK_READY if the request has changed.
BUG=chrome-os-partner:34168
TEST=Manual on Samus. Plug Zinger as lone charger, verify that 20V @ 3A
is requested only once. Plug second Zinger in second port, verify that
5V @ 3A is correctly requested.
BRANCH=samus.
Change-Id: Ife6fa9788e97a045edbca5d83933af57cd0ea91d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234701
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove common code across all PD policy layers to select the requested
voltage and build a Request Data Object (RDO).
BUG=none
BRANCH=samus
TEST=Load onto samus and connect zinger. Make sure we request the right
voltage (first 5V, then after initial contract is made, 20V). Make
sure input current limit is set appropriately by checking limit on EC
console using charger command.
Change-Id: Ic6bda5e23b2d7b7d710ffdf085e7fbc1b0c3add9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233673
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Turn on PP5000 when AC is plugged in in G3 so that the PD
MCU can accurately measure the CC voltage.
BUG=chrome-os-partner:33909
BRANCH=samus
TEST=test with various type-C chargers. verify that in G3 the
pp5000 rail is on when AC is plugged in, but off when AC is
unplugged
used reported battery current to estimate that turning on
PP5000 rail in G3 consumes an extra 30mW of power, but that
shouldn't matter much when AC is connected.
Change-Id: I3cdd2aaf3e7688d69a65e5d11e38e5b9cf16e703
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233734
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This exposes the pd_exchange_status() function and lets it
return the charge port that the PD reports, so that the lightbar
TAP sequence can decide which direction to display.
BUG=chrome-os-partner:32227
BRANCH=ToT, samus
TEST=make buildall -j
Change-Id: I78b57fbeaaf38fee15c86eca4d90abce77e2f722
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232092
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If override charge is selected on a port currently acting as a charge
source, but the attached device is also capable of acting as a source,
request a charge role swap and initiate a pending delayed port override.
If the role swap completes successfully and a charge source is found,
the selected port will become the override port. If the role swap fails
or no charge source is found within 2 seconds, the delayed port override
will be lost.
BUG=chrome-os-partner:28343,chrome-os-partner:31195
TEST=Manual on Samus. Connect two Samus units together through charge
ports.
"pd 1 swap power" - put port on test device into source role
"chgoverride 1" - set charge override, verify that role swap takes
effect and charge manager selects PD charge source, 900mA @ 5V
Disconnect charge cable, verify that charge manager goes back to not
charging.
BRANCH=Samus
Change-Id: Iadcc4dc98631661f254245eeff18973df517f652
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231900
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Samus USB ports can't actually act as UFPs, so open switches when in
UFP mode.
BUG=chrome-os-partner:32003
TEST=Manual on Samus. Connect two Samus units, run `pd 1 swap data`,
verify that switches are opened on switch to UFP. Unplug samus and
connect a USB 2.0 device instead, verify that ports are again closed.
BRANCH=samus
Change-Id: I9e1ca58089caf29e419698c8426bf8b72500833a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233711
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The new hard reset recovery state was endlessly sending hard resets.
Added in hard reset counter to cap the number of hard resets for
a sink.
BUG=none
BRANCH=samus
TEST=test with non-PD type-C charger and verify that we only send
two hard resets and set the appropriate input current limit after
the hard resets.
Change-Id: I95a3739be28ad2a5fed245aad021bcd6d51d94b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233754
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When we receive source capabilities packet from a source, if we are already
the active charging port, then we know we can request max power, otherwise
request vSafe5V. Normally, when you first attach a charger, the port won't
already be the active charge port when we receive source cap. But, if we
already have a power contract with a source and the source sends us new
source capabilities, then this comes in to play.
BUG=chrome-os-partner:34168
BRANCH=samus
TEST=test with plankton. when you press the 5/12/20 V buttons on plankton
it changes the source capabilites of plankton and sends a new source cap
packet to samus. thus, without this change, when you press one of the buttons
twice, the second button press causes us to negotiate to vSafe5V instead
of the max power. with this change, the requested power stays constant
when plankton re-issues source capabilities.
Change-Id: I3cc1e6b109117566f59de07762fd1af9adec05bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233753
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Do not allow remote PD firmware update of a device that is providing
us power when we have no battery (or else we will lose power).
BUG=none
BRANCH=samus
TEST=attach a zinger that has an old FW to samus with no battery and
see that host attempts to update FW but PD MCU does not allow it.
Change-Id: Iaf816dc44017d9c65a2b248ea8536d7c03898910
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233752
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Before sysjump we need to send a soft reset to any attached devices
and then disable PD communication so that we don't re-negotiate again
before the sysjump. This will guarantee expected message ID is cleared
for after the sysjump.
This also moves executing soft reset from before sending the soft reset
command to after the port partner accepts a soft reset.
BUG=none
BRANCH=samus
TEST=test on samus. without this change, when sysjumping the PD MCU
has time to re-negotiate (at least partially) before the sysjump, which
causes various problems. with this change, when sysjumping, the PD
MCU sends soft reset, and then does not send anything else.
Change-Id: Id7a60c62c8908ee4ab33dfbe995ef136b0aa83de
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233751
CL to migrate the flashing VDMs from zinger's custom vdm to
common/usb_pd_flash.c such that other updateable type-C devices can
share.
Additionally adds gaskets to call standard runtime flashing facilities
for USB-PD devices using it.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
Try following:
1. From samus_pd console w/ zinger in port 1
pd 1 flash version
pd 1 flash reboot
pd 1 flash info
2. From samus linux prompt w/ zinger in port 1
ectool --name cros_pd flashpd 1 1 <zinger RW payload>
Reading 16384 bytes from
/usr/local/zinger_v1.1.2528-d809e42.ec.RW.bin...
Erasing expected RW hash
Rebooting
Erasing RW flash
Writing RW flash
Rebooting PD into new RW
Complete
3. Repeat 1&2 above on hoho & dingdong.
Change-Id: I018055fa9de128f937c57debdc21dea026137bcf
Reviewed-on: https://chromium-review.googlesource.com/231835
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
dingdong/hoho have no capability to measure VBUS which is advantageous
in determining what timeouts to honor. Previously we simply assumed
vbus was on and that made things happy until,
e0c80ac pd: on hard reset go to a hard reset recovery state
which introduced proper handling around sink & source reset recovery.
With VBUS assumed 'on' this leads to short timeouts chosen
(PD_T_SAFE_0V) which in turn causes sink to resend hard resets before
source has had time (PD_T_SRC_RECOVER) to handle request.
This change creates config CONFIG_USB_PD_NO_VBUS_DETECT for devices
without the capability to account for lack of VBUS detect.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34090
TEST=manual
from samus_pd 'pd 1 flash reboot' is successful
Change-Id: I9ef9b0115c7be6c56c64556d2ce8c296f95c614e
Reviewed-on: https://chromium-review.googlesource.com/233024
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
EAh is used at the end marker for calculating hash in EC.
The extra EAh make hash calculated by EC different from calculated in host
by sha256sum for the RW image. The RO image is fine.
Fix a comment, no A,B images anymore.
BUG=chromium:438326
TEST=Check sha256sum is similar for Ryu EC image.
On EC console
> hash rw
[28.740271 hash start 0x00010000 0x0000ea24]
> [28.938875 hash done e2c40d0168ce4b20e8320438c7fc719d2188d7f88d9cb7ca694527b3f507e534]
sha256sum of built image:
sha256sum build/ryu_p1/ec.RW.flat
e2c40d0168ce4b20e8320438c7fc719d2188d7f88d9cb7ca694527b3f507e534
build/ryu_p1/ec.RW.flat
TEST=Check firmware upgrade still works:
Using a modify version of coreboot with
- ryu_p1 as main ec firmware
- code to reenable SW sync: CL:233222
Ryu with an older image:
cros_ec_init: CrosEC protocol v3 supported (128, 128)
Google ChromeOS EC driver ready, id 'ryu_p1_v1.1.2570-942248a'
Clearing the recovery request.
VbEcSoftwareSync(devidx=0)
EC hash:e2c40d0168ce4b20e8320438c7fc719d2188d7f88d9cb7ca694527b3f507e534
EC-RW hash address, size are 0x835b4ff8, 32.
Hash = b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
Expected hash:b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
EC-RW firmware address, size are 0x837f9374, 59924.
VbEcSoftwareSync() - expected len = 59924
Computed hash of expected
image:b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
VbEcSoftwareSync() updating EC-RW...
VbEcSoftwareSync() jumping to EC-RW
VbEcSoftwareSync() jumped to EC-RW
VbEcSoftwareSync() in RW; done
Check that at next reboot the firmware is not upgraded:
cros_ec_init: CrosEC protocol v3 supported (128, 128)
Google ChromeOS EC driver ready, id 'ryu_p1_no_version'
Clearing the recovery request.
VbEcSoftwareSync(devidx=0)
EC hash:b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
EC-RW hash address, size are 0x835b4ff8, 32.
Hash = b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
Expected hash:b183cd58d668d3d42a7cec95f2dcbb8ddee33f6a42d873f4b78106f85d341b46
VbEcSoftwareSync() in EC-RW and it matches
BRANCH=ToT
Change-Id: I2db275a16b16fbcea95f53287e95104ba921593e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232952
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For accessories without software-sync mechanism, add the option to do a
RSA-based signature verification of the Read-Write firmware.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31192
TEST=enable the configuration on Fruitpie and see the RW firmware
validated and jump to. Tried with good and bad RW images.
Change-Id: I3c886c2cbe17ca9543e19bf8599061c3f9751d4f
Reviewed-on: https://chromium-review.googlesource.com/229594
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
We still need to decide which direction to use. Refer to the bug
for details & discussion.
BUG=chrome-os-partner:32227
BRANCH=ToT,samus
TEST=make buildall -j
From the EC console, use
lightbar seq tap 0
lightbar seq tap 1
If you don't give the third arg, it just uses the previous direction.
Change-Id: I3a6566e8ba18d392f8d9d3419745a5377d22db25
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231893
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When other tasks call lightbar_sequence() to indicate power state
changes, a single-bit event is delivered to the lightbar task and
the requested sequence is saved in a variable. This is
intentional, because we want the lightbar to run only the most
recently requested sequence.
Of course this means there's a small race condition, which caused
occasional problems. This change reduces the window for problems,
by making a copy of the requested sequence immediately after the
event is delivered (rather than after printing a bunch of stuff),
and then having the current sequence function return that new
sequence back to the lightbar_task() main loop.
While we're at it, the transitional sequences (S5S3, etc.) can
just return their next sequence directly instead of letting that
decision be made in the lightbar_task() loop.
BUG=chrome-os-partner:33401
BRANCH=ToT,samus
TEST=make buildall -j
Power on/off, reboot, open & close the lid, double-tap, etc.
Watch the lightbar the whole time. It should do the right thing.
Change-Id: Icbe96194e523ef4d85d2643ec14675cf5c893dc0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix bug where if a power swap fails in the final stages, it
will have switched its CC resistor, but will not have actually
switched roles, which causes all sorts of weirdness.
BUG=none
BRANCH=samus
TEST=make buildall. tested power swap between two samus'. modified
one samus to never send PS_RDY when in PD_STATE_SNK_SWAP_COMPLETE,
and verified that when source asks for power swap and fails, that
it properly resets CC to pull-up.
Change-Id: If0fc8d3d51ede3be1160ae3b106061edabeaa948
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231193
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
