As advised by Daisuke makes the new API slightly better:
- remove the useless rxlen assignment.
- keep the normal asynchronous behavior of the function by skipping the
last dma wait.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, use the FP sensor with the passthru.
Change-Id: Iedb8e77cb1af58c273ab5ae6f0a670ce93dfde5a
Reviewed-on: https://chromium-review.googlesource.com/454699
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Master chip/g FW still needs to support deprecated RO, so re-add support
for the old version_struct. This CL can be reverted once we no longer
need to support deprecated RO on master.
BUG=chromium:698881,chromium:698882
TEST=Flash old FW (f51fdf2) to RW_B slot and updated FW to RW_A. Verify
cr50 boots into RW_A, and "version" on the console prints RW_B version,
not "Error".
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3c255afcd12da5694ca128960de8d2abe41686dc
Reviewed-on: https://chromium-review.googlesource.com/450860
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Change-Id: I35f0aa87f5ab1371dbd8b132f22b9d0044358223
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450859
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When an x86 based system is reset, a pulse on the plt_rst_l line is
generated. This pulse is supposed to reset the system and the pulse'
rising edge is an interrupt trigger for H1 to reset the TPM. If H1 is
in sleep state at the time of the rising edge, the interrupt request
could be lost.
Luckily, the minimum plt_rst_l pulse duration is 1 ms, and the worst
case max time to wake up from sleep for H1 150 us. Let's wake up on
low level of plt_rst_l, this way by the time the rising edge comes
along the H1 would be awake and ready to process the interrupt.
BRANCH=cr50
BUG=b:35995492
TEST=verified that platform_KernelErrorPaths.CORRUPT_STACK passes
hundreds of times on a system were it was failing after a few
runs before this fix.
- verified that suspend_stress_test still succeeds at least 300
iterations
Change-Id: Ib9984efa08bdd185a95716dc9e48077cf4bb3c2a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/455579
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Erase the first location in the manifest info map to ensure that the
flash info state is updates and then the RO prevents booting earlier
images (where the map is unaltered).
BRANCH=cr50
BUG=none
TEST=verified that once both RW_A and RW_B are programmed with the new
image and the H1 is restarted, the first info map location is erased.
Change-Id: Id48d8a2009f7cf9842b7a33f036dc98457dbeafc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/455580
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Enable more hardware related console commands to help hardware
validation.
BUG=chrome-os-partner:62673
TEST=manual
build and load into Rowan
check console commands:
gpioget
spixfer
BRANCH=none
Change-Id: I86d3b74cef77ed9244a140290241a9fac6af3f84
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441486
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
EC controls SPI CS pin as GPIO. This CL remove the ALT function
config. And before trigger SPI hardware reset, the driver state needs to
be disable.
BUG=chrome-os-partner:62673
TEST=manual
load into Rowan and boot up AP.
check console command accelread
BRANCH=none
Change-Id: I511c5906efbbb42b09547c61414bcc24b0217ad3
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441485
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
spi_transaction() always returns success even without the sensor.
Check whoami value to make sure that the sensor is existed.
BUG=none
BRANCH=none
TEST=remove LID accel sensor from elm and see init failed log.
[1.258973 Lid Accel: 1: init failed: 4]
Change-Id: I55aa35bc9790e5dec61e22aa2f51243e29368a86
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/453579
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The led_get_brightness_range and led_set_brightness functions are only
used by the led control host command and exercised via ectool for
factory testing.
Currently the ectool inputs must be inverted to get expected behavior:
ectool led power red=100 green=100 blue=20 << blue
Instead we can invert them in the EC to get more intuitive behavior for
the user input values, and use the led_id parameter to split the control
so they can be addressed individually for testing:
ectool led left red=0 green=0 blue=80 << blue
ectool led right red=100 green=13 blue=0 << amber
BUG=b:36150361
BRANCH=none
TEST=Tested manual control of indivual LEDs using ectool
Change-Id: I6551656f3faf26930749d1e9d45a176088c6646c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/453303
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Add LED types for left and right so they can be addressed
properly with ectool.
BUG=b:36150361
BRANCH=none
TEST=manual testing of 'ectool led <left|right> <color>' behavior
Change-Id: Iea25cc69db2d35416e787dcb5a324d2e2cf5d3a6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/453126
Reviewed-by: Scott Collyer <scollyer@chromium.org>
IADP monitoring bit was set to the default value for the devices
with an RO image which clears the bit (and causes the issue).
This patch removes the code so that we do not touch the IADP
monitoring bit since transitioning from 0->1 may cause other issues.
BUG=b:35647661
BRANCH=reef
TEST=none
Change-Id: I4413e0bd2de3f4e3912cbe6e73b8cad641ee9245
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453400
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453798
In order to make pass through charging safe, there must be a mechanism
to signal the CHG port manager that Vbus is available and in a steady
state. When a typec only charger is used for the CHG port, then it's
steady state is SRC_DISCOVERY. Need a way to differentiate the TypeC
only charger from a USB PD charger that's also going through
SNK_DISCOVERY.
In addition, to allow a DTS device to support PD messaging, can't
stay in SRC_ACCESSORY state. This CL makes a modification to the
USB PD state machine so that if a debug accessory is detected and
CONFIG_USB_PD_DTS is defined, then the state machine will advance to
SRC_STARTUP and prepare for messages similar to when a UFP attach
is detected.
BUG=b:35586526
BRANCH=servo
TEST=Manual Built for both Plankton and Reef, verified that Reef
connects as both SNK and SRC.
Change-Id: I9aea0341cd9b6e6773023f0923a9a18a86fc4627
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448987
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Extend the SPI master API to be able to do fancier transactions:
- allow to read the incoming bits while transmitting.
If SPI_READBACK_ALL is set in 'rxlen' when calling spi_transaction(),
then the received data during transmission is recorded in rxdata buffer
and the function assumes that the real 'rxlen' is equal to 'txlen'.
- add spi_transaction_wait() which is similar to spi_transaction_flush()
but without de-asserting the chip select, so we can chain several
transfers in a single transaction.
Implement them for STM32.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, use the FP sensor with the passthru.
Change-Id: Iebff617acd3230277d36a4f565766b7748721a1d
Reviewed-on: https://chromium-review.googlesource.com/452898
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Enable properly the SPI slave command interface to drive the FP MCU from
the main CPU using the EC SPI protocol V3.
Fix the SPI slave driver on STM32L4 along the way:
- the STM32L4 family has the same FIFOs as STM32F0
- on STM32L4, we need to map the DMA requests
- set explicitly the data size (rather than setting an invalid value
which defaults to 8-bit).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:36025702
TEST=On Eve, use the kernel cros_ec_spi driver to communicate with the
FPMCU using the Cros EC SPI protocol V3.
Change-Id: Ib641c141808aa60b3a74611319e18e7a6c3736f0
Reviewed-on: https://chromium-review.googlesource.com/452373
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
When sighing prod images it is important to be able to reproduce them
bit for bit. Setting the manifest timestamp filed to a non-zero value
makes sure that this value is used in the header as opposed to the
current time.
Setting the value to 1 guarantees that any dev image with the same
epoch/major/minor field values will be preferred, as it would have a
later timestamp.
BRANCH=none
BUG=none
TEST=verified that two images built with this manifest are exactly the
same (they used to differ before this change).
verified that the header timestamp field is indeed set to 1:
$ od -Ax -t x1 -vd d2/cr50.bin.prod | grep -A1 004350
$ 004350 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00
$ 004360 00 00 00 00 11 00 00 00 01 00 00 00 00 00 00 00
location 0x435c is the epoch_ field offset, 32 bit
epoch/major/minor is set to 0/0/17 and 64 bit timestamp is set to
1.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: I6ea0e664fa3eab7917ca472d715824feec49eb51
Reviewed-on: https://chromium-review.googlesource.com/452956
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Without this include, the `watchdog_reload()` function will be compiled
as a noop unless "config.h" is included before "watchdog.h" in whatever
compilation unit requires watchdog functionality.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I311019753f6d61890be1e475664bd528e5250729
Reviewed-on: https://chromium-review.googlesource.com/449694
Commit-Ready: Jeff Andersen <jeffandersen@google.com>
Tested-by: Jeff Andersen <jeffandersen@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Prevent spurious wake when servo is not connected.
BRANCH=none
BUG=b:36119938
TEST=Measure pull up value with a multimeter when servo is not
connected: value around 30k when host in S0 and S3.
Change-Id: I8bd54e4dcfd5c65f1f0cd32ffd4a70cedb979cc2
Reviewed-on: https://chromium-review.googlesource.com/452652
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=b:35775100
BRANCH=None
TEST=Verified that tablet mode switch events can be seen in evtest.
Event: time 1489093184.754803, -------------- SYN_REPORT ------------
Event: time 1489093196.842930, type 5 (EV_SW), code 1 (SW_TABLET_MODE), value 0
Event: time 1489093196.842930, -------------- SYN_REPORT ------------
Event: time 1489093198.839809, type 5 (EV_SW), code 1 (SW_TABLET_MODE), value 1
Event: time 1489093198.839809, -------------- SYN_REPORT ------------
Change-Id: Id47e817ba12294cc07281df3e04a9d68dec40ee7
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/451582
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Send EC_HOST_EVENT_MODE_CHANGE upon base attach and detach, to
wake the AP as required. Also, re-factor the code for base detect
status change to allow single function for all actions that need to be
taken on base attach/detach.
BRANCH=none
BUG=b:35775085
TEST=Flash poppy, powerd_dbus_suspend, EC wakes the AP on base
attach. Confirmed in eventlog that wake event is seen by AP:
53 | 2017-03-08 16:44:58 | ACPI Enter | S3
54 | 2017-03-08 16:45:06 | ACPI Wake | S3
55 | 2017-03-08 16:45:06 | EC Event | Mode change
Change-Id: I5b488b32df0454f14a9d784e7564be7e999caadd
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SPI initialization interrupt needs to be generated only when there
was actual data received while CS was asserted and after transaction
finished (i.e. CS is de-asserted).
BRANCH=cr50
BUG=b:35774896
TEST=verified on a bob with updated AP firmware
Change-Id: Ifc4b11870d511d47e9607a2001d845ee1e153f7f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452792
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
To improve robustness of booting under low battery condidtions,
increased the thershold CONFIG_USB_PD_TRY_SRC_MIN_BATT_SOC from 1 to
2. The effect of this change is that try srouce mode will be disabled
until the battery has >= 2% of charge. This prevents the port from
disconnecting, when a USB PD charge is connected under this low
battery condition.
BUG=b:36093023
BRANCH=None
TEST=Verfied that when the battery charge was < 2% the USB PD state
machine on Eve did not go to state 15 (SRC_DISCONNECTED) after
initially attaching as a sink device. When the battery charge is >= 2%
then observed that the transition to state 15 happens.
Change-Id: I50123bc4f98e7a8dc793d9a9844d1d9961fde121
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452739
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Follow reef setting.
When battery is fully charged, pyro starts discharging to protect
battery and starts charging again when charge level goes down
around 95%. To prevent the battery LED from showing green with the
charger plugged in.
BUG=none
BRANCH=reef
TEST=Fully charge Electro. Plug in OEM charger. LED lights green.
Change-Id: If8560cbc3975b35ae84a9df2bdf5331c653143d1
Signed-off-by: Bruce.Wan <Bruce.Wan@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/449600
Commit-Ready: Keith Tzeng <keith.tzeng@quantatw.com>
Tested-by: Keith Tzeng <keith.tzeng@quantatw.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This command is handy in debug images when rollback protection needs
to be reset.
Manufacturing data stored in the last quarter of the INFO1 space is
preserved across the erase session.
BRANCH=cr50
BUG=b:35774863
TEST=built a non-debug image with the first map location in the
manifest set to zero, booted the new image. Then built and booted
a debug image with this patch included. Using sysinfo command
verified that the info map has one location zeroed, then ran
eraseflashinfo command and checked sysinfo output again. The info
map shows no more zeroed locations, and tpm still reports statues
as "manufacutred"
Change-Id: I58e2a6f6371b6ce656c1d6cc373dfdc6f9d9f5be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450906
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
With enabling INFO1 map based rollback protection it is important to
be able to tell the state of the flash map and the currently installed
images' infomap header field.
The new function counts number of zero words in the info map and zero
bits in both RW headers, and returns them in a string printed out by
the sysinfo command.
BRANCH=cr50
BUG=b:35774863
TEST=built images with different manifest info field contents and
verified that the string printed by the sysinfo command makes sense.
Change-Id: If633a6c678dc34197b2dad116b6180b2d549e089
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450905
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Debug images should run on any H1 device, no matter what its INFO mask
is set to. This is achieved by emptying the info {} section of the
manifest when building images with nonempty CR50_DEV in the
environment.
BRANCH=cr50
BUG=b:35774863
TEST=built images with and without CR50_DEV=1, verified that the
manifest has the info{} section emptied when CR50_DEV is set.
Verified that the RW images boot fine.
Change-Id: Ied314c175d5c02f4108b7af85c244b6da8547616
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450904
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The cr50 RO image compares INFO rollback map space against the
contents of the RW image's infomap field.
To ensure that no rollback is possible, the RW should verify that the
INFO space state is consistent with the current RW and RW_B headers,
and if not, update the INFO state to comply.
This should happen only when running prod images, so that debug images
could be rolled back if so desired.
Also fixed the bug in functions enabling read and write access to the
INFO1 region. Write access is now a superset of read access setting.
BRANCH=cr50
BUG=b:35774863
TEST=as follows:
- built and ran a new image, observed it start successfully;
- modified the manifest to erase the first map location, built and
ran a new image, observed it start successfully
- restored the manifest, built and tried running a new image,
observed that the earlier version is starting.
Change-Id: I62253c3e98cd24ed24424b8bb9de22692a262d89
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447966
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In order to prevent noise when using the system with a full
battery the EC can disable charging at full until it reaches
97% and then turn on charging again.
However this needs additional LED handling to ensure that the
charging LED is shown green in this state.
BUG=b:36024657
BRANCH=none
TEST=manual test with full battery on Eve P1b, ensure that the
LED is still green when battery is full and discharging.
Change-Id: Iad2b1462ad85163dc9702ff1154f3ff10eb0f7ca
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450953
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Limit max input current to 95% for safety.
(changes ported from reef)
BUG=b:36024657
BRANCH=none
TEST=manual testing on Eve P1b board
Change-Id: I6beb3fc4ac62e40bb7c8dfc8463e6a0d177997d9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450952
Reviewed-by: Scott Collyer <scollyer@chromium.org>
To prevent in rush current from the charger when attached, enable
discharge on AC until the charger is detected.
This required enabling charger profile override which was previously
not getting called, so discharging was never disabled.
BUG=b:36024657
BRANCH=none
TEST=build and boot on eve, ensure battery charges with AC attached
Change-Id: Ie5912c1d4981d894366f36f31607d5f66a04c346
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450951
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Limit battery charge voltage to prevent battery over-charge due to
regulation inaccuracy.
(ported from reef board)
BUG=b:36024657
BRANCH=none
TEST=build and boot on reef and ensure charging is still functional
Change-Id: I90dd8bda3d67a6c50aa39bbd096239565c73b7c5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450950
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Allow the board to override the hardcoded 97% value for reporting to
the host (and controlling LED behavior) when the battery is "near full".
When enabling "discharge on ac" with a full battery the battery stops
taking a charge until it reaches ~94% SOC (the actual value is not set
but rather comes from a smart battery status bit) but the user will see
the device as discharging between 97% and 94%.
The host side view can be worked around with a powerd preference.
The LED behavior is all inside the EC, so you end up with the LED showing
discharging when it should not.
If we allow the board to override this to 94% then the LED and host
behavior is consistent.
BUG=b:36024657
BRANCH=none
TEST=make -j buildall
Change-Id: Ie5ab8e41b87101e201073276bf441e25be7daca4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450949
Reviewed-by: Scott Collyer <scollyer@chromium.org>
To make sure cr50 usb works, we need to disable sleep immediately
after the usb controller detects that usb has resumed. The usb WKUPINT
is asserted on usb resume, but cr50 doesn't currently respond to that.
This change umasks the usb wakeup interrupt, so that USB ISR will
disable sleep on resume.
BUG=b:35774906
BRANCH=none
TEST=Run 100 'usb_updater -f' 100 times sleeping 20 seconds in between
each run. Verify there are no failures and cr50 still goes to sleep
between each run.
Change-Id: I1819deaa3988bcf2a85686d1b9d57092ba264c4d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450900
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Pass "full_build_string" to ccprintf() as expected. I believe that this
code only worked previosly due to blind luck; the compiler allocated
"full_build_string" on the stack in such a way that it was available at the
end of the call frame for ccprintf().
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: Ib307547a4c4d6300ccf018b33aee4db7a4f364f8
Reviewed-on: https://chromium-review.googlesource.com/451084
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Matches the pressure multiplier used with elan trackpad on Chrome OS
(3.1416). We do fixed point arithmetic to avoid the need for
floating point or non-power of 2 division.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: Ic3daad2645839955734eb7cbd9a60bbdf2520ce8
Reviewed-on: https://chromium-review.googlesource.com/450994
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
