summaryrefslogtreecommitdiff
path: root/util/comm-dev.c
Commit message (Collapse)AuthorAgeFilesLines
* util: Add missing "meanings" from ec_status codesTom Hughes2019-09-091-1/+6
| | | | | | | | | | | | | | | The "meanings" array is used to translate the ec_status enums, but haven't been kept in sync. This results in valid ec_status return values showing up as "<unknown>". BRANCH=none BUG=none TEST=make buildall -j Change-Id: I82a8fe0e60716b11ca305a1a5bef2e26fec5b1aa Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1790567 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* ectool: use poll interfaceVincent Palatin2018-01-231-0/+20
| | | | | | | | | | | | | | | | | | | Test polling for MKBP events through the kernel cros_ec/pd/fp/.. driver node. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=b:69460856 TEST=run on Eve EVT: ectool --name=cros_fp fpmode fingerdown && \ ectool --name=cros_fp waitevent 5 10000 Change-Id: Ibdec137a3b646cf017a29afcf24ff5bbfb731198 Reviewed-on: https://chromium-review.googlesource.com/806167 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* ectool: use v2 ABI for fallback 'readmem' ioctlBrian Norris2016-05-241-3/+3
| | | | | | | | | | | | | | | | | | ec_readmem_dev_v2() was copy/pasted from ec_readmem_dev(), but we forgot to switch over the fallback 'fake_it' case to the new ioctl format. This case is used over transports like SPI, which don't implement cmd_readmem. BUG=none TEST=run `ectool version` on kevin (with cros-ec-spi) and don't see: ioctl -1, errno 25 (Inappropriate ioctl for device), EC result 255 (<unknown>) BRANCH=none Change-Id: I4335f8fc3d43169cf628e26cadf1ac8d263955f2 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/347111 Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org>
* ectool: Revert "ectool: Remove CROS_EC_DEV_IOCRDMEM"Gwendal Grignou2016-04-221-10/+58
| | | | | | | | | | | | | | | | | CROS_EC_DEV_IOCRDMEM must be used on architecture where legacy IO mapped registers are accessed inderectly via EMI. The kernel is taking care of the translation. TEST=Check on reks that we need to use the IOCTL. BUG=chrome-os-partner:52550,chromium:602832 BRANCH=none This reverts commit de45353bbdf0 ("ectool: Remove CROS_EC_DEV_IOCRDMEM"). Change-Id: I8efad56df90c58c25bdc9ccd70a508547e629a77 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/340348 Reviewed-by: Shawn N <shawnn@chromium.org>
* ectool: Remove CROS_EC_DEV_IOCRDMEMGwendal Grignou2016-04-151-58/+10
| | | | | | | | | | | | | | | | | On !LPC EC, we can read memory via CROS_EC_DEV_IOCXCMD ioctl, using command EC_CMD_READ_MEMMAP. On platform that supports direct memory access (lpc), we access the memory directly, bypassing the ioctl. BUG=chromium:602832 TEST=On gnawty and veyron, check 'ectool battery' works. Verify that gnawty use io mapped registers. BRANCH=none Change-Id: I9bfcddcf450bf8df63ead78e1df97dd7392289e6 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/338853 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* ectool: Upgrade to improved ioctl formatGuenter Roeck2016-04-121-3/+118
| | | | | | | | | | | | | | | Support both old and new ioctl formats at the same time. Auto-detect the ioctl format used by the kernel. BUG=chromium:481710 BRANCH=None TEST=Work on Samus with kernel 4.4 and 3.8/3.14/3.18 Change-Id: I31d7ce5b517b4b5af8e2b617e386c3cfd3276f20 Signed-off-by: Guenter Roeck <groeck@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/331830 Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* ec: fix duplicate 'const' warning for clang..Yunlian Jiang2015-04-181-1/+1
| | | | | | | | | | | | | | | It fixes duplicate 'const' warning. BUG=chromium:475960 TEST=the warning is gone. BRANCH=none Signed-off-by: yunlian@chromium.org Change-Id: I348fbefec4d681bb8b20c6b8cf84acec4561b391 Reviewed-on: https://chromium-review.googlesource.com/266109 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Yunlian Jiang <yunlian@chromium.org> Tested-by: Yunlian Jiang <yunlian@chromium.org>
* ectool: Revert: Do not increase buffer size after probe max size from ecGwendal Grignou2015-03-281-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Not needed with kernel fix: Commands are currenly limited to 252 bytes. Even if EC support protocol v3, ectool would only limit the command sizes, never go beyond 252 bytes. This reverts commit be0bd9b83538427cc350ad38d64b821dfcad82a0. It also remove a TODO. CQ-DEPEND=CL:262870 TEST=With proper kernel, and firmware supporting commands > 252 bytes, check that ectool console does not crash anymore. /usr/sbin/ectool --name cros_sh console returns more character than before. Check ectool version as well. /usr/sbin/ectool --name cros_sh version BUG=chromium:399057,chromium:454324,chrome-os-partner:31989,chrome-os-partner:23823 BRANCH=none Change-Id: I058ab0e6df96196a0fae186d1ffedcfa16e5dc3b Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/262885 Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
* samus: new algorithm for tmp006 object temperatureBill Richardson2014-10-221-5/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original algorithm is given in the TMP006 User's Guide (SBOU107.pdf). The algorithm we previously implemented is that, plus some additional and completely undocumented massaging of the Tdie and Vobj registers. The original meaning of that hack is now lost in the mists of time, thanks to our email retention policy. This CL introduces a new algorithm variant, but at least this time the details are in the bug report. It's essentially the same as the User's Guide algorithm, except that we apply one-stage FIR filters to the Tdie input and the Tobj output. There are five new parameters: d0, d1, ds, e0, e1. Refer to tmp006_read_object_temp_k() in ec/driver/temp_sensor/tmp006.c to see how these new parameters are applied. CAUTION: The tmp006 sensor algorithm is mostly math and magic numbers. The spreadsheet attached to the bug report has six sheets with wildly varying values for those parameters. Since the correct parameter values haven't yet been determined for Samus, all I can be sure of with this CL is that it seems to work and isn't any worse than the old one. Oh, and note that the EC's 't6cal' console command has been disabled until/unless we add support for floating point IO. Use ectool from the host to get and set the params instead. BUG=chrome-os-partner:32260 BRANCH=ToT,Samus TEST=manual After booting, look at the sensor values using ectool: localhost ~ # ectool temps all 0: 312 1: 314 2: 313 Sensor 3 not calibrated 4: 311 Sensor 5 not calibrated 6: 305 Sensor 7 not calibrated 8: 306 Sensor 9 not calibrated 10: 307 Sensor 11 not calibrated 12: 312 Sensor 13 not calibrated localhost ~ # localhost ~ # ectool tempsinfo all 0: 0 PECI 1: 1 ECInternal 2: 1 I2C-Charger-Die 3: 2 I2C-Charger-Object 4: 1 I2C-CPU-Die 5: 2 I2C-CPU-Object 6: 1 I2C-Left C-Die 7: 2 I2C-Left C-Object 8: 1 I2C-Right C-Die 9: 2 I2C-Right C-Object 10: 1 I2C-Right D-Die 11: 2 I2C-Right D-Object 12: 1 I2C-Left D-Die 13: 2 I2C-Left D-Object EC result 2 (ERROR) ... localhost ~ # There are six tmp006 object temps that need calibrating. The index used for the calibration is for the tmp006 objects, not the 3,5,7,.. numbers reported for all temp sensors. See the current values with tmp006cal: localhost ~ # /tmp/ectool tmp006cal 5 algorithm: 1 params: s0 0.000000e+00 a1 1.750000e-03 a2 -1.678000e-05 b0 -2.940000e-05 b1 -5.700000e-07 b2 4.630000e-09 c2 1.340000e+01 d0 2.000000e-01 d1 8.000000e-01 ds 1.480000e-04 e0 1.000000e-01 e1 9.000000e-01 localhost ~ # If the s0 param is zero, this sensor is uncalibrated. The params are entered in the order in which they're displayed You can change any or all of the parameters. Skip the ones you don't want to update by specifying '-' for its position. (Note: throw in an extra '--' first so that ectool doesn't think that negative numbers are command options). For example, to change s0 and b0: localhost ~ # ectool -- tmp006cal 5 1.0 - - -3.0 localhost ~ # localhost ~ # ectool tmp006cal 5 algorithm: 1 params: s0 1.000000e+00 a1 1.750000e-03 a2 -1.678000e-05 b0 -3.000000e+00 b1 -5.700000e-07 b2 4.630000e-09 c2 1.340000e+01 d0 2.000000e-01 d1 8.000000e-01 ds 1.480000e-04 e0 1.000000e-01 e1 9.000000e-01 localhost ~ # Now sensor 13 (tmp006 object index 5) is calibrated: localhost ~ # ectool temps all 0: 310 1: 315 2: 313 Sensor 3 not calibrated 4: 310 Sensor 5 not calibrated 6: 305 Sensor 7 not calibrated 8: 307 Sensor 9 not calibrated 10: 307 Sensor 11 not calibrated 12: 312 13: 313 Change-Id: I61b5da486f5e053a028c533ca9e00b9a82a91615 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224409 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* ectool: add new parameter to identify proper EC.Gwendal Grignou2014-09-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add parameter name to identify which EC to talk to. Superseed --dev parameter, removed soon. --name cros_ec (the default): send commands to /dev/cros_ec. --name cros_pd: send commands to /dev/cros_pd. ... BUG=chrome-os-partner:31513 TEST=Tested on samus: check ectool --name cros_pd version returns proper data: ectool --name=cros_pd version RO version: samus_pd_v1.1.2079-8e4f9fc-dirt .... CQ-DEPEND=CL:217297 BRANCH=ToT Change-Id: Ie8b5c6c184d73a89b4445e88d6f104169176b9f3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217311 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* samus: add options for device passthru and interfaceRandall Spangler2014-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* cleanup: Yes, even more TODO commentsRandall Spangler2013-11-041-5/+5
| | | | | | | | | | | | | Almost done. Comment changes only. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms Change-Id: I974dfc12aa264e2035b3bae35a089c19344e7d45 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175484 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* ectool: Return non-success exit code on bad EC status.Shawn Nematbakhsh2013-08-071-0/+1
| | | | | | | | | | | | | | | | 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>
* ectool: fix console commandAaron Durbin2013-07-261-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix uninitialized constant in util/comm-dev.cBill Richardson2013-07-091-1/+1
| | | | | | | | | | | | | | | | | | 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>
* Move protocol v2 constants to ec_commands.hRandall Spangler2013-07-031-1/+1
| | | | | | | | | | | | | | | | 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>
* Use EC_CMD_READ_MEMMAP on platforms without mapped memory.Bill Richardson2013-07-031-6/+21
| | | | | | | | | | | | | | | | | | 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
* Retry ectool commands that return EC_RES_IN_PROGRESSBill Richardson2013-07-031-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Comm interface now provides max I/O sizes and preallocated buffersRandall Spangler2013-07-011-0/+6
| | | | | | | | | | | | | | | | | | | | 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
* Add EC_CMD_TEST_PROTOCOL to fake certain responses.Bill Richardson2013-06-201-2/+9
| | | | | | | | | | | | | | | | | | | | | | 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>
* ectool prefers /dev/cros_ec, then falls back to i2c, lpcBill Richardson2013-06-051-0/+82
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
View Lorry Controller Status