Fix bug in pd transmission. The retry mechanism was not working right
and was causing us to not do any retries.
BUG=none
BRANCH=none
TEST=Test with a zinger unplugged from the wall. Samus sends source
cap and doesn't get a response. Verify on console printout that we
retried 3 times.
Change-Id: Id273bf054655c2d24a791f4eaf4cb8d87253abe2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Increase stack size to account for pd communication errors. With
lots of pd communication errors, I see a max stack usage of 520
bytes, which is larger than the old stack size of 488 and was
causing stack overflows.
BUG=none
BRANCH=none
TEST=load onto samus and generate pd errors by plugging in an
unpowered zinger (samus sends source cap every 100ms, but no
response). measure task usage.
Change-Id: Iab2b0f781cb39d8e1ea906de48bd5b37e229d291
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210580
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If chromeos-ec package hasn't been built, flash_ec tries to find
stm32mon in local build/ directory. However, this is broken in the last
CL when we move away from crosutils. Let's fix it.
BUG=chromium:397202
TEST=Flash samus_pd
BRANCH=None
Change-Id: I05395a727fa965032a24f51c07deaebf2d7c7e51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210419
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Packets can be 128 bytes, and are preceded by a prefix byte. So we
need a 129-byte buffer, not a 128-byte buffer.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=do pd software sync; see that 128-byte packets transfer correctly
Change-Id: Ic1e6cfec2c042537768d1cd0eecea509cc90c052
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210502
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previous assumption assumed that the flash was remapped
to address 0.
This is not the case anymore since cl/210063
BUG=chrome-os-partner:30997
TEST=Check we can boot the EC now.
BRANCH=None
Change-Id: I46e1dc0ad840b21661aa5d87817369b29a659c9b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210407
The script currently depends on common.sh from crosutils, which is not
installed on beaglebone and also pulls in dependency on other
repositories. Let's switch to shared shflags library and include output
formatting functions in flash_ec script. This way we are independent
from crosutils.
BUG=chromium:397202
TEST=Run the script to flash EC
BRANCH=None
Change-Id: Ib18987410eb32d773d55fb4e53133adf230167b9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209827
Reviewed-by: Dan Shi <dshi@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously if you were working on a single board you had to add BOARD=
to all of your make command lines. Now if you are in a board directory
you can just use "make", or "make clean", or any other top level make
command.
This commit also adds support for a top level "make flash" command that
can be used from the board directories as well. This command uses
openocd and requires that the board provides an openocd-flash.cfg file.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=(from a few board directories) make clean; make -j
(from the discovery-stm32f072 directory) make flash
Change-Id: Ie09a74881371169a2c3cd9cd9922f39f4873f1a6
Reviewed-on: https://chromium-review.googlesource.com/209669
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Host commands can be generated by either the PDCMD task (in response
to PD interrupts), or the HOSTCMD task (in response to passthru
requests). Use a mutex to serialize access to the EC->PD interface.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Boot samus
Change-Id: If65d5eb4bbef91e6c811a06ea2e1487e17143dc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210401
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This is necessary for PD software sync. Also need to increase the
hook task size to avoid stack overflow.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=boot samus; on PD console, see hash calculated.
Change-Id: I37e571f9cd03a31eb4eaad903c3dda72f7e51fc1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209812
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Zinger EVT units will have hardware change for PA0 to be able to
wake up from standby. Part of the change is that we have to output
high on PA0 in order for the comparator to compare against 0.65V, which
is inverted from the previous version.
BUG=chrome-os-partner:28335
BRANCH=none
TEST=reworked a p2 zinger with PA0 changes, plugged into samus,
and verified we still charge.
Change-Id: I7344f1d1decddc4e6600e41c313e1e7a5a5de067
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209832
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On Ryu, we are using TPS65913, which doesn't support the 8-second long
key press power-off. Let's switch to firmware timer.
BUG=None
TEST=Do a long power button key press, and see the AP powering off and
not restarting.
BRANCH=None
Change-Id: Ic9eb6d525498c7cdedf8f053dd0a2fa2b568a443
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209850
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have three copies of 'typec' commands in three different boards. The
commands current mix hardware-specific logic and console command logic
together. Adding a board_get_usb_mux() interface to separate the logic
and deduplicate the console command logic.
BUG=None
TEST=make buildall
TEST=Test 'typec' command and verify GPIO settings.
BRANCH=None
Change-Id: Ie1825f49d32609c732db384679cb917f2f1a4082
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209955
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, on stm32f cortex-m0 systems, interrupts are always being
directed to the RO vector table. This can cause strange problems when
running RW software because it is still calling IRQ handlers in the RO
code.
Unfortunately, on cortex-m0 the ability to specify the vector table
location in flash (VTOR register) is optional, and stm32f0 parts do not
have it. Instead, in order to run RW IRQ handlers, at init time, this
CL copies the vector table from flash to the base address of SRAM
(0x20000000), and then selects SRAM to be mapped to 0x00000000 where
the core looks to find the vector table.
BUG=none
BRANCH=none
TEST=Tested on zinger.
- Verified that vector table is copied to SRAM by printing out 48 words
from SRAM base address 0x20000000 in main() and verifying that it matches
the vector table in flash in the disassembly.
- Verified the vector table at SRAM 0x20000000 points to the RW handlers
when in RW and the RO handlers when in RO.
- Also printed out PC in one IRQ handler and verified it was in the
appropriate section of code.
Also, ran on samus_pd and did a sysjump RW to make sure at least one other
system works.
Change-Id: I22aff1b5e0de9b23fd3324f0cbe4f6c45a81967e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add back in sending hard reset on board fault.
BUG=none
BRANCH=none
TEST=Using zinger and firefly, create an overvoltage error by down
stepping with a 0 VOLTAGE_DOWN_STEP_TIME, and make sure that a hard
reset is received by firefly and that we re-establish negotiation
after the OVP fault is cleared.
Also tested with zinger and samus. On samus I set the input current
to 3.5A, which immediately triggers an OCP, and verified that we
get a HARD RESET from zinger and that after the reset we negotiate
correctly and get back to normal (note that when VBUS goes down, the
EC resets the input current limit to default 2A, so that's why we
don't continue getting OCP).
Change-Id: I991b15411c4ce05c1086851b1e2e56e2effab749
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209865
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow a sink to request a new voltage without dropping the established
negotiation. For this to work the sink must save the last received
source cap packet and use that to make a new RDO from the SNK_READY
state.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Tested on a firefly connected to zinger. made sure we can press
buttons to change voltage and we don't lose the existing negotiation.
Also tested on samus, ports 0 and 1, using pd x dev 5/12/20 to switch
between voltages and verified we don't lose existing negotiation.
Change-Id: I5a550b667f3aff7975185e091f3caac4555a907e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209864
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug in which output was disabled on down voltage transitions.
This also changes the behavior of the OVP protection. On down-step
transitions, the OVP threshold is not lowered for a specified amount
of time after the transition to allow the output to dissipate down to
the new voltage. This will still catch a problem if the voltage goes
up instead of down, but avoid OVPing immediately on a normal down
transition.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Attach to firefly and probe output voltage. Make sure we
transition smoothly going down in voltage.
Change-Id: I7f3a0c17cc8b392a25d24d56d2b7155b806acb64
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209863
Board bring up. GPIO / UART / timer / console / task / hook are
working now.
BRANCH=tot
BUG=none
TEST=run on evaluation board and see LED 0/1 are blinking.
Console commands are available to use.
Change-Id: If93a2c94b8abe1c2c931c03a7a12ddd2bed9d9f6
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Some PMIC chip (e.g. TPS65913) doesn't support the 8-second long key
press power-off. For this, we have to check the state of the power
button in firmware, and do not assert PMIC_PWRON during the shutdown
sequence to prevent the AP from restarting.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=with the next CL, on Ryu, do a long power button key press, and see
the AP powering off and not restarting.
Change-Id: I03f703b4ff6d86edea150dfa32f60d30f1ddffd9
Reviewed-on: https://chromium-review.googlesource.com/207381
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
We used the incorrect src_caps index when choosing PD voltage. Let's fix
it to ask for all available power until we are able to ask only for what
we need.
BUG=None
TEST=make buildall
BRANCH=None
Change-Id: I068264246c2586b8192220eff47838da438899b0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207802
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The design voltage is 4.35V and the current charging voltage, 4.4V, is
too high. Let's lower this to 4.34V to meet the designed voltage.
BUG=none
BRANCH=none
TEST=none
Change-Id: Id5ab111d7ef390fe509adbb75112c78de1aab8a9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207687
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On most platforms, the power button is active low,
but the power button on Ryu is active high.
Add CONFIG_POWER_BUTTON_ACTIVE_STATE to override the default active
state.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on Ryu, use the servo pwr_button to start and stop the AP.
Change-Id: I11c6bb3c700bccd3606ce1fa1a69905671792990
Reviewed-on: https://chromium-review.googlesource.com/207274
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Update the code to be compatible with charge v2 expectations :
never return EC_ERROR_UNIMPLEMENTED for battery information else the
charge code continuously tries to read them again.
Fix the State Of Charge reading : on BQ27741 the gas gauge gets confused
if we do a 16-bit I2C read while a 8-bit read works perfectly.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run a Ryu connected to a Kirby battery and check the output of the
"battery" command.
Change-Id: Ic1d6128dc02efa47662fa5ca5b9e5de62420ebe8
Reviewed-on: https://chromium-review.googlesource.com/207273
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
The interrupt handler is hardcoded to I2C1. We should choose between
I2C1 and I2C2 based on I2C_PORT_EC.
BUG=chrome-os-partner:30707
TEST=On Ryu, ectool hello and see ACK.
BRANCH=None
Change-Id: I07055b0ee7459e6cac5585737e200ff2d5814a34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209960
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changes to match this part of the spec:
The Sink shall support the SinkWaitCapTimer. When a Sink observes an
absence of Source Capabilities messages, after VBUS is present, for a
duration of tTypeCSinkWaitCap for the Type-C connector and
tSinkWaitCap after VBUS is present,for all other connectors the Sink
shall issue Hard Reset signaling in order to restart the sending of
Source Capabilities messages by the Source (see Section 6.6.4).
tTypeCSinkWaitCap shall be between 210 and 250 ms
Also set send source cap period appropriately:
tTypeCSendSourceCap shall be between 100 and 200 ms
This should help avoid transmission collisions during negotiation.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load onto zinger and samus and verify they negotiate correctly
10 times. Then loaded custom code to zinger to not send source cap
and verified we send hard reset. Also tested plankton to samus
negotiation works.
Change-Id: Idd6118e3e0a9f7a96ebeae9518c8b10457232c70
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209558
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Board support for Planton, the Raiden testing board for type-C
functional testing.
BUG=none
BRANCH=none
TEST=make BOARD=plankton, load onto a plankton, and verify
buttons are read correctly, and connect raiden to samus and
verify that PD communication is successful
Change-Id: I40922d5627d62f7f3540ac6a307596428d40baf5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207724
Veyron only has one bicolor led (green and orange) near the AC connector.
I dedicated the green channel for displaying power status:
* Power on: Green
* Suspend: Green in breeze mode ( 1 sec on/ 3 sec off)
* Power off: OFF
Charging is now displayed only on the orange channel:
* Fully charged / idle: Off
* Under charging: Orange
* Battery low (10%): Orange in breeze mode (1 sec on, 3 sec off)
* Battery critical low (less than 3%) or abnormal battery
situation: Orange in blinking mode (1 sec on, 1 sec off)
* Using battery or not connected to AC power: OFF
The unfortunate side effect is that they have to share. So while the laptop is
charging in standby the led will blink orange(1s)-yellow(3s). While it's a
little ugly (it would have been nice to have 2 separate leds), it still provides
more information than how it was done before (where there was no indication of
power state).
BUG=None
TEST=Go through the various states (charging on/off/low and power on/off/
/suspend (warning: kernel doesn't report suspend to the EC properly yet, one can
still test this by reverting c/209668 "veyron: fixed SUSPEND_L line"))
BRANCH=None
Change-Id: I8ca0fb0909da1a186e4e5c451d8868e977b3ca1b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209911
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Commit-Queue: Doug Anderson <dianders@chromium.org>
for interface specific requests, the interface number is equivalent to
(wIndex & 0xff). this corresponds to ep0_buf_rx[2], since the setup
packet has format: bmRequestType (1), bRequest (1), wValue (2),
wIndex (2), wLength (2).
BUG=none
BRANCH=none
TEST=verify stm32 does not panic with multiple interfaces
Change-Id: Ied7750035f87fa81f9a6c03c6e73ae606c110398
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209903
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ensure that the slow OCP (thermal/power protection) is not triggering
for power spikes below 20us, by sampling 4 times (with a 5us sampling
period).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28331
TEST=connect Zinger to Firefly+electronic load, test with various
current pulse widths and amplitudes.
Change-Id: Ic8150dbbf191c002bba9e8d3f70beb47af4577b9
Reviewed-on: https://chromium-review.googlesource.com/204588
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Include a force source mode for dual-role ports to allow us to
force a dual-role port into being a source.
BUG=chrome-os-partner:28782
BRANCH=none
TEST=tested on plankton, verified using the pd 0 dualrole console
command.
Change-Id: Ic4c2a9e11984b34b1dec09d5c71e1fd15ed9198c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209071
Reviewed-by: Vic Yang <victoryang@chromium.org>
Adds dual USB-PD port support for samus. Both ports are in dual-role
and can perform either role.
Both ports work fine when only one of the ports is in use. But,
still having problems with PD errors on the lower priority port (port
0). If you have a charger plugged into port 0, and a type-C USB dongle
plugged into port 1, then port 1 has higher priority, and in the
SRC_DISCONNECTED state, every 1.5 seconds when it sends source cap
packet, we occasionally drop pings on port 0, which results in a
lot of start/stop charging.
BUG=chrome-os-partner:28585
BRANCH=none
TEST=Tested on samus to make sure both ports work when I
plug in a charger and a type-C USB dongle with a pull-down on the CC
line. Tested on plankton and zinger to make sure PD works as expected.
Change-Id: Ie7bde3e258f5cd23a0b82b626c0993a45b0df074
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200750
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
servo is already aware of the sensor hub.
Using samus_pd as an example, set the proper argument to flash
an image to the sensor hub.
BUG=chrome-os-partner:30801
BRANCH=None
TEST=None
Change-Id: I0c8465d1e34d515224675957c3e8482392585a56
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209232
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Increase RAM_SIZE for all stm32f07x chips to 16kB to use all of
on chip SRAM.
BUG=none
BRANCH=none
TEST=added 4000 byte array, verified in ec.RO.map that we are using
the new RAM space (bss size over 0x2000), loaded on samus and
verified that we could read and write to the 4000 byte array.
Change-Id: Ided3ce7c5fb353c9c37a01e6ed64f03786717e9b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209847
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Pulled down line so it's not so erratic.
Fixes the issue where the EC doesn't know what state the AP is in.
BUG=None
TEST=EC should report S0 correctly(not S3 all the time). `power on` and
`power off` will also work correctly(instead of doing absolutelly nothing).
BRANCH=None
Change-Id: I69bd17b39d2bd8f7f0456c4babc4ad9f8f34c8bd
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209668
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
Like Samus, the battery can be placed into a disconnect state. This CL
implements the necessary function to determine if it is so and kick it
out of this state when possible.
BUG=chrome-os-partner:30633
TEST=Put a battery in this state. Plug in AC. Verify the battery is
revived.
BRANCH=None
Change-Id: I074a72a2efe3844cbdfb0eda16a25fd8d1755a9b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209634
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Check for warm reboot before initializing ADC. Part of the initialization
process involves calibration of the ADC, which can only be done when the
ADC peripheral is disabled. This fixes a bug on samus_pd where jumping to
RW causes a watchdog because ADC reads hang.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=on samus_pd, without this change running sysjump rw causes us to jump
to RW and then causes a watchdog. With this change sysjump rw works. Also
verified that PD communication works in RW, which means ADC channels are
being read correctly after jumping to RW.
Change-Id: Iaa41da4795c3d15a6db56b0d715e36c29417d9b6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch is base on new hardware board, veyron has not some stuff,
such as power led, charge en
BUG=None
TEST=Read log with servo board, it has reponse when type some commends
BRANCH=None
Change-Id: I45502fd1278f69db5e46fc9ab1deaee02fc8708f
Signed-off-by: zyw <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/209231
Reviewed-by: Alexandru Stan <amstan@google.com>
Commit-Queue: Alexandru Stan <amstan@google.com>
Tested-by: Alexandru Stan <amstan@google.com>
The Samus battery can be placed into a disconnect state by asserting a
disconnect input signal. In this state, the battery will not function
until a charging current is applied. This patch adds detection of the
disconnect state. If a battery in disconnect state is found, a current
is force-applied to the battery to kick it out of disconnect.
BRANCH=None
TEST=Manual on Samus.
1. Put battery into disconnect state
2. Pull AC, then reattach AC
3. Verify "found battery in disconnect state" is seen on the
EC console.
4. Pull AC and verify that EC console is still accessable
Also verify that battery gets out of reset state:
1. Pull AC
2. Issue "i2cxfer w16 0 0x16 0x0 0x12" command on EC console
3. Re-attach AC
4. Pull AC and verify that EC console is still accessable
BUG=chrome-os-partner:29465
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4268887fb483094ac4e641749200268160d3014
Reviewed-on: https://chromium-review.googlesource.com/209013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
