This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When a timing sensitive test run on a heavily loaded system, sometimes a
task runs for longer than it usually does and causes the test to fail.
All the timing requirements in the unit tests are trying to verify the
various delays in our codebase, and mostly we don't care about the time
taken by active running code (as they are very quick.) To improve the
stability of tests, let's slow down the time. To a test, it's as if the
code runs faster. If a test uses udelay() and exceeds the 10-second time
limit, we can make that single test faster by setting the time scale.
BUG=None
TEST=Repeatedly run 'make runtests'
BRANCH=None
Change-Id: I9bc5c77e0d34d04c8630d495387a751ef29c7bd5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220717
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously there was no way to remove multiple units at a time
from the queue, and the queue was wasting an entry to disambiguate
full from empty. There was also no way to get the free entry
count from the queue, only the ability to query if it was above
a required amount. The queue was also storing its constant
compile time configuration as well as its dynamic state in the
same structure. This wasted RAM on configuration information
that doesn't change.
This refactor fixes these issues, making the queue suitable for
use in the new USART stream driver.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I284cee52d8189928dbc4c499f87ab34e14019e5a
Reviewed-on: https://chromium-review.googlesource.com/210533
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Changed motion_sense task to assume sensors are unpowered in G3
and re-initialize sensors every time coming out of G3.
Added EC command line test utils as well.
Fixed some bug during unit tests.
BUG=chrome-os-partner:27313,27320
BRANCH=ToT
TEST=Verified on Samus.
Tested with accel EC CLIs
accelread, accelrange, accelrate, accelres
Tested accelcalib, a ACCEL calibration util, and it succeeded.
Tested sysfs interface:
cd /sys/bus/iio/devices/iio:device1
cat in_accel_*_gyro_raw
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: I5752b00c03e1942c790ea4f28610fda83fa2dcbc
Reviewed-on: https://chromium-review.googlesource.com/211484
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This module controls the inductive charging transmitter. For now, the
policy is to charge whenever possible.
BUG=chrome-os-partner:31392
TEST=Unit test passed
BRANCH=None
Change-Id: Ie48a38ad92fe2bc3329c4962e96572f2bc40b4e6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212715
This CL ensures that temporary "one-shot" sequences such as KONAMI, TEST,
TAP, etc. will revert to the previous "normal" sequences even when
interrupted by other one-shot sequences.
This also adds a test for those cases.
BUG=chrome-os-partner:29873
BRANCH=ToT
TEST=manual
make runtests
Change-Id: Ie83908731acdf2f7c9108568a1ba047943175d26
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213230
Previously our accel / gyro drivers assumed that we had exactly two of
each identical part in the system. Some systems may have different
configurations, so allow this to be specified at the board-level.
Note that our motion_sense algorithm currently assumes that we have one
accelerometer in the lid and one in the base -- we'll need to fix that
in another CL.
BUG=chrome-os-partner:27320
TEST=Compile-only. Tested in future Samus commit.
BRANCH=None.
Change-Id: I1fae1f6c578fedebe78b473a5d66a5794ccaae00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212321
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When emerging chromeos-ec for ryu the build blows up when doing
tests. Remove all tests for RYU so that we can start building the
EC code through the build system.
BUG=chrome-os-partner:30659
BRANCH=None
TEST=Can emerge-rush_ryu chromeos-ec
Change-Id: I293f2640891f42cfea0eb8aeb1ff1de603db9a93
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix motion_sense unit test flakiness by making sure that the lid
angle calculations ran by checking LPC sample id number instead of
relying on a fixed time delay.
BUG=chromium:391625
BRANCH=none
TEST=make -j runtests
Change-Id: I6e879ef28837e62e0c9d4e5f05e0165fa9f9a966
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206878
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This test checks:
- flash_is_erased() returns true when flash is erased.
- flash_is_erased() returns false when the entire flash except one
byte is erased.
BUG=chrome-os-partner:30281
TEST=Check this test fails without the fix for flash_is_erased(), but
passes with it.
BRANCH=all (if the fix is cherry-picked)
Change-Id: Id4fe5591381cabcdad9bb16ba820acd48e92ba13
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206897
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some chargers support a timeout mechanism that it would stop charging
if no voltage/current setting comes from battery or EC. This is designed
for safety.
In charger v1, it always updates charger periodically. But in v2, old code
only updates charger when needed. New code updates the charger periodically.
Also keep the ability for debugging. A manual mode is introduced so that
any requested volt/curr from host and force idle mode request would trigger
this mode. To leave this mode, just disable the force idle mode.
BUG=chrome-os-partner:28201,chrome-os-partner:28208
BRANCH=nyan
TEST=See below.
Plug AC and battery. Wait for 10 mins and the battery is charged normally.
'chgstate idle on': the charger doesn't charge the battery.
'chgstate idle off': charge again.
Plug in AC and remove battery: No annoying repeated message and works fine.
Plug in battery and remove AC: No annoying repeated message and works fine.
Power up machine with battery only: No annoying repeated message and works fine.
Power up machine with AC only: No annoying repeated message and works fine.
Change-Id: I00d62f8afa2fe2627ea9259f11679ced02af897a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196385
Refactored keyboard scan enable/disable flag such that it is a mask of
potential disable sources. When all disable sources are off, scanning is
enabled, otherwise scanning is disabled. This fixes a recently introduced
bug in which enabling/disabling keyboard scanning due to lid angle in S3
was interfering with enabling/disabling keyboard scanning due to power
button. This also allows for easy expansion for future causes for disabling
keyboard scanning.
BUG=chrome-os-partner:27851
BRANCH=rambi
TEST=Manual tests with a glimmer. Used the ksstate console command to
check state of keyboard scanning under all permutations of power button
pressed/unpressed, lid switch open/closed, and lid angle in tablet position
vs. laptop positon.
Change-Id: Ied4c5ebb94510b1078cd81d71373c0f1bd0d6678
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194287
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This improves some of the smart battery mocks, and adds some more tests for
the new change state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make coverage
Line coverage of this file jumps from 53% to 93%.
Change-Id: I4a9b8818cefaffd3022cebe08a36d592b0611295
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193690
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Sometimes the battery happily reports that it's current temperature is
6280C, which is just a little bit high. This just treats unreasonably high
temperatures as an error.
BUG=chrome-os-partner:27527
BRANCH=ToT
TEST=manual
Make the change, watch the EC console while the AP is running and the
battery charges and discharges. The problem is intermittent, but when it
occurs it shuts the AP down immediately. With this change, it just prints a
warning instead.
I've also added a check for this to test/sbs_charging_v2.c
Change-Id: Ibfa53cf0244499ec52d4887bcd06fb9126c07a6c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193277
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:26838
BRANCH=ToT
TEST=Verify only one ACPI 4 event is generated
when attaching external power and that only one
ACPI 5 event is generated when removing external
power. (using the ec console)
Change-Id: I7f8efa03a18bda39152abc2326f1cda928355868
Original-Change-Id: Icaec298bd0f41708260117c26f83fe9158a7ad4e
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189930
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192135
Added ability to disable the keyboard to wake from suspend when the lid
is outside a certain angle range. This has been added to glimmer by
defining CONFIG_LID_ANGLE_KEY_SCAN in its board.h.
Also modified the lid angle calculation to include a reliability
flag which can be used to tell when the hinge aligns too closely
with gravity and the lid angle value is unreliable.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
In S3, verified that when the lid is open past ~180 deg, the keyboard
does not wake the machine. Also verified that if you align hinge with
gravity, the keyboard enabled/disabled status remains the same (since
we can't actually trust the lid angle value).
Change-Id: I45b2c7c3c4bbcae61d3a0f8b5baa461ab8dabfb0
Original-Change-Id: If1a1592d259902d38941936961854b81b3a75b95
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190061
Reviewed-on: https://chromium-review.googlesource.com/191612
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When measuring speed gain of mem*() in utils test on host, there are too
many reasons that the results may be fluctuate. This gets even worse
when the unit tests run on buildbots. Let's only check for speed gain on
device.
BUG=chromium:351870
TEST=Check the speed gain check assertion is not compiled.
BRANCH=None
Change-Id: I0369d07d1da8cbb469d3a2a9d846406415c06745
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189804
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On some CPU cores, the compiler needs an helper to perform the 64-bit
multiplication. As the only remaining 64-bit multiplication in the code base
is not necessary, fix it rather than adding the helper.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=build for Cortex-M0 platform.
Change-Id: I88dd7a4f2eabeca5b03fb3db232bbca9a037dcf8
Reviewed-on: https://chromium-review.googlesource.com/189151
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
On some CPU cores, the compiler needs an helper to perform the 64-bit
multiplication.
As the only 64-bit multiplication in the code base is not necessary, fix
it rather than adding the helper.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=build for Cortex-M0 platform.
Change-Id: Id5d6b4b6641f81732a456dacb78dee7262f6729d
Reviewed-on: https://chromium-review.googlesource.com/188980
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Compiling with coverage enabled screws up the time that things take, so
don't test for a particular speedup in that case. It fails unreliably.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
cd src/platform/ec
make coverage
Before, it failed about half the time. Now it doesn't.
Change-Id: I535f0193bf450a922b486777b296fea1b2768a1a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188790
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This speeds up memset by copying a word at a time.
Ran the unit test on Peppy:
> runtest
...
Running test_memset... (speed gain: 141532 -> 32136 us) OK
...
Ran make buildall:
...
Running test_memset... (speed gain: 1338 -> 280 us) OK
...
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If34b06ad70f448d950535a4bea4f6556627a9b6f
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185936
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
This speeds up memmove by copying a word at a time.
Ran the unit test on Peppy:
> runtest
...
Running test_memmove... (speed gain: 2156 -> 592 us) OK
...
Ran make buildall:
...
Running test_memmove... (speed gain: 143918 -> 32367 us) OK
...
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Change-Id: I6a3ac6aed27a404c3bef227b6c886a59414b51d7
Reviewed-on: https://chromium-review.googlesource.com/186020
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This speeds up memcpy by copying a word at a time if source and destination are
aligned in mod 4. That is, if n and m are a positive integer:
4n -> 4m: aligned, 4x speed.
4n -> 4m+1: misaligned.
4n+1 -> 4m+1: aligned in mod 4, 4x speed.
Ran the unit test on Peppy:
> runtest
...
Running test_memcpy... (speed gain: 120300 -> 38103 us) OK
...
Ran make buildall -j:
...
Running test_memcpy... (speed gain: 2084 -> 549 us) OK
...
Note misaligned case is also optimized. Unit test runs in 298 us on Peppy while
it takes about 475 with the original memcpy.
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ic12260451c5efd0896d6353017cd45d29cb672db
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185618
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Change 18baa15 made a call to keyboard keyboard_update_button
conditional on running the KEYPROTO task. This call is needed
for the button unit test.
This fixes a test breakage when running "make buildall"
BUG=None
BRANCH=ToT
TEST=Run "make buildall -j32" "make BOARD=glimmer tests -j32"
and "make BOARD=rambi tests -j32" successfully with a
"make clobber" in between.
Signed-off-by: Dave Parker <dparker@chromium.org>
Orig-Change-Id: I6f10577ffd189fee7081aa65cf5adb9075c95373
Reviewed-on: https://chromium-review.googlesource.com/185104
Tested-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
(cherry picked from commit c267054850c4b296a364e975063c634f34d701e9)
Change-Id: I92932577e83561530ef288c6ede211fa809962f8
Reviewed-on: https://chromium-review.googlesource.com/185245
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
The implementation of trace dump has little to do with task scheduling,
so we should move it to a separate module for cleaner code. This
requires exposing some emulator-specific task info, as defined in
host_task.h.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: Iba9bc0794a4e1dd4ddb92b98345162b398fa6a8d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183238
Settings in test_config.h should only be applied #ifdef TEST_BUILD.
This fixes omitting vboot hash all time. It should only be omitted
for test builds.
BUG=chrome-os-partner:24892
BRANCH=all
TEST=boot system; 'hash' command works on EC and system is not stuck in
recovery mode.
Change-Id: I15f645824382e25caef9c1c045bb079f374fbb88
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds golden wake count for each task and check at the end of the
test. The golden wake count is calculated with the seeds and the pseudo
random number generator.
BUG=chrome-os-partner:23800
TEST=Pass the test
BRANCH=None
Change-Id: I7e90336b3f0b0355795ada7baf7c052a047ee302
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
The variable 'interval' is declared as unsigned integer, and this
sometimes causes an integer underflow when substracting it by SECOND,
and in turns leads to false test failure. Changing it to signed integer.
BUG=chrome-os-partner:19236
TEST=Repeatedly run hooks test
BRANCH=None
Change-Id: Ic6d8001f90fb8756b6bdadf811a668c02fbccb34
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181882
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The mock power button GPIO is initially low, so we need to set it high
before testing it. Also, wait for all tasks to start before starting the
test to prevent race condition.
BUG=chrome-os-partner:19236
TEST=Pass the test
BRANCH=None
Change-Id: I813588a9c721815c1213882f7a9458daea4d78eb
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Those are actually charge state, not power state. Rename the misleading
names.
BUG=chrome-os-partner:24832
BRANCH=link,falco,samus,rambi,peppy,spring,pit,snow
TEST=build only because no name conflicts.
make clean BOARD=link && make -j32 BOARD=link && \
make clean BOARD=falco && make -j 32 BOARD=falco && \
make clean BOARD=samus && make -j 32 BOARD=samus && \
make clean BOARD=rambi && make -j 32 BOARD=rambi && \
make clean BOARD=peppy && make -j 32 BOARD=peppy && \
make clean BOARD=snow && make -j 32 BOARD=snow && \
make clean BOARD=spring && make -j 32 BOARD=spring && \
make clean BOARD=pit && make -j 32 BOARD=pit && \
make clean BOARD=nyan && make -j 32 BOARD=nyan && \
make runtests -j 32 && make tests -j 32 BOARD=link && \
make tests -j 32 BOARD=falco && make tests -j 32 BOARD=samus && \
make tests -j 32 BOARD=rambi && make tests -j 32 BOARD=peppy && \
make tests -j 32 BOARD=snow && make tests -j 32 BOARD=spring && \
make tests -j 32 BOARD=pit && make tests -j 32 BOARD=nyan
Change-Id: Ie15052d5a7dbd97d519303d37260945346a27779
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181505
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Renaming file names is the first step. Please see issue tracker
for more details.
BUG=chrome-os-partner:24832
BRANCH=link,falco,samus,rambi,peppy
TEST=build all x86 boards.
make clean BOARD=link && make -j32 BOARD=link && \
make clean BOARD=falco && make -j32 BOARD=falco && \
make clean BOARD=samus && make -j32 BOARD=samus && \
make clean BOARD=rambi && make -j32 BOARD=rambi && \
make clean BOARD=peppy && make -j32 BOARD=peppy
Change-Id: I3a296a0c14f6bebefa858438b1320061ac71dd38
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181400
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This provides us a way to inject interrupts during a test. If a test has
interrupt_generator() defined, it will run in a separate thread. The
generator can then trigger interrupts when it decides to. The current
running task is suspended while emulator is executing ISR.
Also fixes a bug that tasks run without scheduler notifying them during
emulator start-up.
BUG=chrome-os-partner:19235
TEST=Repeatedly run all tests.
BRANCH=None
Change-Id: I0f921c47c0f848a9626da6272d9040e2b7c5ac86
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/55671
We have three copies of the same pseudo random number generator in our
test codes. Let's consolidate them into a single copy in test_util.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: I7ea0b3476f3cfe6944855f19861e3c86af35807e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181085
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
This renames constants used in compiler conditionals to uppercase.
BOARD_foo
CHIP_foo
CHIP_FAMILY_foo
CHIP_VARIANT_foo
CORE_foo
Mixed-case constants are still defined by the makefile, but are now no
longer used. I will make one more pass in a week or so to catch any
that are part of someone else's CL, since otherwise this change might
silently merge correctly but result in incorrect compilation. Then I
will remove defining the mixed-case constants.
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no
results (similarly for CHIP, CORE, etc.)
Change-Id: I6418412e9f7ec604a35c2d426d12475dd83e7076
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179206
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
