Add support for toggling between source and sink as dual-role
port. When transitioning to S0, we turn toggling on, when transitioning
to S3, we turn toggling off but remain in the same PD state, and when
transitioning to S5, we turn toggling off and force the PD role to a
sink.
Note, when toggling is off, the source disconnected state is
allowed to transition to sink disconnected, but not vice versa. This
means that if you go into S3 as a source, it will remain a source
until the device is unplugged, at which point it will transition to
a sink until the next transition to S0.
The spec specifies:
tDRP: 50ms - 100ms, Period a DRP shall complete a DFP to UFP and back
dcDRP: 30% - 70%, Percent of time that a DRP shall advertise DFP
tDRPHold: 100ms - 150ms, time to hold VBUS on after a DRP detects a UFP
tDRPLock: 100ms - 150ms, time to stay in DFP after detecting loss of UFP
This CL uses 40ms for time as a UFP (sink), 30ms for time as a DFP
(source), and 120ms for hold and lock times.
Also, if advertising as a DFP (source) and VBUS is detected, this
automatically switches to a UFP (sink).
BUG=chrome-os-partner:28782
BRANCH=none
TEST=test on samus, make sure we are toggling between source and sink
when disconnected. make sure plugging in zinger switches state machine
through to sink_ready and make sure plugging in a USB switches to
source_discovery. tested on a fruitpie by scoping the CC line and verifying
the timing (except the hold time which I can't easily test).
tested that dual role toggling is off in s3 and s5. also verified that
going into s3 as a source keeps the port as a source and going into s5
switches it to a sink.
Change-Id: I478634861f694164301d71359da35142ee7ebf75
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207154
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Host commands in the range 0x4000-0x7fff will be passed thru the EC to
the PD MCU as 0x0000-0x3fff.
BUG=chrome-os-partner:30079
BRANCH=samus
TEST=manual. On PD console:
hcdebug params
On EC console:
hostcmd 2 0 -> hex string of EC version
hostcmd 0x4002 0 -> hex string of PD version, and PD console shows host
command 2 was received. The hex response shown on the PD console
matches the one printed by the EC
Change-Id: Icc2d97c5977145a0c3ad2630d2b5a19e876a36d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207821
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Revert
- https://chromium-review.googlesource.com/#/c/205145/2
- https://chromium-review.googlesource.com/#/c/205147/4
Now using the real AC_PRESENT gpio signal instead of whether or
not the PD MCU negotiated for 20V.
BUG=chrome-os-partner:29841, chrome-os-partner:29842
BRANCH=none
TEST=tested on a board with reworked AC_PRESENT signal. Verified
that gpio is correctly reporting state of AC and is charging when
AC is plugged in. Tested the no battery case to make sure
board powers on and stays on with just a charger. Also tested the
dead battery case by plugging in a dead battery, then plugging in
a charger and making sure system powers on and starts charging.
Change-Id: I4424771c91c8a2aa19eda68a8b5194e9265d529c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206598
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The HW signals to control the type-C ports muxing have changed between
Fruitpie and Samus, update the code to match the HW.
Also add the docking mux option and update the board muxing code to
prepare for the automatic mode detection :
- the polarity will be determined by the PD code.
- the port muxing will be enable/disable by the common alternate mode PD
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: I0706626270c73d2a5e3f85b86e65a7c4fc21f9ec
Reviewed-on: https://chromium-review.googlesource.com/206685
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we reset the PD power source, ensure we always transition to
DISCONNECTED state, so we will re-enable the 5V power when transitioning
back from DISCONNECTED to DISCOVERY.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=Plug Firefly to Zinger and play with voltage transition buttons.
Change-Id: Ifa0f30391b2249b54385ce8c93df932e37803695
Reviewed-on: https://chromium-review.googlesource.com/206954
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Change PD sink to use VBUS for initial detection to match
USB type C spec.
BUG=chrome-os-partner:30116
BRANCH=none
TEST=Tested on samus. Connect and disconnect zinger a few times
and make sure we successfully negotiate each time.
Change-Id: Ifa9ff301cb34b6df6609d4bbbde3231bb029d554
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207000
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Verify the connection status at every FSM loop,
by monitoring VBUS presence for the sink and by monitoring CC going
above Vnc for the source.
Also ensure we are never stuck in the source transition state in the
sink doesn't ack the PSReady packet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=connect Firefly to Zinger, trigger hundreds of voltage transition,
record and analyze the PD traffic : no longer see spurious PSReady
messages.
Change-Id: I4495ae5415d53d77055fb2a562c594fa9a1d4dc8
Reviewed-on: https://chromium-review.googlesource.com/206945
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Once the source has successfully sent a SourceCap packet (ie it got
acked), it needs to transition from the DISCOVERY to the NEGOCIATE
state.
This was done when the source was sending unsolicited SourceCap, but
this was missing when the SourceCap was an answer to a Sink GetSourceCap
request. The usual effect of the missing transition was sending twice
the SourceCap triggering some collisions.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=plug a Zinger to a Firefly, randomly push the Firefly voltage
selection buttons and see the transition always happening properly.
Change-Id: If4b335e2144595f22ad4e9a8a9e289506f597407
Reviewed-on: https://chromium-review.googlesource.com/206941
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This caused all platforms to check only the first 25% of each page to
see if it's already erased. Fortunately, we tend to fill flash pages
from the beginning, so in normal usage we don't hit this bug.
BUG=chrome-os-partner:30281
BRANCH=all (if convenient)
TEST=Make sure CONFIG_CMD_FLASH is defined. Then at the EC console:
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0xffffffff
flashwrite 0x1f3e0 0x20
rw 0x1f3e0 -> 0x03020100
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0x03020100 (bad!) or 0xffffffff (good)
Change-Id: If78b08b5e0414993a440bc8cd707b5ce70eb1a0a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206891
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
(cherry-pick back to ToT)
Clear the CHARGE_INHIBIT bit when requesting non-zero current/voltage
and set it when charging should be disabled. On Blaze with the
BQ24725 charger, setting this bit saves 10-15mW when we're not on AC.
This also fixes an issue where battery charging would not get enabled
when the charger is connected while the machine is in S3/S5. This is
because the kernel driver would inhibit charging when the charger was
removed and then the EC would not enable it when the charger was
re-connected while the host was off, such as in S3/S5.
BRANCH=nyan
BUG=chrome-os-partner:29386
TEST=Boot Blaze, disconnect charger, suspend, connect charger and
observe that the battery now starts charging.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203163
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit bd4469ae4ffbbd6f2cd5549bdb8809838e55d6f7)
Change-Id: Ibcb635b01a2292f214f71ab400ec34cd12e7536f
Original-Change-Id: I2efaf02296dc08c0de85950a70ad2592f4428241
Reviewed-on: https://chromium-review.googlesource.com/206909
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Until now when send_validate() receives another valid packet in place of the
GoodCRC, it was continuing its retries loop. But given that the presence
of a valid packet indicates that the other side is trying to send us
something, it's better to bail out immediatly and wait for its retry.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29847
TEST=repeatly plug and unplug a Zinger to a Samus and record the traces
of the PD negociations.
Change-Id: I901bd8d85999ed195ed9887d7375806f61222f8b
Reviewed-on: https://chromium-review.googlesource.com/206391
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add a retry mechanism for EC to PD host commands to make the
communication channel more robust.
BUG=none
BRANCH=none
TEST=run on system to verify that we don't drop host commands
to PD MCU.
Change-Id: Ida6f02a149e4dd9e85a5aac21790928b16864104
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205148
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a temporary workaround to allow dead battery charging without
an AC PRESENT signal by delaying going into hibernate with an extremely
low value in order to check if AC is present by waiting for PD MCU.
BUG=chrome-os-partner:29842
BRANCH=none
TEST=Test with a dead battery that when you plug in AC and reboot, it
is able to charge. Previous to this change with a dead battery and AC
plugged in the EC would boot and almost immediately go back into hibernate
Change-Id: I338a0cc9ee37dab3e6caf29369ac6e819772ca91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205147
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The ACOK input to the EC is not connected to the charger so
that signal cannot be relied on for AC presence. Instead
have the PD report when it negotiates to 20V and when it
disconnects and have the EC use that for AC presence.
BUG=chrome-os-partner:29841
BRANCH=none
TEST=test charging with zinger on samus system.
Change-Id: Ia9096a24ab05d110e31910218dc8c214a846a9a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205145
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
We never implemented this. We have no devices which support it. And
we used bit #17 in a 16-bit field to flag it, so it wouldn't have
worked even if we did. So, remove this (dead) code.
BUG=chromium:382944
BRANCH=none
TEST=make -j buildall
Change-Id: Id3a4a93612d1078a3239d85921a05cfd7362b84c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204162
Reviewed-by: Doug Anderson <dianders@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
Increase the delay after receiving a good CRC in send_validate_message()
to avoid catching the last edge as the start of a new packet.
BUG=none
BRANCH=none
TEST=Tested with zinger and samus using the python script to flash
zinger RW, and simply negotiating power and receiving pings.
Change-Id: Iffdd73e02e5d292396d46a611d728f66402f2da4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203206
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds a new lightbar sequence (TAP), which temporarily displays the
battery level. It pulses if the system is charging.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
From the EC console, run
lightbar seq tap
The lightbar should change temporarily.
Then run
lightbar demo on
and press the Up, Down, Left, and Right keys to fake the battery charge
level (up & down) and the AC present state (left & right). Run the
lightbar seq tap
command periodically to watch it change.
Change-Id: I84ff928d93060f7ef7d46d608732d37cf5185aff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202964
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On samus battery, when the battery is dead it reports 0 for desired
voltage, current, and state of charge. In this case we should allow
charging.
Added a CONFIG option for this that should be removed as soon as
the battery side is fixed.
With this CL, when a dead samus battery is used and a charger is
connected, we attempt to charge it.
BUG=chrome-os-partner:29465
BRANCH=none
TEST=test on a samus with a dead battery. w/o this CL, the battery
never charges because the charging not allowed flag is set. With this
CL, the battery charges.
Change-Id: Ic61f27a27237166d33cb9ea5f024d3ef6360ce82
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202603
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When this option is configured, two changes take place.
First, the AP doesn't power on by default when the EC reboots. To boot it,
you can run the "powerbtn" command, or poke the power button manually, or
any of the normal things.
Second, we watch for power-related signal changes (anything that's connected
to the power_signal_interrupt() function) and keep track of them as they
happen. After a second with no further changes, we print the time and value
of each change. For example:
[19.939212 Port 80: 0x29]
[19.967971 HC 0x23]
[19.976236 Port 80: 0x3a]
[19.995700 HC 0x87]
[20.567884 Port 80: 0x73]
11 signal changes:
19.638241 +0.000000 PCH_SLP_SUS_L => 1
19.654378 +0.016137 PCH_SLP_S5_L => 1
19.654457 +0.000079 PCH_SLP_A_L => 1
19.654535 +0.000078 PCH_SLP_S3_L => 1
19.654587 +0.000052 PCH_SLP_S4_L => 1
19.659630 +0.005043 PGOOD_1_5V_DDR => 1
19.663199 +0.003569 PGOOD_1_5V_PCH => 1
19.664751 +0.001552 PGOOD_1_8VS => 1
19.668735 +0.003984 PGOOD_VCCP => 1
19.671883 +0.003148 PGOOD_VCCSA => 1
19.868406 +0.196523 PGOOD_CPU_CORE => 1
[21.908551 Port 80: 0xf0]
[21.908855 HC 0x48]
BUG=none
BRANCH=ToT
TEST=manual
Build with CONFIG_BRINGUP, notice those two changes.
Change-Id: I55fd2021a0eae7dbfd1aaf5d93971f65bf2367b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202574
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Moved sampling of ALS to its own task. The problem is that it
spin waits on the i2c bus mutex, and it's a bad idea to spin wait
for very long in the hooks task because the hooks task tickles
the watchdog.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=tested on samus: make sure ALS task is running and no
watchdog timeouts when the i2c bus is wedged indefinitely.
Change-Id: Ifcebabdfc151ea85cecdfe7a8ed489e8a82ee5ba
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202545
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For non-PD aware sink, ensure that we detect their disconnection when
the CC goes back above Vnc.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28782
TEST=on Samus, put the port in source mode (using the "pd charger"
console command), then plug and unplug the type-C to type-A cable and see the
PD state going from Disconnected to Discovery and the other way round
(using "pd state" console command).
Change-Id: Ic9e19fee78f0c5e1fc742e2443eaf4b804ee5ee9
Reviewed-on: https://chromium-review.googlesource.com/202445
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Support bist carrier mode 2 - continuously transmit alternating
1's and 0's, and check for bit errors on receive side. note
that once the test is started the only way to stop is to hard
reboot the devices involved.
BUG=none
BRANCH=none
TEST=connect two fruitpies together. set one to be source:
> pd charger
and then start the bist
> pd bist
start receiving data:
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa - incorrect bits: 0 / 0
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 - incorrect bits: 0 / 0
Change-Id: Id920f6b7177a418a80e1ce325042243cd633cec6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202187
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the current version of USB-PD standard, the packet header should have bit 15
set to 1 to tell the other side that we are supporting Biphase Mark Coding
(aka BMC).
For now, just set it, do not check it as most of our devices are setting it
yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: Ia6f89f592632520b46478a7d7975e9e8d3a28b59
Reviewed-on: https://chromium-review.googlesource.com/202391
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When sink receives a power request rejected packet, go back to discovery
state in order to retry transmitting request.
BUG=none
BRANCH=none
TEST=tested with zinger. when zinger has an over current fault, it
rejects requests for power. made sure that when device gets rejected
it goes back to discovery state.
Change-Id: Id532b69f52bd533e5d7ac1171d8833bc993a0e9f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201157
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For non-PD aware source, ensure that we detect their disconnection when
the CC goes back below Vnc.
BUG=none
BRANCH=none
TEST=when zinger gets into state where it is not talking PD, remove
charger and make sure we transition to disconnected state.
Change-Id: I675ff6d3300eda680acdd7814f0163f222eeb516
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201156
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add interrupt to VBUS signal to detect VBUS transitions
quickly to make sure we transition out of SNK_READY when VBUS
goes away.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Test on samus 1.9 board. Ran for hours with charger plugged
in, made sure when charger cuts out after missing ping responses,
that it successfully goes to disconnected state and renogiates
power.
Change-Id: I93b2e49891e6a38c98095b7311a9435606cc61ab
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201155
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Detect loss of VBUS when acting as PD sink and go to the disconnected
state. This allows us to renegotiate power when power supply drops
and switches to 5V.
BUG=none
BRANCH=none
TEST=On a samus, tested by running for a couple of hours, and verifying
that occasionally when zinger drops from 20V to 5V, we detect it and
go to the disconnected state. Note, this only happens a couple times
every hour.
Change-Id: I237d267824ff564662c9c02e525ce2613ed229e6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200365
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The commit 4ba7a15 has modified the traces resulting in a far larger overhead
(mainly due to %T doing dozen? of 64-bit divisions which is an expensive
operation on a Cortex-M0)
as a result the code is now missing communication deadlines.
for lack of a better solution, revert the modification is this file.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run PD communication between Zinger and Firefly,
and between Fruitpie and Samus and see communication
error rate is going down from 30% failure to less than a few percents.
Change-Id: I902b951450bc200baad722ae5d65053ceda5357b
Reviewed-on: https://chromium-review.googlesource.com/200326
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Allow flashing the RW firmware by sending Vendor-Defined Messages over
the USB-PD link.
This is not the secure update whose design is still under discussion,
it's a simple update with integrity check.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28330
TEST=using the following CLs,
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW, repeat the operations with different
builds of the RW firmware.
Change-Id: Icd90eb92f7321ccd66341a50b9dabd73c59c68c1
Reviewed-on: https://chromium-review.googlesource.com/197948
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Imported code from VBoot firmware cryptolib and slightly reformat it for
the EC code base.
We already have SHA-256, but for updates over PD, the maximum payload
size is 192 bits, so SHA-1 seems a better trade-off.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28336
TEST=none
Change-Id: I6da7b71a9af03c6689accfa3c59cfcf7776fcfc6
Reviewed-on: https://chromium-review.googlesource.com/199553
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This is useful for testing battery charge profiles. When enabled, a dump of
all battery, charger, and charge state information will be printed whenever
the battery charge percentage changes.
BUG=none
BRANCH=ToT
TEST=make buildall -j
On the EC console:
chg debug on
then watch the console while either charging or discharging the battery.
Disable with
chg debug off
Change-Id: I6725c461461f90fcd812873f97490e980ab47bc6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199816
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds an "extra/" directory to hold various experiments and optional
programs. With this change, we add a tool that can simulate the lightbar
behavior on the build machine. That can be used to experment with variations
in the lightbar pattern code without needing to reflash a Pixel with a new
EC to see the effect.
There is no functional change to the EC code, just a couple of #ifdefs to
allow common/lightbar.c to be compiled separately from the EC.
BUG=none
BRANCH=ToT
TEST=make buildall -j
cd extra
make
./lightbar
You may need to install the libxcb1-dev package on your build machine.
Change-Id: I847ce7ea97cae792b1de1b91f488819e873b6555
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199883
This puts the code that talks to the lightbar hardware in one file, and the
code that implements the pretty patterns and behavior into another. This
will let us make improvements or changes to the patterns without requiring
detailed knowledge of the controller chips.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=make buildall -j
Refactoring only. There is no new functionality.
Change-Id: I4e5fe8943385ddeab26bbd7e66c20e2dccd3dc43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new lightbar subcommands to the EC_CMD_LIGHTBAR_CMD host
command, allowing the AP to read the current brightness level, the
current lightbar LED values, and the state of demo mode.
Because this is new, also update LIGHTBAR_IMPLEMENTATION_VERSION. All the
previous commands are unchanged, though.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=manual
From the AP, run these commands to see the changes:
ectool version
ectool lightbar brightness
ectool lightbar 0
ectool lightbar 1
ectool lightbar 2
ectool lightbar 3
ectool lightbar demo
The version output is different, the other commands used to just emit
errors.
Change-Id: If32a5d2388217edc3ae7b9b091d66e9d2cf753be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
While debugging reboot issue, it was difficult to get POST code from failing
boards. Currently POST code is only accessible from EC console. Not all boards
are fitted with servo board.
This patch adds Port 80 history access from ectool. Reuse command code 0x48,
EC_CMD_PORT80_LAST_BOOT with version 1.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
BUG=chrome-os-partner:28514
BRANCH=rambi
TEST=manually test on rambi to confirm port 80 history match EC console
Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e
Reviewed-on: https://chromium-review.googlesource.com/198012
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
Detect over-current and over-voltage and trigger a fault.
The over-current threshold is 10% over 3A (3.3A).
Only currently implement the slow protection,
the fast interrupt-based one will be done later.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=with Zinger connected to an electronic load, adjust the current to
3.35A and see the output voltage cut.
Change-Id: I0e848192392fd73f0839d4bcb806528b2a6b9122
Reviewed-on: https://chromium-review.googlesource.com/197947
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
