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
When running certain ectool commands, our ioctl may succeed, yet our
command may not be successful for a variety of reasons (see ec_status
enum). In this case, we should return a non-success exit code so that we
can easily detect such failures in scripts.
BUG=chrome-os-partner:21171.
TEST=Pass FAFT suite on Peppy. Pass factory tests on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia33b8285fb048b256f0668b709573e86c15f1162
Reviewed-on: https://gerrit.chromium.org/gerrit/64686
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There are a few issues with console output:
1. The EC was returning more bytes than the message's insize. The
reason stems from a refacotring that the set the global
ec_max_insize variables to 'EC_PROTO2_MAX_PARAM_SIZE - 8'.
It really should be EC_PROTO2_MAX_PARAM_SIZE to cover the
maximum packet size returned from the EC.
2. A change was made to handle EAGAIN returning from the EC kernel
driver's ioctl() interface. That change prevented 0 bytes received
from being returned properly.
The first issue occurs because the EC console is always larger than
what the original ec_max_insize was set to. This caused no console
messages to be displayed. The second issue causes the console command
to potentially loop forever because the drain of the EC console is
never indicated because 0 could never be returned.
BUG=chrome-os-partner:21165
BRANCH=falco,peppy
TEST=Built and can now read 'ectool console' output as well
as not including gargabe.
Change-Id: I3114594f0020a5198532aa78ce126f4da6caf09a
Reviewed-on: https://gerrit.chromium.org/gerrit/63445
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
This made the /dev/cros_ec method fail when reporting the version.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=manual
ectool version
Used to fail; now it works again.
Change-Id: Ib5b7188f713981cffce36d065255d81b102d4bbe
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61133
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
LPC-based ECs provide a region of memory that is mapped into the AP's
address space, making it easy to read.
This CL uses an alternate EC host command to read that region, for those
systems that don't have mapped memory.
BUG=none
BRANCH=none
TEST=none
I tested this by building a special command into ectool.
Change-Id: If5cc52356f61522ae96e20d4c5d365accc299987
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59662
This came up when testing issue 242706. If you tell the EC to return
EC_RES_IN_PROGRESS, then the EC gets stuck and times out on the next
command.
I'm not entirely sure what the correct response should be, but I think that
the EC might not be doing the right thing either. In any event, this keeps
it from getting stuck.
BUG=none
BRANCH=none
TEST=manual
Try
ectool test 8 14
ectool test 0 14
The first command fails because we told it to, but the second command also
fails because the EC is expecting something else.
After this change, the second command works.
Change-Id: I513294396cff872018316c354d2c41953eb6fdf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59661
The maximum packet / param size differs depending on interface and
protocol version. Commands can now ask the comm interface what the
limits are, and can use preallocated buffers to avoid needless
malloc/free.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=the following all work on link
burn_my_ec
ectool version
ectool chargedump
ectool console
ectool i2cxfer 5 0x41 2
Change-Id: Ib847994da3f79721e7fb4e347231b9147a3f485f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60275
This lets us force the EC to return various error codes, so that we can be
sure we're seeing them.
BUG=chromium:242706
BRANCH=none
TEST=none
Trigger various errors like so:
ectool test 0 14
ectool test 1 14
ectool test 5 14
ectool test 8 14
ectool test 0 33
Change-Id: Ia951cd7afacdcce6c8ec7d35d3bfb5b113dea694
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59327
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is preparation for the common userspace EC interface. If/when that
appears, this will be ready.
BUG=chromium:239197
BRANCH=all
TEST=manual
Build, install, run it. Shouldn't be any change.
Change-Id: I9fa78515ec5443ba659f10a66bbaadcb7f4802b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56131
