When usb_updater is invoked with the '-f' option and without
specifying the binary file to transmit, the cr50 still enters the data
transfer mode, even though the host is not transferring anything.
As a result cr50 stays in the 'rx_outside_block' state until timeout
expires. Another usb_updater invocation fails if attempted before
timeout expiration.
The UPGRADE_DONE PDU sent by the host causes the state machine to
switch to the idle state immediately.
BRANCH=none
BUG=none
TEST=ran the following commands:
usb_updater -f && usb_updater -f
the second invocation used to fail before this change, now it succeeds.
Change-Id: Iceafeb30de6011975fbf47dabc7c6c494177c0f7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415554
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces version 6 of the cr50 USB update protocol. This
version allows to multiplex TPM vendor and extension commands over the
same USB endpoint which is used for firmware updates.
When channeling TPM vendor commands the USB update frame looks as follows:
4 bytes 4 bytes 4 bytes 2 bytes variable size
+-----------+--------------+---------------+-----------+------~~~-------+
+ total size| block digest | EXT_CMD | Vend. sub.| data |
+-----------+--------------+---------------+-----------+------~~~-------+
Where 'Vend. sub' is the vendor subcommand, and data field is
subcommand dependent. The target tells between update PDUs and
encapsulated vendor subcommands by looking at the EXT_CMD value - it
is set to 0xbaccd00a and as such is guaranteed not to be a valid
update PDU destination address.
In the previous protocol versions target reset was requested by the
host sending a 4 byte PDU after the target receives the UPGRADE_DONE
message and moves the state machine to the 'awaiting_reset' state.
With the ability to transfer vendor commands, there is no need for the
target to have a special state for reset. The host can send the posted
or immediate reboot request using the appropriate vendor command.
As a result the 'awaiting_reset' state has been removed, the target
accepts vendor commands only when state machine is in the rx_idle
state.
Vendor command response size is not fixed, it is subcommand dependent.
In the current implementation the total size of the vendor command PDU
can not exceed 64 bytes, as there is no reassembly on the target side.
For backwards compatibility in case the target is running protocol
version earlier than 6, the 4 byte PDU is still sent to the target
after UPGRADE_DONE is sent.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=tested updates on Reef and Gru, observed that it is possible to
update earlier versions of firmware, and that it is possible to
request immediate and posted reset (depending on the presence of
the -u flag in the usb_updater invocation).
Change-Id: I6ea9e9f742c96b8ab0670e9cec87a83cd47bb20e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When usb update errors happen it helps a lot to be able to see the
actual error code returned by the target and where the error was
generated.
This patch adds a few printouts to help with debugging.
BRANCH=none
BUG=none
TEST=observed proper error messages generated while debugging
introduction of extension/vendor commands transfer over USB.
Change-Id: I06c77e7467f7f9547704c88c4b673866fb2e6032
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414947
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Until extension commands using incompatible TPM command code are
phased out, the function sending vendor/extension commands to the TPM
needs to be aware of the subcommand code and use the matching TPM
command code.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=with the rest of the patches applied both posted and immediate
reset commands operate on Gru as expected.
Change-Id: I8977df22e4c2fadfd3427c0b4f70035f7f532e00
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414946
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Let's make sure that both embedded and host side use the same command
definitions. To avoid host compilation problems move the definitions
into a separate file.
BRANCH=none
BUG=none
TEST=compilation still works.
Change-Id: Id0d85a51aebabed0637965b3b19d7ed42c46e75e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414945
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Just for consistency sake, make all normal messages generated by the
utility in the course of firmware update start with lower case letters
and all error messages start with upper case letters.
BRANCH=none
BUG=none
TEST=make buildall -j still succeeds
Change-Id: Ifb0bd8dec4c2bb5cbbb2c93b1918fc699c2f33dd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414944
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This is just a clean up patch, unifying all cases where endian
conversions are used in the usb updater source code.
BRANCH=none
BUG=none
TEST=usb update of cr50 is still possible on gru (which uses the code
being changed).
Change-Id: I362e9762493854b4fdbb9ec15c2cb363003f258a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414443
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
sweetberry takes a bit longer to erase flash and seems to be timing
out. This fix gets sweetberry to update reliably.
BUG=chromium:608039
TEST=update sweetberry firmware
BRANCH=None
Change-Id: I9a0cbeae3b7ce0e4b87840fe8bf24bb2e10777e9
Reviewed-on: https://chromium-review.googlesource.com/404710
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The new extension command is used to request device reset after a
successful update when communicating over SPI.
tpm_send_pkt() is being refactored to allow passing of different
extension commands.
BRANCH=none
BUG=chrome-os-partner:58226
TEST=verified that the system gets reset and the new image version
kicks in on both gru (over SPI) and reef (over USB).
Change-Id: I02f3ef76fc4b4ee1e52dedb9cb538e072638257a
Signed-off-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/395629
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The keyid field of struct SignedHeader is what distinguishes prod
keys from dev keys. This may be useful someday, so let's have the
update protocol return those values for the active RO and RW
images.
Bump the UPGRADE_PROTOCOL_VERSION accordingly.
Note: This doesn't enforce any keyid matches, it just returns the
current values as part of the initial upgrade handshake in case
we want to know.
BUG=chrome-os-partner:57956
BRANCH=none
TEST=make buildall; try on Gru
Make sure that Cr50 can be freely updated and downgraded between
firmwares that speak either v4 or v5 of the protocol, by using
the v5-aware usb_updater tool.
And of course, make sure that v5 images report their keyids. Duh.
Change-Id: If2cc0d4023dca2078b9398fd899618dc2cd409b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394732
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With the recent modification of the tpm reset processing the only way
to get the cr50 restart is to reset it internally.
Make sure that usb_updater triggers the cr50 reset in the end of the
update.
BRANCH=none
BUG=none
TEST=with the corresponding init script changes the update on reef
happens as expected.
Change-Id: Ib49b81c4ef6d12d0b877a8a63493cf4d6d5aaeb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394255
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The previously added '-b' command line option was left out from the
help message. This patch fixes it.
BRANCH=none
BUG=none
TEST=verified that -b command line option description is included in
the help message.
Change-Id: I71117a8653ae5094fd0bf3909c8715d6ec25259d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394254
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Port USB firmware update to stm32f4 dwc usb from st usb.
This includes usb dwc usb stream inplementation, generic
endpoint interfaces, and the sweetberry test case.
BUG=chromium:608039
TEST=usb update works
BRANCH=None
Change-Id: Ia26e4f7e990ee64991468799c99b036f5f32190f
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It is sometimes necessary to find out headers' version of a cr50
binary blob. This patch adds this ability.
BRANCH=none
BUG=none
TEST=build the new tool image and try it:
$ ./extra/usb_updater/usb_updater -b /build/kevin-tpm2/opt/google/cr50/firmware/cr50.bin
read 524288(0x80000) bytes from /build/kevin-tpm2/opt/google/cr50/firmware/cr50.bin
RO_A:0.0.8 RW_A:0.0.4 RO_B:0.0.8 RW_B:0.0.4
$
Change-Id: I367ca94346484410f785fb56a941c8558ab57634
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374085
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trying to use usb_updater in the upstart script made its shortcomings
very obvious: it is difficult to tell if the cr50 needs to have both
RO and RW updated, and if so - if it is even capable of updating RW.
Also, it is not clear that the target should erase its backup sections
as soon as it receives the transfer originating PDU. It is not known
in advance if the host has a newer RW section, of if the host is even
going to transfer the RO section.
These issues are addressed by version 4 of the image transfer
protocol.
The target now reports versions of its currently active RO and RW
sections back to the host. The host compares versions running on the
target with the versions retrieved from the image prepared for the
update and decides which sections, if any, need to be transferred.
The host also takes into account protocol version currently running by
the target's RW: versions below 3 do not allow RO updates.
In the development environment USB transfer ends with the target
reset. This is not desirable when the update is happening on a
Chromebook running production code. Also, in the development
environment there could exist multiple versions of the image with the
same signer header version fields, with only difference in the
timestamp. We want to be able to update using these images in
development environment, but in production we want to rely to the
header version fields.
These two mode (dev versus production) are now controlled by the
-u/--upstart command line flag.
The updater now can return four different exit values:
- 0 means that the update was not required, the device is already
running the current code.
- 1 means update was completed, the target must be reset for the
update to kick in.
- 2 means that the RW transfer was completed, but the RO transfer
could bot be attempted, because the target is running an early
protocol version and is not capable of the RO updates.
This exit value is the indicator that the utility needs to be run
again after target restated, so that the new RW version can accept
an RO update.
- 3 means the update failed due to some internal error.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=updates of targets running earlier protocol version still work
fine.
Change-Id: Ia56f63072eaf88dcdefebf621b7341535748c7d7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374759
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The code should be compiled with -O0 for gdb use, otherwise various
optimizations make it very difficult to follow the execution flow.
With this patch adding DEBUG=1 to the environment or make command line
causes the usb_updater utility built with -O0 instead of -O3. The
debug flag is being changed to -g from -g3 as this code is not going
to be able to benefit from the g3 features, especially when built
inside chroot.
BRANCH=none
BUG=none
TEST=verified that gdb can properly control execution when make is
invoked with DEBUG=1
Change-Id: I50d8df46a7dd04d4d253b34146dde95f5388287d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374758
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces support for the cr50 firmware update protocol
version 3. It is described in more details in the comment in the
patch, the bottom line is that both RO and RW updates are supported,
and SPI and USB modes use the same protocol now.
The notions of PDU (protocol data unit) passed between the host and
the programming function on the CR50 is introduced, and USB mode
framing is described.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that version 1 and 2 updates still work. Version 3 mode
was tested later, when the device side patches were applied.
Change-Id: If51854b6a0b140730e85853bc42039233550fe8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371509
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In preparation to cr50 update protocol enhancements allowing to update
both RO and RW sections this patch is changing the name of the
structure containing communications endpoint information.
In the upcoming patches more fields are going to be added to this
structure, it is cleaner to change its name and existing use before
adding new features.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=make -C extra/usb_updater
Change-Id: I5ca0b6da75067a4f01ea80b6a6ca49a50e1136ab
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371508
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This just adds the new command line option and a help message for it.
This option will be used to signal that the RO section update is
required along with the RW section update when invoking usb_updater.
The flag indicating presence of the option will be saved in the
endpoint structure so it is available at different layers of the code.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=built usb_updater and invoked it with --help option, observed the
new option showing up in the output.
Change-Id: Ief35a553651d29ca39c42c5af7294d3aba223b02
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/369160
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In preparation of introducing new update protocol version this patch
cleans up the existing implementation.
The receive and transmit PDU headers are separated into their own
structures and are now shared between the server and client sides.
Some comments have been added to better explain different protocol
versions' details.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that it is still possible to update RW_A and RW_B on a
Kevin CR50, works using both USB and SPI.
Change-Id: Ied65b2c2a7800bae045f1d2dd64e58dd5e793d27
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368989
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In preparation to RW and RO cr50 updates, separate the code
transferring an image section (an RW section currently) into a
function.
This will allow to add RO transfer by invoking the same function with
different address and size parameters.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that it is still possible to update to RW_A and RW_B
both over USB and SPI.
Change-Id: Ia41317e0eefe114bac41e73c7e715b1a5cb6549c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368988
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This is a mostly cosmetic change, use size_t as the type for variables
which are used to pass around number of bytes received or transmitted.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that usb_updater still works both over USB and SPI.
Change-Id: I2cc726315d613ee42937fb494745cf7e0ea66622
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368987
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Print the reply bytes, be more consistent between %d and %x.
BUG=none
BRANCH=none
TEST=manual
Build debug version, verify that it prints more stuff.
Change-Id: I8c8a983360f4895ccc72b73ed67ce2d45a461bad
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365120
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This script is more flexible for updating multiple targets,
including servo_v4, servo_micro, and sweetberry.
The command takes a json config file that specifies
flash layout, USB ID, and size.
BUG=chromium:571476
TEST=./fw_update.py -b servo_v4.json -f ec.bin; both RW, RO
BRANCH=none
Change-Id: Ic9dcee2c23484bb28c8bfaf1882c578314534116
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361835
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
A new option is being added to the set of command line options, '-s',
once it is specified, the utility tries to update the CR50 using
/dev/tpm0.
BRANCH=none
BUG=chrome-os-partner:54992
TEST=emerge-gru ec-utils, copy /build/kevin/usr/sbin/usb_updater and
~/trunk/src/platform/ec/build/cr50/ec.bin to the DUT, try running
the update command on the DUT:
$ <path to>/usb_updater -s <path to>/ec.bin
observe in the end of the log:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
-------
update complete
bye
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
restart the cr50 and verify that it is running the new image.
Change-Id: Idb755328f911f3065f01df420488c7a1b4a32500
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358967
Reviewed-by: Andrey Pronin <apronin@chromium.org>
It is necessary to be able to build usb_updater for both host and
board environments.
When building for board environments the appropriate compiler and
binutils are defined in the environment. Allow the environment
definitions to take precedence over local definitions.
BUG=none
TEST=inside and outside chroot:
. ran 'make clean; make; verified that command can be run on the
host.
inside chroot:
. ran 'emerge-kevin ec-utils' and verified using the 'file' utility
that the executable in /build/kevin/usr/sbin/usb_updater is built
for arm
Change-Id: If2ac4a4e7f7ece188eba5ff917a510363c6d1990
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353165
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The README points the reader back to the docs directory where the
CCD documentation lives. I've added information about the install
script, and about how the raiden module identifies a CCD serial
console.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I8714dffcad0b8c30f46529a8f2d670b5d432cda6
Reviewed-on: https://chromium-review.googlesource.com/352787
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This rule makes it easier to use CCD devices when the raiden module
can't be installed for some reason. The rule informs the usbserial
module that it should handle anything that looks like a simple serial
port for any CCD compatible USB devices.
The install script now detects failure when building and installing
the raiden module and offers the --fallback option in that case.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I617bbdfb4c5cb9e9803f4088c651f84e3f72bd28
Reviewed-on: https://chromium-review.googlesource.com/351873
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The install script builds and installs the raiden module, it also copies
the udev rules file into /etc/udev/rules.d and updates the module alias
and dependency information.
The install script will also retrigger udev to process rules for all
devices that have the Google Vendor ID (0x18d1). This ensures that
any devices that are connected when the install is run will immediately
be available for use (as opposed to requiring that these devices be
unplugged and replugged before use).
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=Remove udev rules file
Remove raiden.ko module, aliases, and dependency information
Reboot workstation
Run ./install
Plug in CCD capable device
ls /dev/google
Change-Id: I7bcb02f05ee84738a6259800afc4d0c69bea9e69
Reviewed-on: https://chromium-review.googlesource.com/347092
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It is not trivial to direct output of this make file into a different
directory, let's just add the byproducts to a local .gitignore.
BRANCH=none
BUG=none
TEST='git status' after running make does not show any junk any more.
Change-Id: Id04822102d788c6883cff36f26fd8f9d50c996aa
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346746
Reviewed-by: Anton Staaf <robotboy@chromium.org>
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>
