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>
In sink hard reset recovery, when VBUS finally goes high, go
to SNK_DISCOVERY quickly so that we can set our SINK_WAIT_CAP
timer.
BUG=none
BRANCH=samus
TEST=tested with zinger. when samus sends hard reset, it goes
to SNK_DISCOVERY quickly after VBUS goes high.
Change-Id: Ie5b3ed95ea9e0c405861be71bd694b057de289d0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231397
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Remove host_event_commands.c from build to save flash space. The
PD MCU does not use host event infrastructure and instead has a
simple gpio line it uses to notify EC that it has info to share.
BUG=none
BRANCH=samus
TEST=make buildall. view the .map file and see we save about 700
bytes of flash.
Change-Id: I71b8a4e32b9ecb57eb1a57f6d28652476ee6afe6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231444
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
I need more information to find the source of some problems. This
just adds a little more context to the lightbar console messages.
BUG=chrome-os-partner:33401
BRANCH=ToT,samus
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I97a210754833c9384eae517f9df2e97d3a9ea6b4
Reviewed-on: https://chromium-review.googlesource.com/231136
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added new hard reset recovery states for sink and source state machines
and transition there on hard reset. This is necessary because on a hard
reset we are not supposed to turn off vconn, nor disconnect USB, nor
switch the data role. In other words hard reset is not the same as a
disconnect.
This also changes timing around when to send source cap after a hard
reset and when to expect source cap after hard reset.
This also adds a delay between sending hard reset and executing it to
give time for sink to recognize the hard reset as differentiated from
a disconnect when VBUS goes down.
For sink, when a hard reset is issued or received, sink waits for VBUS
to go away, then for VBUS to come back, and then starts the sink wait
cap timer.
BUG=none
BRANCH=samus
TEST=make buildall
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Icb6ceaf242cebfcf8d08d7317976f83286a256ff
Reviewed-on: https://chromium-review.googlesource.com/228111
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Without a PD contract, regularly monitor CC line voltage to determine
if CC pull-up has changed its current advertisement.
BUG=chrome-os-partner:33682
BRANCH=samus
TEST=test with donette prototype: plug in one donette port to a samus,
see it set current limit to 3A, then plug in another port to a different
samus and see the first samus lower the current limit to 1.5A.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I965ab5fde7a67025f3f7ea34eb86fa35187080a6
Reviewed-on: https://chromium-review.googlesource.com/230594
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
If our request is rejected, go to SNK_READY, but don't set
explicit contract flag.
This also changes charge manager slightly to avoid new power
request loops. A new power request is only requested if the
charge port changes, or if the active charge port changes its
voltage/current offering. A new power request does not occur
if the current ceiling changes, since the existing contract
still suffices.
BUG=chrome-os-partner:33692, chrome-os-partner:28332
BRANCH=samus
TEST=make buildall. use samus and make sure we negotiate for 20V
as normal. modify zinger to send a REJECT and make sure we go from
PD_STATE_SNK_REQUESTED to PD_STATE_SNK_READY and explicit contract
bit is 0.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Iec02663364dcdc4aa66c681ec08911db7424abbc
Reviewed-on: https://chromium-review.googlesource.com/230522
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add tSenderResponse timeout to waiting for response from a request
message. If timeout triggers, send hard reset.
BUG=chrome-os-partner:33687
BRANCH=samus
TEST=test with zinger that we can negotiate normally. then modify
zinger code to not send any response when it receives a request and
see that samus sends hard reset from PD_STATE_SNK_REQUESTED.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: If147d809cfe185ec714e292a4814fbbfb50af04b
Reviewed-on: https://chromium-review.googlesource.com/230521
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add flag for whether or not a type-C port is in an explicit
contract. This flag will be used in the future to determine if
VDMs can be sent.
BUG=chrome-os-partner:33861
BRANCH=samus
TEST=load onto samus. plug in to zinger, use pd 1 state to verify
explicit contract bit is set. plug in to another samus, issue a power
swap, see contract bit go away and come back when contract is
established.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I9404e7cc920ebe0b37d9efae758436cc6aa7be85
Reviewed-on: https://chromium-review.googlesource.com/230520
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ensure that the PD source changes the output voltage after
tSnkTransition delay after having sent the ACCEPT message
(rather than before).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33684
TEST=connect Zinger to a PD power sink and monitor VBUS and CC while
doing a 20V to 5V transition.
Change-Id: If86f59eec67630491f4e8dc13a52015ac2de918a
Reviewed-on: https://chromium-review.googlesource.com/230805
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The latest gcc picked up a couple out-of-bounds issues, so
"make buildall" was failing. This fixes them.
BUG=none
BRANCH=ToT
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idcd6a3358ecbb0e0d2a610e1cd28c2f138ce520b
Reviewed-on: https://chromium-review.googlesource.com/231156
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add host command to set charge port override.
BUG=chrome-os-partner:32003
BRANCH=Samus
TEST=Manual on Samus. Insert PD charger in port1 and BC1.2 charger in
port0.
./ectool --name=cros_pd chargeoverride 0 --> Charges from port 0
./ectool --name=cros_pd chargeoverride off --> Charges from port 1
./ectool --name=cros_pd chargeoverride dontcharge --> No charge port
./ectool --name=cros_pd chargeoverride 1 --> Charges from port 1
./ectool --name=cros_pd chargeoverride 2 --> Correctly returns error
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib35f797a4a24e96fd2e3c008ace3fd6291b89d25
Reviewed-on: https://chromium-review.googlesource.com/230910
Reviewed-by: Alec Berg <alecaberg@chromium.org>
pd[port].timeout will be 0 immediate after set_state(), thus will cause
a negative value result for timeout calculation in the pd_task's ending
loop. This will cause task_wait_event to receive a negative timeout value.
Obviously it causes no harm to the current implementation, but should be
fixed by being paranoid.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Ib2817e1d95ca6c6eedcaff16a9e7e95033953901
Reviewed-on: https://chromium-review.googlesource.com/229760
Commit-Queue: Bernard Shyu <bernard_shyu@bizlinktech.com>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Bernard Shyu <bernard_shyu@bizlinktech.com>
Add commands to send PD packets and to tweak individual parameters (TX
clock frequency, RX detection threshold, resistors on CCx).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28337
TEST=verify that the PD sniffing is still working by dumping traffic
between Zinger and Samus.
Connect Twinkie to Zinger, set Rd by using "tw res NONE RD" and see VBUS
going to 5V (reading it using "ina 0").
Send a BIST mode 2 request using the following command :
tw send 2 0x1043 50000000
and see the other end starting sending BIST.
Change-Id: I3c8ddf858435ac1c17a43f59351bbaa69603a209
Reviewed-on: https://chromium-review.googlesource.com/227778
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
With this change we can use power event to configure sensors
and trigger motion detection in suspend.
BUG=chrome-os-partner:31071
BRANCH=ToT
TEST=Check power states. Check power up messages and commands are
present at the console.
Message at boot:
[0.007142 hash start 0x00010000 0x000096dd]
[0.007293 Inits done]
[0.007506 power state 2 = S3, in 0x0000]
[0.007765 power state 3 = S0, in 0x0000]
[0.007908 event set 0x00002000]
[0.008021 hostcmd init 0x2000]
[0.146870 hash done
f87d7824b439db923d270df016af5aabec51b73505b7c4faa6e40c16b12dd392]
Change-Id: I9c56fe5203506462f0820bbc8a5fe4528f6805ac
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226881
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
MOTIONSENSE_CMD_DUMP is deprecated, replaced with MOTIONSENSE_CMD_GET_DATA
Also use vector_3_t instead of x,y,z
ectool motionsense commands only work with newer firmware, to
handle a dynamic number of sensors.
- The host sends the number of sensor it has allocated space for.
- If 0, the EC just sends the number of sensors available
- Otherwise returns sensor information up to the limit imposed by the host.
Remove MOTIONSENSE_GET_STATUS: not needed. It is only useful for LPC,
to guarantee atomicity of the data.
Remove MOTIONSENSE_GET_DATA: not needed since we increase the version
number of MOTIONSENSE command.
BUG=chrome-os-partner:31071,chromium:430792
BRANCH=ToT
TEST=Compile. On a firmware that support the new command:
/usr/sbin/ectool --name=cros_sh motionsense
Motion sensing active
Sensor 0: 92 15 1030
Sensor 1: -94 -63 718
/usr/sbin/ectool --name=cros_sh motionsense active
0
On a machine with older firmware (samus), check these
functions are not working anymore.
Change-Id: I64b62afff96670fb93457760d43d4e64e26e029f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Factory test process need lid switch no function or keep lid opened
BUG=chrome-os-partner:33304
BRANCH=paine,yuna
TEST=Run command "ectool forcelidopen 1" and "reboot". Then lid close
quickly, the system boot as lid opened.
Deault value or run command "ectool forcelidopen 0" make the device normal.
Change-Id: I94527b7ef7f9efe779c6b86f3eab651f99af6000
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/230180
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Don't charge from dual-role capable ports, unless an override is set to
force charge. Also, if an override is set to charge from a dual-role
capable port and a dedicated charger is attached, remove the override.
BUG=chrome-os-partner:32003
TEST=Pass unit tests
BRANCH=Samus
Change-Id: I4e81e39a9f6ba325fa8a5e8f0d77fd5bfc7a672c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229465
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a Google Firmware Update alternate mode to zinger. This mode must
be entered in order to allow the unstructured VDMs that we use for
sending a new firmware.
BUG=chrome-os-partner:33754
BRANCH=samus
TEST=load on samus and zinger. see that "GFU" is printed on zinger console
to represent that it entered GFU mode. use twinkie to see that samus
sent discover identity, discover svids, discover modes, enter mode, and
then read info. See on samus pd console that we received result of read
info. from samus pd console with zinger attached:
> pe 1 dump
IDENT:
[ID Header] 2c0018d1 :: AMA, VID:18d1
[Cert Stat] 00000000
[2] 50100001 [3] 00000003 [4] 52136b91 [5] 0401137d
SVID[0]: 18d1 MODES: [1] 00000000
MODE[1]: svid:18d1 caps:00000000
Also, use a samus with cros_pd_update running in kernel, and see that zinger
auto-updates when plugged in. Performed 10 updates with no failures.
Change-Id: I8d4d38e4a9f649fe0889f688f262630ef55106ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229622
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow to use larger RSA keys by setting CONFIG_RSA_KEY_SIZE to 4096 or
8192 rather than using the default 2048-bit size.
It's mainly for benchmarking purpose right now as we don't have the RAM
to store the 3x key size buffer and the flash space for the public key
structure.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=build Zinger with CONFIG_RSA_KEY_SIZE equals to 4096 and run it.
Change-Id: I9839121bf158d0a30dde1e48d875f345191bfec2
Reviewed-on: https://chromium-review.googlesource.com/228925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Allow policy layer to request a PR or DR swap upon formation of
a power contract. Zinger always asks for a data swap so it can
be a UFP, and Samus asks for a data swap only if it is a UFP to
become a DFP.
BUG=chrome-os-partner:33754, chrome-os-partner:31195
BRANCH=samus
TEST=load onto samus and zinger and make sure they swap roles
upon connect with no collisions
Change-Id: I275c9669549c26f25c58f80845daad8edab11313
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229327
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changed actions to take on PD disconnect to do all the same actions
for source and sink disconnect. With power and data swap commands, there
are potential bugs with state variables not getting cleared properly
when separated source and sink disconnects are seperated out. Also
changed code to only take those actions on PD disconnect whereas before
it was also happening on dual role toggle.
BUG=none
BRANCH=samus
TEST=load onto samus, make sure it takes disconnect actions on when
zinger is unplugged.
Change-Id: I455f4970517477d4ffd38059110521b228282763
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229621
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
An earlier commit posted fan-change info to the console. Turns
out it's a little too annoying, and disabling it with the "chan"
command would also hide messages related to thermal shutdown.
This just removes those updates completely.
BUG=chrome-os-partner:33775
BRANCH=ToT,samus
TEST=make buildall -j
Watch the EC console. The messages no longer appear.
Change-Id: Ie8c48d7ce493a25bf0afbd26d280a87dda882c1a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229623
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It's really annoying to have to type two different commands. If I
want to read a location and then write it and then read it back
(which often happens when poking at hardware), then this:
rw 0x40570008
rw 0x40570008 14
rw 0x40570008
is much easier to enter than this:
rw 0x40570008
ww 0x40570008 14
rw 0x40570008
The "ww" command is still there, if you're really attached to it.
BUG=none
BRANCH=none
TEST=manual
Tried the example above. It worked.
Change-Id: I2302ed60df3dd3ec2224afa7c32d997bd2468ec1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
