First case is for legacy support
ectool pwmsetfanrpm <targetrpm> - set all fans to <targetrpm>
ectool pwmsetfanrpm <fan> <targetrpm> - set <fan> to <targetrpm>
BUG=chrome-os-partner:23803
TEST=Tested the above EC commands on Auron
BRANCH=none
CQ-DEPEND=CL:220960
Change-Id: I8f447f53289abaa9c5cc1285f9f0921328fbf32c
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The Zinger RW is now signed with 2048-bit RSA key (using SHA-256 as
digest).
This CL implements the verification mechanism.
note: the RSA key used for signing must be provided as a .pem file.
The path to .pem file must be provided in the PEM environment variable.
By default, it's using the dev key stored in zinger_dev_key.pem.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:28336
TEST=on Zinger, run with properly signed RW firmware and corrupted
firmware and check the serial traces.
Change-Id: Ia58482458904a3ed72d6b0e95996cae86a0ead83
Reviewed-on: https://chromium-review.googlesource.com/220178
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Minimuffin is identical to zinger, same MCU, same gpio, same
circuitry aroundt the MCU with two differences:
- Rated current is 2.25A instead of 3A
- USB PD hardware device ID needs to be different so that host
can differentiate between the two.
Due to the similarity between the two, minimuffin is defined
as a symlink to the zinger board.
BUG=none
BRANCH=samus
TEST=make BOARD=minimuffin
load onto a zinger and verify that samus reads device ID correctly
and limits input current limit to 2.25mA.
Change-Id: Ie39ec43262c7d14663eb68abff073bfeec451a24
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220689
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a command-line option to ask stm32mon to read the EC firmware image
to flash from the standard input when the filename is replaced by a "-".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:398165 chromium:396233
TEST=use the following flashing commands:
cat build/fruitpie/ec.bin | ./util/flash_ec --board=fruitpie --image=-
./util/flash_ec --board=fruitpie
./util/flash_ec --board=fruitpie --image=build/fruitpie/ec.RO.flat
and check the content of the flash.
Change-Id: I8039ecb6910f912161a7f59c5f5e2fc80447ce7b
Reviewed-on: https://chromium-review.googlesource.com/220842
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This removes the special casing around HALT. It saves us a string
literal and some logic. In total, we gain about 50 bytes and a
little cleanup for this.
BUG=None
BRANCH=ToT
TEST=Tried a program that uses HALT (i.e. red-green-blink) in
simulator and on hardware.
Change-Id: Iffee1b559983fd1ecd385cc6b8967f72a6b968a0
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220589
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=none
BRANCH=ToT
TEST=manual
make BOARD=samus
for i in extra/lightbar/programs/[g-z]*.bin; do
./build/samus/util/lbcc -d $i /tmp/x.lbs
./build/samus/util/lbcc /tmp/x.lbs /tmp/x.bin
cmp $i /tmp/x.bin
done
Change-Id: I86c014c425e917ecafadd1c6845fcf2e5b4edbb7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220244
This diff allows the user to send small programs to the EC and
gain control of the lightbar. Right now, this is only exposed
through ectool, and sysfs support will come later.
To send a program to the EC, use
$ ectool lightbar program /path/to/program.bin
and then start running the program with
$ ectool lightbar seq program
BUG=None
BRANCH=ToT
TEST=Using the above steps with hand-assembled programs.
Checked that infinite bytecode loops do not hang the EC.
Checked that bad opcodes exit with an error.
Stress tested pushing programs and changing sequences.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I635fb041a5dc5c403f7c26fb9a41b5563be9b6b7
Reviewed-on: https://chromium-review.googlesource.com/219558
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
During the communication init, ectool will probe max request and
response packet size from ec and set packet size accordind to that.
However, with older kernel's ec driver, the buffer allocated by
kernel is not large enough and this will cause kernel bug.
BUG=chrome-os-partner:31989
TEST=ectool version runs fine on blaze
BRANCH=ToT
Change-Id: I499a5305c8fa8b0fd6f3be8554c9cf066b7e0828
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219114
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Older versions of flash VDM supported a 'rw_hash' command that has
since been deprecated in favor of 'info' command. This CL makes
flash_pd.py try either in order to determine whether the pd flash
erase was successful.
BRANCH=none
BUG=chrome-os-partner:28330
TEST=manual, succesfully run on zinger with only 'info' command support
util/flash_pd.py -m 1 zinger_ec.RW.flat
2014-09-18 14:35:39,305 - root - INFO - Current PD FW version is zinger_v1.1.2192-5cd
2014-09-18 14:35:39,305 - root - INFO - Flashing 11532 bytes
2014-09-18 14:35:45,779 - root - INFO - Successfully erased flash.
2014-09-18 14:35:45,890 - root - INFO - Chunk 0 of 481 done.
...
2014-09-18 14:36:39,133 - root - INFO - Chunk 480 of 481 done.
2014-09-18 14:36:46,072 - root - INFO - Flashing DONE.
2014-09-18 14:36:46,072 - root - INFO - SHA-1: f6b296ba d474edc4 2e917ad0 33cd16cb 0f51a3fc
2014-09-18 14:36:46,090 - root - INFO - New PD FW version is zinger_v1.1.2226-bea
Change-Id: I32f8b06fa546aa99c8290b6b73faa9b8df05e4fb
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218878
Reviewed-by: Alec Berg <alecaberg@chromium.org>
CL provides some useful information similar to the EC console command
'pd state <port>' when host command 'usbpd <port>' is sent from host
with no additional arguments.
Also added a few build asserts for role & mux strings.
BRANCH=none
BUG=chrome-os-partner:31690
TEST=manual
ectool --interface=lpc --dev=1 usbpd 1
Port C1 is enabled. Role:SNK Polarity:CC1 State:6
# has zinger attached
ectool --interface=lpc --dev=1 usbpd 0
Port C0 is enabled. Role:SNK Polarity:CC1 State:2
Change-Id: Id44eb7bf6a6fcfa888a0008a2249601967c50bcc
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217138
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PD accessories that are RW update-able will broadcast their rw_hash
SHA1 digest upon connection to the PD MCU which will store it.
For update purposes, the host needs that accessories device id and
rw_hash to determine its proper firmware update payload.
This CL creates a host command that requests the type-C accessory info
attached to a particular port. It also implements an ectool command
to expose the host command.
BRANCH=none
BUG=chrome-os-partner:31361
TEST=manual,
# connect zinger to port 1 on samus
ectool --dev=1 --interface=lpc infopddev 1
Port:0 Device:1 Hash: 0x7f4d7a13 0xf07b65b9 0x41181e10 0xb99b3d5f 0x9dee1206
ectool --dev=1 --interface=lpc infopddev 0
Port:0 has no valid device
Also do the same on port 0 with similar results.
Change-Id: Id63c7edad77a43d43c14d8cd6bd96e08d0d9b501
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216814
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PD accessories that are RW update-able will broadcast their rw_hash
SHA1 digest upon connection and remain in RO briefly for a response.
In order to speed-up the response and decouple common case of
accessory is up-to-date, the PD MCU will keep a small 4 entry table of
PD accessory device ids and their corresponding RW hashes for quick
lookup.
The AP will be the source of new updates and their corresponding
device id's and RW hashes and therefore needs a method to update the
PD MCU table.
This CL creates the table, host command & ectool command to facilitate
future driver / daemon to update the RW hash entries.
BRANCH=none
BUG=chrome-os-partner:31361
TEST=manual,
# from AP
for i in `seq 1 8` ; do
ectool --dev=1 --interface=lpc rwhashpd $i $i $i $i $i $i
done
# from samus_pd console
pd rwhash
Device:5 Hash: 0x00000005 0x00000005 0x00000005 0x00000005 0x00000005
Device:6 Hash: 0x00000006 0x00000006 0x00000006 0x00000006 0x00000006
Device:7 Hash: 0x00000007 0x00000007 0x00000007 0x00000007 0x00000007
Device:8 Hash: 0x00000008 0x00000008 0x00000008 0x00000008 0x00000008
Change-Id: Ibe87b3594793cd5215eba42160489b26974aadbc
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214366
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add setting of new GPIO, prog_en, to flash_ec to be able to program
new plankton boards. This pin must be on for boot0 and nrst to be
connected from the FTDI to the MCU.
BUG=chrome-os-partner:31633
BRANCH=none
TEST=manual,
sudo servod -c plankton.xml
util/flash_ec --board=plankton
CQ-DEPEND=CL:216160
Change-Id: I29f882856e24147a7af283c5e82298c7736b8662
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216161
Reviewed-by: Todd Broch <tbroch@chromium.org>
Current ectool uses max outsize / insize from protocol v2
even if we have a v3 protocol ec. This makes some command
not working when actual size supported by ec is less than
max size from protocol v2.
This CL uses protoinfo command to read max size from ec
during the initialization process to correctly set max size
for ec with protocol v3+. For ec with protocol v2, protoinfo
command won't exist, hence ectool won't modify the max size
and used the size that we set when init the protocol.
BRANCH=none
BUG=chrome-os-partner:31660
TEST=Run 'ectool flashread 0 0x1000 /tmp/fr' in ryu
Change-Id: I226b6c2fb2f7e9be73032f2c5146d2710939b293
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214838
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a new host commmand for sending RW updates to PD devices.
The host command has a variety of sub-commands for performing the
update, including: erase RW, reboot, write new hash, write flash.
To program zinger RW, you should send host commands in this order:
write new hash to all 0's
reboot (zinger boots into RO since RW hash doesn't match)
erase RW
write flash
write new hash to match contents of RW
reboot
This also adds an ectool command to write a new RW. Just pass it
the RW .flat or .bin file.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=ectool --dev=1 --interface=lpc flashpd 0 0 zinger.RW.flat
Change-Id: Ia81615001b83ad7ee69b1af2bf1d7059177cde04
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213239
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The original version of the script worked but as the USB PD protocol
SM has been enhanced to handle more complicated scenarios the
occurrence of collisions on the baseband comm has grown and script
needs to account for that.
Script now checks status of ACK from zinger 'DONE 0' and retries two
additional times for commands that failed. If those three attempts
are unsuccessful script raises exception and quits.
Also added some more logging around retries and progress of chunk
writes.
BRANCH=none
BUG=chrome-os-partner:30135
TEST=manual, util/flash_pd.py build/zinger/ec.RW.flat succeeds in
programming zinger even in light of some retries.
Change-Id: Iaa8a22c2510ea5f4ebd92e1715be5fe062e13c61
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213131
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Passing the "--usb" argument will now utilized case-closed
debugging for flashing the EC. Currently this is only supported
for the samus LM4-based board.
BRANCH=none
BUG=none
TEST=verify that when the case-closed debugging flag is set, the
alternate openocd config file is used for samus, and an error is
thrown for all other boards
Change-Id: I0642bc2e9c2657cd8dbd83ee6e282365275d665a
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change the VDM implementation in the PD task to allow for VDMs
at any time when connected without disrupting any regular PD
communications.
BUG=none
BRANCH=none
TEST=load on a samus and on a zinger and test sending VDMs:
pd 0 flash version
pd 0 flash reboot
Also, test using the flash_pd.py script to write zinger RW using
VDMs.
Change-Id: I48352978d8c45f78e8a5a7735d65b013a853f3e2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210746
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This fixes the bug that SRC_ROOT is not set. This should be the last fix
for flash_ec. DEFAULT_BOARD is intentionally left as is. For developers
who don't want to use --board option every time, they need to set
DEFAULT_BOARD in their environment variables.
BUG=chromium:397202
TEST=util/flash_ec --board=link
BRANCH=None
Change-Id: If23f73adbd37f2a79cb5176e3665562e278f46db
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210523
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Add console commands to send the Vendor-Defined Messages used to flash a
USB-PD target.
Also add a simple test script to flash Zinger through its CC line. To
run the script, the board must have CONFIG_USB_PD_CUSTOM_VDM defined.
By default fruitpie has this config option enabled.
BRANCH=none
BUG=chrome-os-partner:28330
TEST=With a fruitpie connected to a zinger run
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW.
Change-Id: I06f8f545e28b93b2e646e668d81b594eb7976a2d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203375
Reviewed-by: Todd Broch <tbroch@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>
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>
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
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>
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>
This allows sending host commands to the PD chip through the EC.
The --interface option allows forcing a particular host interface.
This is necessary at present because the crosec device driver doesn't
support host protocol v3 so only has 8-bit command numbers.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=from EC console,
ectool version -> prints EC version
ectool --interface=lpc --dev=0 version -> prints EC version
ectool --interface=lpc --dev=1 version -> prints PD version
ectool --interface=lpc --dev=2 version -> prints error
ectool --interface=i2c version -> can't find EC
ectool --interface=dev version -> prints EC version
Change-Id: I9dd10578dac77e3e104d19e2f37759814eec6ca2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207948
This is needed for supporting device passthru. Right now, the --dev
option simply prints an error.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=manual
ectool -> prints an error
ectool help -> prints list of commands
ectool version -> prints EC version
ectool --dev=0 version -> prints EC version
ectool --dev=1 version -> prints error about bad device 1
ectool --dev=0 -> prints an error (because there's no command)
ectool --dev=0 foo -> prints 'unknown command foo'
Change-Id: I0f431a4789428cd6cc8ef48b396b38237935282a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207904
The 2 boards are similar enough to test stuff on big for now, at least
until the new hardware comes.
Also added veyron to flash_ec.
Also cleaned up the style: pre-upload.py was giving errors on files
that were unmodified from big(spaces instead of tabs).
I had to ignore this though:
> ERROR: Macros with complex values should be enclosed in parenthesis
> #471: FILE: board/veyron/board.h:35:
> +#define KB_OUT_PORT_LIST GPIO_A, GPIO_B, GPIO_C
BRANCH=none
BUG=chrome-os-partner:30167
TEST=~/trunk/src/platform/ec $ make BOARD=veyron clean &&
make -j BOARD=veyron && util/flash_ec --board=veyron --ro
verify ec is alive and version is reported as veyron
Change-Id: I1f4bd562c0ab55360a2160a753ad8ad9b58f8c47
Signed-off-by: Alexandru Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207270
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
ectool must support all prior versions of commands that shipped
EC binaries use.
BUG=chrome-os-partner:29830
BRANCH=None
TEST=Manual
With an EC that only supports version 0:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> error with explicit
message about at-shutdown not being supported
- Run 'ectool batterycutoff foo' -> error, bad parameter
With an EC that support version 0 or 1:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> success
- Run 'ectool batterycutoff foo' -> error, bad parameter
Change-Id: Ia88cfc5fa7c5125828ec0595f0b6a505916c97ea
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205155
Reviewed-by: Vic Yang <victoryang@chromium.org>
Twinkie only has test points for uart connection so nominally it will
need to be programmed via DFU mode over USB micro-B connection.
This CL changes from programming via flash_stm32 function and instead
adds dfu support.
BUG=chrome-os-partner:28337
TEST=util/flash_ec --board=twinkie successfully programs twinkie f/w
Change-Id: Ia5433b569579bb879bd405e98921450764510a73
Reviewed-on: https://chromium-review.googlesource.com/204749
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@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>
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>
CL manages various dut-control dependencies for readying the STM32
part for programming.
Additionally deprecated the short-lived --uart_prefix argument as
user's defining this could be problematic without knowledge of
necessary modifications to h/w & s/w.
Signed-off-by: Todd Broch <tbroch@chromium.org>
CQ-DEPEND=CL:200146
BRANCH=none
BUG=chrome-os-partner:28826
TEST=manual,
util/flash_ec --board=samus_pd succeeds.
util/flash_ec --board=spring succeeds.
Change-Id: I7627c77293da187700aeddf7382dbb12e163a2ef
Reviewed-on: https://chromium-review.googlesource.com/200148
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
