When the target is running upgrade protocol version 2, it is capable
of processing multiple transfer attempts of the same block.
This patch allows timeouts when expecting the target acknowledges. If
the acknowledge does not arrive in time, the host reports the timeout
on the console and retransmits the same block to the target.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=it is now possible to successfully upgrade cr50 on Kevin in one go:
$ ./extra/usb_updater/usb_updater build/cr50/ec.bin
read 0x80000 bytes from build/cr50/ec.bin
open_device 18d1:5014
found interface 4 endpoint 5, chunk_len 64
READY
-------
erase
Target running protocol version 2
Updating at offset 0x00004000
sending 0x29620/0x3c000 bytes
Timeout!
Timeout!
Timeout!
Timeout!
-------
update complete
reboot
bye
Change-Id: Ib1c3179cb3a02c0ae6e5e949476553ae28b6a295
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341583
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The original version of usb_upgrade does not provide for any error
recovery and also does not support any protocol version notion.
Real life experience has shown that error recovery is essential, it
needs to be introduced as a protocol enhancement. We want to stay
backwards compatible though, so there is a need for protocol
versioning.
In the original version of the protocol target response is always the
same: a 4 byte number which is the error code (and zero means no
error). This patch modifies response to the very first packet from the
host, the startup packet. The startup response is 8 bytes long. The
first 4 bytes is still the same as before, the second 4 bytes carry
the protocol version supported by the target, an integer in network
byte order.
Thus, receiving a 4 byte reply to the startup message tells the host
that the target is running protocol version zero, 8 byte reply carries
the actual version number in the last 4 bytes.
The USB transfer function on the host is enhanced to accept responses
shorter then expected, when allowed.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=usb_updater can successfully update both old and new cr50 images,
properly reporting protocol version as 0 or 1 respectively.
Change-Id: I9920d2708b21f29615282161fc0eb027018f9378
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341617
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
It might not matter much, but it is a good practice to explicitly
release USB resources when terminating the app which used them.
Also, make function signatures around the file simpler by introducing
a structure to carry common USB endpoint properties: device handle,
endpoint number and chunk size.
BRANCH=none
BUG=chrome-os-partner:52856
TEST=no change in functionality, upgrades on B1 still work fine,
upgrades on Kevin still very unreliable
Change-Id: I9157774a2f5591c70701ba822f20db6ba02e7029
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341616
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The device-specific subclass used for Non-HC firmware updates is
in the spreadsheet now, so we can rename the macros to be
"official".
BUG=chrome-os-partner:49962
BRANCH=none
TEST=make buildall; test on cr50
make BOARD=cr50 (plus whatever signing magic works for you)
make -C extra/usb_updater
./extra/usb_updater/usb_updater build/cr50/ec.bin (sudo if needed)
Note that you may need to rebuild ec.bin in order to see any
difference after the update. If the A & B images are identical,
the RO bootloader always picks A.
Change-Id: I385ce89a9abe2059d52da2d82a0b92b9b3e3c93f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/339220
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds a standalone linux utility to deliver RW firmware
updates to the Cr50 over USB.
It prepares update blocks required by the firmware upgrader, and then
fragments and transfers the blocks though the USB channel. The blocks
are reassembled on the target and passed to the upgrade module for
integrity verification and programming.
BUG=chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50 as follows:
sudo extra/usb_updater/usb_updater build/cr50/ec.bin
The Cr50 doesn't yet accept firmware updates that way,
so there's no functionality to test just yet.
Change-Id: I1c698fd0c553c936d58ff16a2acaa05ae05bc857
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338088
* Update flash_ec to allow flashing servo_micro
* Add servo_micro build
BUG=chromium:571477
BRANCH=None
TEST=updated servod is able to control gpio, gpio extender,
SPI flash, ec uart, ap uart on test yoshi
Signed-off-by: Nick Sanders <nsanders@google.com>
Change-Id: I4d69c83ae581cb41da928a27c39b7152475d7ca8
Reviewed-on: https://chromium-review.googlesource.com/327214
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This just adds a .gitignore entry so that git doesn't complain
about the executable you may have built in the extra/usb_console/
directory.
BUG=none
BRANCH=none
TEST=make buildall
This has no effect on the EC code at all. The things in the
extra/ directory are optional and unsupported.
Change-Id: Ib4915f712f9d14caf7418ef4b03aa41e8764fd36
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310840
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The SPS RX FIFO handler prototype changed from passing cs_enabled
to cs_disabled, but the callback function for the spshc command didn't.
Now it does.
The spshc command switches the protocol on the SPI Slave bus to
expect EC Host Commands.
BUG=none
BRANCH=none
TEST=manual
At the EC console:
spstpm off
spshc
On the build machine, with an FTDI cable connected to the SPS
input:
cd extra/ftdi_hostcmd
make
./test_cmds
Change-Id: I69294a977b83854c5f6348904330bf74416cc6ec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293619
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds another test program to use with the EC connected to
the build host via an FTDI USB-to-SPI adapater, This program
sends an EC_CMD_HELLO host command to the EC. Options exist to
display the bytes transferred over the SPI interface, and to
truncate the message before its complete, to see how the EC reacts.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
To try out the new test program:
cd extra/sps_errs
make
./prog
./prog -v
./prog -v -c 22
Change-Id: I1d370ecdbae047d9504bc6e5f73949d4e3aed9d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284865
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This enables the feature that lets the Cr50 receive host commands
via the SPI (slave) interface.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
CQ-DEPEND=CL:283998
This CL also adds a test example in the extra/ftdi_hostcmd/
directory. To use it, you need the Cr50 attached to the build
host via an FTDI USB-to-SPI adapter.
cd extra/ftdi_hostcmd
make
./test_cmds
Change-Id: Ia719b1c898afc45b3105a9cd573a8492178d9be2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284001
This unifies all the EC header files to use __CROS_EC_FILENAME_H
as the include guard. Well, except for test/ util/ and extra/
which use __TEST_ __UTIL_ and __EXTRA_ prefixes respectively.
BUG=chromium:496895
BRANCH=none
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Iea71b3a08bdec94a11239de810a2b2e152b15029
Reviewed-on: https://chromium-review.googlesource.com/278121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just makes the LEDs blink continually, because I have a
development board sitting on my desk and I like to see it doing
something.
You can still force the GPIOs on and off using the tool in
extra/usb_gpio/.
BUG=none
BRANCH=none
TEST=make buildall
Try it:
sudo make BOARD=discovery-stm32f072 flash
The LEDs blink.
Force them on and off with:
cd extra/usb_gpio
make
./usb_gpio write -1 0
./usb_gpio write 0 -1
./usb_gpio write 2 0
./usb_gpio write 4 2
To resume blinking, use
./usb_gpio write 0 0
Change-Id: Iadbe7436c02de5b6eae81885d95bad154ca3692c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274131
Reviewed-by: Anton Staaf <robotboy@chromium.org>
This provides a very simple console interface for talking to the
discovery-stm32f072 board over its USB connection. It's a simpler
way to check that the board is working than configuring udev
and/or various drivers to recognize USB device 18d1:500f as a
serial console.
BUG=none
BRANCH=none
TEST=manual
Connect a discovery-stm32f072, then
cd extra/usb_console
make
./usb_console
Change-Id: Ib25baebe5b4f3a930cdc3a1367d6d20d05b70c56
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273570
Reviewed-by: Anton Staaf <robotboy@chromium.org>
ModemManager likes to play with serial ports it shouldn't
play with, mark our serial ports as off limits.
This also bumps the ordering of this rules file just past
the udev default rules because it uses environment variables
populated by that file.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=install new rules file, delete old rules file
verify that symlinks to TTY's are still created
verify that ModemManager leaves them alone now
Change-Id: I4ded95192d78b5b1bbc661ca5b762e18307d2d60
Reviewed-on: https://chromium-review.googlesource.com/269743
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This udev rule creates a directory in /dev/google for each
device attached. The name of the directory is unique to the
device and is prefixed with the device product name. Within
the directory there is a serial directory that contains
symlinks to each USB serial port exposed by the device. The
symlinks are named based on the USB interface name provided
by the EC. Additional subdirectories can be added for I2C,
JTAG, GPIOs, and SPI as needed.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=Verify that two different CCD devices generate uniquely named
entries.
Change-Id: I7e6f2ace29b7302c7c072bcf6aab7c8f060b993a
Reviewed-on: https://chromium-review.googlesource.com/260420
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This is a simple kernel module and Makefile for
building it out of tree. This module just uses
the existing kernel usb serial driver and probes
for the Google VID/Class/SubClass/Protocol that
identifies a valid simple serial interface.
This code should be rolled into the existing kernel
driver at: drivers/usb/serial/usb-serial-simple.c
While that happens, this module is still useful to
developers.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=cd extra/usb_serial; make; sudo insmod raiden.ko
Connect the discovery-stm32f072 over USB and see
that its console is discovered and works.
Change-Id: I83661b816643c43b3e2dc9fdc825bc3a796af2f4
Reviewed-on: https://chromium-review.googlesource.com/225923
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Makes a significant encoding change to existing opcodes and
adds several opcodes to allow for encoding the more complicated
patterns that we have on the lightbar (S0, etc.) as well as
condense the ones we technically could encode but couldn't
fit in the 192-byte footprint allotted to us (KONAMI).
We need this to remove sequences from the EC code.
BUG=chrome-os-partner:32203
BRANCH=ToT
TEST=run test programs on hardware and lightbar simulator
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I12fe908d3a43a924aa39f24ad66adbe53f7f38e1
Reviewed-on: https://chromium-review.googlesource.com/222949
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With only four LED segments, it's confusing to indicate a power
percentage by dimming the top segment unless you can see the
indicator smoothly ramping up from all-off. This does that.
Kind of pretty, if I say so myself.
BUG=chrome-os-partner:29041
BRANCH=ToT, Samus
TEST=make buildall
Run "ectool lightbar demo on", then press the T key to invoke the
pattern and the arrow keys to fake the charge state.
Change-Id: Ib6a56aea56078b8c1fc9edddda469d7f41735ff7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223300
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Wire up the discovery's four LEDs and one user
button as GPIOs that can be written and read using
the new USB GPIO driver. This also adds an extra
tool called usb_gpio that provides control of GPIOs
from the linux command line.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=cd board/discovery-stm32f072 ; make flash
cd extra/usb_gpio ; make
usb_gpio write 0x1e 0x00
Change-Id: I15115f82b15b6c35d1a34b83b7114a6bfa6a3d67
Reviewed-on: https://chromium-review.googlesource.com/218270
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
This prepends EC_ a macro exposed in ec_commands.h, moves a
macro into lbcc that is not used elsewhere, and changes lb_program
structs to lightbar_program.
BUG=None
BRANCH=ToT
TEST=make buildall -j
Change-Id: I481562da72d91f846c64cf9af40338027641462c
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222406
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Gets a little more coverage on the SET_COLOR control operand.
BUG=None
BRANCH=ToT
TEST=On hardware and simulator. Should appear exactly the same
as rainbow-shift.bin.
Change-Id: Id9c9948ae178884180e4d42e4fcceb58218423f8
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222004
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
PULSE and TEST sequences are not used anywhere. Remove them to save
flash space. Also, fix msleep(MSEC) calls in the unit test; it's
essentially usleep(SECOND) written in an incorrect way.
BUG=chrome-os-partner:32203
TEST=make buildall
BRANCH=None
Change-Id: I61ba897df632538eb89364a4c913d5fee87f3864
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220711
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
These programs test various bytecode interpreter functions.
rainbow-shift, red-green-blink and green-pulse produce visual
effects, whereas the other three programs test error cases.
bad-jump makes sure the interpreter stops if the PC goes
out of bounds. bad-opcode makes sure the interpreter stops if it
does not understand the instructions it is decoding.
infinite-jump makes sure that sticking a tight loop in the EC
(i.e., one not perforated with any DELAYs, RAMP_ONCEs, or CYCLE*s)
does not cause it to hang or crash. bad-decode-8 and -32 test that
malformed instructions are detected while decoding the
instruction's immediate data.
BUG=None
BRANCH=ToT
TEST=In simulator/scp files to device and test
Change-Id: I6c189997a13e7c6196daa28eb74d5506b5288f2b
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219565
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
This just brings the competely unsupported but occasionally useful lightbar
simulation tool up to date with the rest of the source tree so it will
compile and run again.
BUG=none
BRANCH=ToT
TEST=manual
cd extra
make
./lightbar
Change-Id: Iafeaaa5ac56a4b711c63d2c64d8c51ab4b324104
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213206
Reviewed-by: Randall Spangler <rspangler@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
