summaryrefslogtreecommitdiff
path: root/util
Commit message (Collapse)AuthorAgeFilesLines
* Remove bolt, daisy, kirby, puppy, slippy boardsRandall Spangler2013-11-211-2/+2
| | | | | | | | | | | | | | | | | | These boards are unloved and unsupported. They'll never grow up to be laptops, and hardware is increasingly hard to come by. Comparable functionality is available in the other, more-loved boards. Removing these boards speeds up util/make_all.sh by 40%. (If you're not running that before every upload, you should be...) BUG=chrome-os-partner:24062 BRANCH=none TEST=build all remaining platforms and pass unit tests Change-Id: I4d8a49e4d52d7393471f1b1cbef059c8db4a4f77 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177373
* util: declare all host utils source dependencies in build.mkVincent Palatin2013-11-142-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of hardcoding the common files for host utils in the generic rules, let's declare them in the build.mk file using the same system as the Linux kernel build. if a binary "foo" declared in "host-util-bin" or "build-util-bin" has a matching "foo-objs" variable, it will be build from all objects declared in "foo-objs" else it uses directly "foo.o" (single source file). This is preparatory to add new "build" tools sharing common sources. note: the dependencies on the utils are a bit less fine-grained as a result of this change, but given the low number of tools, that should be acceptable. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=./util/make_all.sh Change-Id: Ieffce7ca6f5b685ffb7d1f4626b99aff07b61443 Reviewed-on: https://chromium-review.googlesource.com/176174 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Add boardversion command to ectoolChromeOS Developer2013-11-131-0/+17
| | | | | | | | | | | BRANCH=none BUG=chromium:318342 TEST=Run "ectool boardversion" on device with and without support for board ID. Note, boards without support will return an error. Signed-off-by: Dave Parker <dparker@chromium.org> Change-Id: Ib7599570c84a7ed5cf70ce9d8336467785b35569 Reviewed-on: https://chromium-review.googlesource.com/176543
* ite: Added functionality to ITE In-system programming tool.Alec Berg2013-11-081-84/+255
| | | | | | | | | | | | | | Added ability to erase and program flash to iteflash. BRANCH=none BUG=chrome-os-partner:23576 TEST=generate random 192kB file, write it to the ITE chip, read flash back and make sure file read in matches file written. Change-Id: Id525b43e523a3d710ee65b623fec07800cf7f347 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/176022 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* ite: Add IT8380 In-system Programming toolVincent Palatin2013-11-072-1/+774
| | | | | | | | | | | | | | | | | | | | use the IT8380 SMB0 interface connected to the Servo FTDI chip to access the internal flash. The write-protect is not implemented. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Alec Berg <alecaberg@chromium.org> BRANCH=none BUG=chrome-os-partner:23576 TEST=check waveforms on the Logic analyzer. Change-Id: Ic3402e4e8def731fe4f2fe93be254f5fd0982abf Reviewed-on: https://chromium-review.googlesource.com/175677 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: Yes, even more TODO commentsRandall Spangler2013-11-045-20/+33
| | | | | | | | | | | | | 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>
* Remove QEMU testsstabilize-4886.BVic Yang2013-10-292-265/+0
| | | | | | | | | | | | | | | | | | | | | | QEMU tests served us well, but it has been more and more difficult to maintain as we now have more chips and use more functionality from each EC chip. With emulator tests in place to test common code and hardware test to test per-chip/per-board drivers, it's time to remove QEMU tests to simplify our code base. QEMU tests that are covered by other emulator tests are removed completely; tests that are not covered are left alone for now to preserve the test logic. BUG=chrome-os-partner:18343 TEST=util/make_all.sh BRANCH=None Change-Id: I5a4dd2f5ac42f7f66f86fdce0b62dbd2c65bf66a Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174669 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: comments in i2c modulesRandall Spangler2013-10-251-2/+4
| | | | | | | | | | | | | No code changes; just update comments with bug links BUG=none BRANCH=none TEST=build all platforms Change-Id: I8b845f9c43315b7db5a746a16c6618c3ee96979d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174614 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lpc: No need to scan entire host command I/O space for detectionRandall Spangler2013-10-231-13/+6
| | | | | | | | | | | | | | | | The EC LPC implementation guarantees that the status byte will have at least one zero bit, so there's no need to scan the parameter space as well. Removing this unneeded check will slightly speed up ectool. BUG=chrome-os-partner:10963 BRANCH=none TEST=on an x86 chromebook (e.g. link), ectool hello still works iotools io_read8 0x200 && iotools io_read8 0x204 -> not both 0xff Change-Id: Ic02ca0ee686ab10e50093807717ec638aaa468c6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174059 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* ec: add nyan boardYen Lin2013-10-171-1/+1
| | | | | | | | | | | | | | | | | | | This is to add nyan board support: - new files in board/nyan folder, including battery.c - new common/chipset_tegra.c, which is mostly based on chipset_gaia.c - new include/tegra_power.h - modified build.mk and flash_ec for nyan BUG=none BRANCH=nyan TEST=tested on Venice 2 board Change-Id: I36895f34f2f4d144a9440aff358c8274797ebbd6 Signed-off-by: Yen Lin <yelin@nvidia.com> Reviewed-on: https://chromium-review.googlesource.com/168078 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Create samus board configBill Richardson2013-09-301-1/+1
| | | | | | | | | | | | | | | | | | | This just does a copy/rename from Bolt. Tweaking for Samus' peculiarities will come next. BUG=chrome-os-partner:22870 BRANCH=none TEST=manual The only thing we can check is that it compiles: cd src/platform/ec make BOARD=samus Change-Id: Ied95ebdd1137548b21334b4a65a298c68482c517 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171081 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Tool support for STM32L-Discovery boardJeremy Thorpe2013-09-282-2/+3
| | | | | | | | | | | | | | | Add the ChipID for the stm32l152c board to stm32mon. Add discovery to the list of supported boards in flash_ec. BUG=None TEST=With modified servo connector, see that image can be loaded onto stm32l152c discovery board. BRANCH=none Change-Id: Ie16c64d17c907f7de765b09de98f534c486ae04c Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170981 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* rambi: Initial EC firmwareChromeOS Developer2013-09-251-4/+4
| | | | | | | | | | | | | | | | This should have all the correct GPIO mappings. Chipset and charger tasks are currently disabled, until we bring up the voltage rails and I2C communication. BUG=chrome-os-partner:22895 BRANCH=none TEST=compiles; everything else needs to wait until we get hardware Change-Id: Iea49fe7ab8bd17f61c8cc6c71f236a503418ee28 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170540 Reviewed-by: Vic Yang <victoryang@chromium.org>
* ec: fix duplicate 'const' declarartion.Yunlian Jiang2013-09-171-1/+1
| | | | | | | | | | | | | | | BRANCH=None BUG=chromium:292965 TEST=CC="i686-pc-linux-gnu-clang" CXX="i686-pc-linux-gnu-clang++" emerge-x86-generic chromeos-ec passes. Signed-off-by: yunlian@chromium.org Change-Id: I936f5e9b3e6ab5a5c1c2f6b6c41d054d748545e3 Reviewed-on: https://chromium-review.googlesource.com/169633 Reviewed-by: Luis Lozano <llozano@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yunlian Jiang <yunlian@chromium.org> Tested-by: Yunlian Jiang <yunlian@chromium.org>
* Change get-set host command to be less genericBill Richardson2013-09-121-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having a per-device enum list for use by the EC_CMD_GET_SET_VALUE command won't work when the one-and-only ectool tries to talk to different devices. Any particular enum may be missing or have a completely different meaning. Instead, we can do the same thing that EC_CMD_HOST_EVENT_* does - use the same structs for a bunch of different commands. If/when we run out of command numbers (it's currently only 8 bits), we'll just switch to using EC protocol v3 (see crosbug.com/p/20820), which provides 16 bits for the command. This CL renames EC_CMD_GET_SET_VALUE to EC_CMD_GSV_PAUSE_IN_S5 (since that's the one-and-only use of it at present), and renames the params/response structs as well. Since only the names are changing, the implementation remains backwards-compatible (assuming the flags value usage is preserved by ectool for the EC_CMD_GSV_PAUSE_IN_S5 command, which it is). If I can cherry-pick this change into the one place where it's being used, I will. BUG=chromium:287969 BRANCH=ToT TEST=manual Although this is primarily an internal name change, it also means that the commands to invoke the previous usage of this feature have changed. To test: On Haswell systems only. To enable the pause in S5 at shutdown, do either of these: EC console: pause_in_s5 on root shell: ectool pause_in_s5 on Shut the AP down politely, and it should pause in S5 for 10 seconds before continuing to G3. You can see this by watching the EC console. To disable the pause in S5 at shutdown, do any of these: EC console: pause_in_s5 off root shell: ectool pause_in_s5 off or press Refresh + POWER Boot the system, then politely shut down. This time it should go directly to G3 without pausing in S5. Change-Id: Ic614fed37ad89db794c2bbcca2b83d1603030ab2 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168816
* Add command for Haswell to pause in s5 at shutdownBill Richardson2013-09-061-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At normal AP shutdown, Haswell systems skip S5 entirely and go directly to G3. It's sometimes handy to pause in S5 as the other systems do, for things like power-cycle tests that use the RTC to do a delayed wake from S5. This CL adds a console command and a host command to enable/disable that pause in S5. The default is to skip S5, and the override value is not persistent across EC reboots, so whenever the EC hibernates or reboots (Refresh + Power, software sync), you'll have to re-enable it again. BUG=chrome-os-partner:22346 BRANCH=falco,ToT TEST=manual On Haswell systems only. To enable the pause in S5 at shutdown, do either of these: EC console: gsv s5 1 root shell: ectool pause_in_s5 on Shut the AP down politely, and it should pause in S5 for 10 seconds before continuing to G3. You can see this by watching the EC console. To disable the pause in S5 at shutdown, do any of these: EC console: gsv s5 0 root shell: ectool pause_in_s5 off or press Refresh + POWER Boot the system, then politely shut down. This time it should go directly to G3 without pausing in S5. Change-Id: I324e6e2373bc20b61a731b4ef443d7bb8edb6b83 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168086 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Allow parallel unit testing in make_all.shVic Yang2013-09-051-1/+1
| | | | | | | | | | | | | | | We are already applying arguments of make_all.sh to building ec binary for each board. Let's also apply them to 'make runtests'. BUG=None TEST=util/make_all.sh -j8 BRANCH=None Change-Id: I267aee662c015e65b737640815dbbb0cb72c58ba Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167826 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add LIGHTBAR_CMD_VERSION command to detect lightbar features.stabilize-4636.BBill Richardson2013-08-302-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most systems don't have a lightbar. Those that do need a way to detect that one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command to the EC and checking the result. If the response is EC_RES_INVALID_COMMAND, there isn't a lightbar. But what .cmd value should we use in struct ec_params_lightbar? Future lightbar implementations (if any), could remove existing functions or add new ones, so there isn't a safe choice. This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new implementation exists. Future systems should return some useful information in response to this command. Existing systems will return EC_RES_INVALID_PARAM, which is enough to distinguish them. BUG=chromium:239205 BRANCH=none TEST=manual make BOARD=link make BOARD=link runtests There are no user-visible changes in functionality to anything. Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167549 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* bolt: add board support to flash_ecAaron Durbin2013-08-231-1/+1
| | | | | | | | | | | | | | | The flash_ec utility was not honoring --board=bolt. Therefore, add it to the known variants of flash_slippy. BUG=chrome-os-partner:20372 BRANCH=None TEST=flash_ec --board=bolt dosen't fail Change-Id: I8f9c1ddcf7d40b8b579cd90af7dd5c4d90537084 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66820 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Completely new thermal/fan implementationBill Richardson2013-08-231-6/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problems with existing thermal control loop: * Not multi-board friendly. thermal.c only supports Link and needs refactoring. Temp thresholds and fan speeds are hard-coded. * Only the PECI temp is used to determine the fan speed. Other temp sensors are ignored. * Has confusing data structures. Values in the CPU temp thresholds array mix ACPI thresholds with fan step values. With this change, the thermal task monitors all temp sensors in order to perform two completely independent functions: Function one: Determine if the host needs to be throttled by or informed of any thermal events. For thermal events, each temp sensor will have three threshold levels. TEMP_HOST_WARN * When any sensor goes above this level, host_throttle_cpu(1) will be called to ask the CPU to slow itself down. * When all sensors drop below this level, host_throttle_cpu(0) will be called. * Exactly AT this level, nothing happens (this provides hysteresis). TEMP_HOST_HIGH * When any sensor goes above this level, chipset_throttle_cpu(1) will be called to slow the CPU down whether it wants to or not. * When all sensors drop below this level, chipset_throttle_cpu(0) will be called. * Exactly AT this level, nothing happens (this provides hysteresis). TEMP_HOST_SHUTDOWN * When any sensor is above this level, chipset_force_shutdown() will be called to halt the CPU. * Nothing turns the CPU back on again - the user just has to wait for things to cool off. Pressing the power button too soon will just trigger shutdown again as soon as the EC can read the host temp. Function two: Determine the amount of fan cooling needed For fan cooling, each temp sensor will have two levels. TEMP_FAN_OFF * At or below this temperature, no active cooling is needed. TEMP_FAN_MAX * At or above this temperature, active cooling should be running at maximum. The highest level of all temp sensors will be used to request the amount of active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to convert the amount of cooling to the target fan RPM. The default pwm_fan_percent_to_rpm() function converts smoothly between the configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages between 1 and 100. 0% means "off". The default function probably provide the smoothest and quietest behavior, but individual boards can provide their own pwm_fan_percent_to_rpm() to implement whatever curves, hysteresis, feedback, or other hackery they wish. BUG=chrome-os-partner:20805 BRANCH=none TEST=manual Compile-time test with make BOARD=falco runtests On the EC console, the existing fan commands should work correctly: faninfo - display the fan state fanduty NUM - force the fan PWM to the specified percentage (0-100) fanset RPM - force the fan to the specified RPM fanset NUM% - force the fan to the specified percentage (0-100) between its configured minimum and maximum speeds from board.h (CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX) fanauto - let the EC control the fan automatically You can test the default pwm_fan_percent_to_rpm() with fanset 1% faninfo The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it automatically again with fanauto Also on the EC console, the thermal settings can be examined or changed: > temps PECI : 327 K = 54 C ECInternal : 320 K = 47 C G781Internal : 319 K = 46 C G781External : 318 K = 45 C > > thermalget sensor warn high shutdown fan_off fan_max name 0 373 387 383 333 363 PECI 1 0 0 0 0 0 ECInternal 2 0 0 0 0 0 G781Internal 3 0 0 0 0 0 G781External > > help thermalset Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]] set thermal parameters (-1 to skip) > > thermalset 2 -1 -1 999 sensor warn high shutdown fan_off fan_max name 0 373 387 383 333 363 PECI 1 0 0 0 0 0 ECInternal 2 0 0 999 0 0 G781Internal 3 0 0 0 0 0 G781External > From the host, ectool can be used to get and set these parameters with nearly identical commands: ectool thermalget ectool thermalset 2 -1 -1 999 Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66688 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* kirby: Add kirby support to util/flash_ec.Jeremy Thorpe2013-08-211-1/+1
| | | | | | | | | | | | | This allows stm32mon built in kirby build directory to be used to flash EC. BUG=chrome-os-partner:21964 TEST=util/flash_ec --board=kirby --image=build/kirby/ec.bin BRANCH=None Change-Id: I38ab6de0e129996010974c8766e1f84f4e8eb3a7 Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66005 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Remove board 'wolf' from master/ToT branch.stabilize-falco-4537.91.Bstabilize-4537.147.Bstabilize-4537.118.Brelease-R30-4537.BDave Parker2013-08-121-1/+1
| | | | | | | | | | | | | | Firmware development for this board is happening on the firmware-wolf-4389.24.B branch. BUG=chrome-os-partner:21815 BRANCH=None TEST=Run util/make_all.sh. Verify all is made. Change-Id: I4b58a982a87562231453f3f201024b809c6a24fb Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65514 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* ectool: Return non-success exit code on bad EC status.Shawn Nematbakhsh2013-08-072-0/+4
| | | | | | | | | | | | | | | | 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>
* Peppy ectool led commandDave Parker2013-08-071-11/+36
| | | | | | | | | | | | | | | | | | | | | Glue between the existing ectool led command and the led control logic. BUG=chrome-os-partner:20776 BRANCH=peppy TEST=Manual. Run "ectool led" commands: Should pass: ectool led power blue|yellow|off|auto|blue=1 yellow=1 ectool led battery blue|yellow|off|auto|blue=1 yellow=1 Should fail: ectool led adapter <color> ectool led power|battery red|green|white Signed-off-by: Dave Parker <dparker@chromium.org> Change-Id: I2540940baa553866760dd9ae62278b6b845793ef Reviewed-on: https://gerrit.chromium.org/gerrit/64627
* Pass command line arguments to make from make_all.shVic Yang2013-08-011-1/+1
| | | | | | | | | | | | | | | | This would allow us to do something like: util/make_all.sh -j32 util/make_all.sh V=1 BUG=None TEST=util/make_all.sh -j TEST=util/make_all.sh V=1 BRANCH=None Change-Id: Ifed0baf6c94fbe8b0296cbdc70ba84f92f04b75b Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64268 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>
* Reboot emulator with execv()Vic Yang2013-07-241-11/+2
| | | | | | | | | | | | | | | | With this, the emulator is able to reboot itself without the help of run_host_test script. This makes it easier for development and also speeds up the test. BUG=chrome-os-partner:19235 TEST=Pass all tests BRANCH=None Change-Id: Ifa510442de19256c671ab91b6bc75fe9e8b9dc7b Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62969 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Add a script to build all platforms and run host-based unit testsRandall Spangler2013-07-241-0/+17
| | | | | | | | | | | | | | | | As the number of boards grows, it's handy to have a script which builds them all and runs host-based unit tests, to make sure that changes are at least somewhat sane before submitting them to the commit queue. BUG=none BRANCH=none TEST=util/make_all.sh Change-Id: Ie3fcb062caedaf36b3e350c3d9be34a9b080c76d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/63230 Reviewed-by: Rong Chang <rongchang@chromium.org>
* Truncate version string to 32 charactersRandall Spangler2013-07-191-4/+17
| | | | | | | | | | | | | | | | | | | | | | | The version struct and EC_CMD_GET_VERSION assume 32-character version strings. But if the git tree is dirty and the board name is long, the version string overflows that limit. This change truncates what's stored in the version string to fit. The build info still contains the full version string, as it did before. BUG=chrome-os-partner:21156 BRANCH=none TEST=build BOARD=mccroskey with a dirty tree; it should build. Then cat build/mccroskey/ec_version.h to see CROS_EC_VERSION32 has truncated the version string. Then build a platform of your choice and type 'version' to see that the version string and build info is still reported correctly. Change-Id: Ie71b8efd99a83315f8b4d5ad10c51e48781b12f4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62649 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add ectool discharge command to Falco and Peppy.Dave Parker2013-07-191-13/+27
| | | | | | | | | | | | | | | | | | Expands and renames ectool 'chargeforceidle' command to 'chargecontrol'. Board-specific calls are needed to enable and disable the discharge while on AC power state. BUG=chrome-os-partner:20506 BRANCH=falco,peppy TEST=Run ectool chargecontrol command with each option (normal, idle, discharge) on Falco and Peppy. Verifiy battery is discharging in discharge mode via EC console 'battery' command. Change-Id: I7ac2b18b4f143bf6abc1e0bb878ad21a99f52100 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60689 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add EC_CMD_GET_FLASH_INFO version 1Randall Spangler2013-07-181-2/+18
| | | | | | | | | | | | | | | | | | | | | This adds two new fields: the ideal write size for best EC flashing performance (e.g., page mode instead of word mode), and a flags field with a flag to indicate whether the EC erases its bits to 0 or 1. The EC still supports the old version 0 command, since u-boot and flashrom expect that to work. BUG=chrome-os-partner:20973 BRANCH=(all haswell); this will speed up flashing and software sync TEST=ectool flashinfo 1. old EC, new ectool -> only reports version 0 info 2. new EC, old ectool -> only reports version 0 info 3. new EC, new ectool -> reports new fields Change-Id: I484327fe22a58d2b69d7f6ac767b2d3e81b3e0b7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62378 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Add 'version' option to ectool test command.Bill Richardson2013-07-161-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just handy to be sure we're correclty passing the command version to the EC. BUG=chromium:242706 BRANCH=falco, peppy TEST=manual Run "hcdebug params" the EC console (using ToT EC) Compare the output on the EC console when you run these two commands on the host: ectool test 0 13 ectool test 0 13 1 You should see these two lines (among other things): [5728.756652 HC 0x0a.0:000000000d00000030313233343536373839616263646566303132333 43536373839414243444546] [5730.809596 HC 0x0a.1:000000000d00000030313233343536373839616263646566303132333 43536373839414243444546] The "0x0a.0" and "0x0a.1" indicate that the version is being passed correctly. Change-Id: I23b97ac6622274a157717f9375945d0866691a37 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61920 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Split wireless power/radio control out of switch.cRandall Spangler2013-07-111-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Chipset control of wireless power uses the new API instead of overriding the wireless power itself. Refactor board-specific support for it to just a few config #defines instead of board-specific functions. This makes some assumptions about the polarity of the enable signals. Not making those assumptions would require defining an array of structs or some other heavier-weight board-specific info. Since the assumptions hold for all current boards, let's make them now because this is a step in the right direction, and reserve doing something more general until we actually have a use case for it (so we build in just the flexibility we need). BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms; see that link wifi turns on at boot and off at shutdown (verify via 'gpioget' from EC console) Change-Id: Ic036e76158198d2d5e3dd244c3c7b9b1e8d62982 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61608 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Uprev panic data struct versionVic Yang2013-07-101-6/+28
| | | | | | | | | | | | | | | | The struct was changed in commit 74c34bbad, but the struct version was left as 1. We need to uprev this so the data returned by host command is useful. BUG=chrome-os-partner:16901 chrome-os-partner:20548 TEST='ectool panicinfo' with new and old struct. Compare output with output from console command 'panicinfo'. BRANCH=None Change-Id: I4df3142497dc5ee21d100c4cb8118fb7a0ce7a7e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60314 Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
* Initial board commit for Wolf based on Slippy.Dave Parker2013-07-091-1/+1
| | | | | | | | | | | | | Additional fix-ups will come in subsequent CLs. BUG=chrome-os-partner:20760 BRANCH=wolf TEST=Verify "make BOARD=wolf" complete succesfully. Change-Id: I24a37f3bebb1feb37c83c2c1b4f8f8db7bbcb2d8 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61318 Reviewed-by: Shawn Nematbakhsh <shawnn@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-033-14/+9
| | | | | | | | | | | | | | | | 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>
* ec: puppy: add support to flash ecJimmy Zhang2013-07-031-1/+1
| | | | | | | | | | | | BUG=none TEST=flashed ec on venice board Change-Id: I9a8ba6fcbc974d971af7af0f84ff7088cd69b987 Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com> Reviewed-on: https://gerrit.chromium.org/gerrit/60706 Reviewed-by: Andrew Chew <achew@nvidia.com> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@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
* ectool: Correct the empty console checkSimon Glass2013-07-021-2/+3
| | | | | | | | | | | | | | | | | | | | ectool is waiting for an empty response from the EC to tell it to stop requesting console data. However, the EC only sends an empty response when there is no snapshot data. In particular, it seems to send a 1 byte response (containing just a \0 byte) when there is an empty string. Adjust the check to stop when no data is provided. BUG=chrome-os-partner:20639 BRANCH=none TEST=manual Run on test device and see that 'ectool console' now completes and does not run forever. Change-Id: I565f1be506833c823e5e7eca09be8b2420c8190c Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60640 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Add get-protocol-information commandRandall Spangler2013-07-021-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is necessary to support larger packet sizes for host protocol ver.3. The host previously didn't have any way to know how big a packet the EC could accept / respond with (except on LPC, where the size is determined by the I/O window). BUG=chrome-os-partner:20257 BRANCH=none TEST='ectool protoinfo' returns good info; on link, Protocol info: protocol versions: 2 3 max request: 256 bytes max response: 256 bytes flags: 0x00000000 and on pit, Protocol info: protocol versions: 2 3 max request: 544 bytes max response: 544 bytes flags: 0x00000001 Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60703 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Allow bigger flash write commandsRandall Spangler2013-07-014-8/+119
| | | | | | | | | | | | | | | | Version 1 of EC_CMD_FLASH_WRITE will use as big a write as possible given the available command parameter space. Falls back to 64 byte writes on old platforms. BUG=chrome-os-partner:20571 BRANCH=none TEST=Copy burn_my_ec onto a link and run it. Write size should be 64 bytes for the first half of the update (since the old EC doesn't support ver.1 of the write command) and 240 bytes for the second half of the update. Change-Id: I5900de3a5700d7c82a2e0c3cf9921b7ced1c0343 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60511
* Comm interface now provides max I/O sizes and preallocated buffersRandall Spangler2013-07-018-42/+76
| | | | | | | | | | | | | | | | | | | | 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 common interface to EC flash commandsRandall Spangler2013-07-015-72/+184
| | | | | | | | | | | | | | | | | ectool and burn_my_ec need to use the same lower-level interface to the EC flash commands, rather than duplicating calling the low-level flash read/write/erase commands. This is a precursor to refactoring the low-level commands to support SPI/STM32L in a follow-up CL. BUG=chrome-os-partner:20571 BRANCH=none TEST=in a root shell, burn_my_ec flashes both RO and RW EC code Change-Id: I4c72690100d86dbff03b7dacc2fb248b571d3820 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60266
* Split file read/write functions out of ectool.cRandall Spangler2013-06-284-81/+125
| | | | | | | | | | | | | | | | ectool.c has gotten monstrously huge. Refactor out some utility functions. This is precursor work to refactoring out a lower-level flash read/write interface. BUG=chrome-os-partner:20571 BRANCH=none TEST=ectool flashread 0x20000 0x80 /tmp foo -> works Change-Id: I26dae609a73e54e8adaec56edbdce6a0bb4b8758 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60265 Reviewed-by: Vic Yang <victoryang@chromium.org>
* ectool command to print panic dataVic Yang2013-06-271-0/+67
| | | | | | | | | | | | | | This can be useful when the EC reboots but we don't have access to the EC console. BUG=chrome-os-partner:20548 TEST=Manual BRANCH=None Change-Id: I0b762011860d7802ffbc208ffa42920fa6ed098d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60220 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Rename LPC packet size constant for version 3 protocolRandall Spangler2013-06-261-1/+1
| | | | | | | | | | | | | | The maximum packet length for LPC is limited by the I/O space window size. But that's not the case for SPI or LPC. Rename LPC constant before adding a SPI constant. BUG=chrome-os-partner:20257 BRANCH=none TEST=build link Change-Id: I088327a11eff18d401c773db953700a36f9c1bb4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59959
* Add EC_CMD_TEST_PROTOCOL to fake certain responses.Bill Richardson2013-06-203-3/+44
| | | | | | | | | | | | | | | | | | | | | | 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>
* Refactor host command interface to support version 3 packetsRandall Spangler2013-06-201-6/+108
| | | | | | | | | | | | | | | | | | | | | | | | | This will fix EC flash commands on pit, once the host side (u-boot and cros_ec driver) are upgraded to match. This change is backwards-compatible the EC still supports the existing version 2 protocols for talking to existing AP/kernel/ectool. Once the AP-side supports version 3 for SPI (and existing systems are upgraded), we will remove older SPI support since we haven't shipped a product which uses SPI. BUG=chrome-os-partner:20257 BRANCH=none TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link And with an old ectool which predates this CL, 'ectool hello' also works. On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and keyboard works. Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58908 Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Queue: Doug Anderson <dianders@chromium.org>
View Lorry Controller Status