Sometimes the toolchain tries to put a relocation which is not suitable
to access variables in a read-only section.
The nds32 gcc uses GP-relative signed 17-bit relocation to access
variables stored in .rodata (eg lwi.gp $r0, [ +gp ])
That's wrong since $gp is pointing in the middle of .data and .bss in
the SRAM, while .rodata is sitting in flash.
Since on IT8380, the flash is at 0x00000 and the SRAM is at 0x80000
(512kB further), the linker will fail trying to create the signed 17-bit
relocation (it detect that it needs to truncate it)
Force the compiler to put another relocation as a workaround for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24378
TEST=./util/make_all.sh ; make BOARD=it8380dev
check "version" and "gpioget" on spring, link and it8380dev.
Change-Id: Ife50adf3a26be28f113292f73a1a70e8d74b5d8c
Reviewed-on: https://chromium-review.googlesource.com/176913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Move the non-core dependent code out of core/$(CORE) directory to
common/ directory.
Put all panic printing code in common/panic_output.c
Put timer management code in common/timer.c
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23574
TEST=./util/make_all.sh
use "crash divzero" and "panicinfo" on Link.
Change-Id: Ia4e1ebc74cd53da55fe24f69e96f39f512b9336d
Reviewed-on: https://chromium-review.googlesource.com/178871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
BSS section is usually put at the beginning of the RAM, so large
alignemnt causes the least memory usage penalty here, compared to
alignment using __attribute__((aligned(x))).
Also remove .bss.tasks and .bss.task_scratchpad, which are both not
present anymore.
BUG=chrome-os-partner:24107
TEST=Build all boards. Boot mec1322_evb.
BRANCH=None
Change-Id: Ie19b9feb76773a94f0443c2a0d39505ddef7a1df
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178274
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A cprintf could increase 96+ bytes of stack usage and may overflow
the stack of idle task, which is 256 bytes on stm32.
BUG=chrome-os-partner:23982
BRANCH=nyan
TEST=verified on nyan
Change-Id: If96a1c51010116a2b4f3d67481ec0acc7bf78dd9
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176619
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changes somewhere in the recent past have caused I2C operations to
consume more stack space. The current failure mode is that after some
debug command or infrequent battery operation, the system fails.
Clean up and enable stack overflow detection by default, and add a
debug command (disabled by default) to verify overflow detection
works.
This adds several instructions to each context switch, but it's still
fairly inexpensive, and represents only a few percent increase in the
size of svc_handler(). That's better than silent failures.
BUG=chrome-os-partner:23938
BRANCH=none
TEST=Enable CONFIG_CMD_STACKOVERFLOW, then run the 'stackoverflow' command.
This should cause a stack overflow to be detected in the CONSOLE task.
Change-Id: I9303aee5bd9318f1d92838b399d15fb8f6a2bbf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176113
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cortex-M3 and Cortex-M4 are not using exactly the same instruction set.
Cortex-M3 is using ARMv7-M ISA which is a subset of the ARMv7E-M used by
the Cortex-M4 core (even though the delta is small).
Let's restrict each core to the right subset of instruction by pushing
the -mcpu/-march configuration in the chip specific area.
Note: GCC 4.8 is now using the full ARMv7E-M instruction set and will emit
"undefined instruction" on Cortex-M3 without this patch.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:314194
TEST=build *and* run on Spring and Link.
Change-Id: I2f9b87fec689e8d1097809cab437a2bd32dfa194
Reviewed-on: https://chromium-review.googlesource.com/175487
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add bug references. Remove one assert that can no longer be triggered.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I3f4d2e4f2f3343a8d0531cb0715d151eaa4d0b50
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175293
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The current chroot toolchain properly compiles the SVC instruction, so
there's no need to hard-code the opcode. That was a workaround for
binutils < 2.22 (that is, binutils versions more than 2 years old).
BUG=chrome-os-partner:23721
BRANCH=none
TEST=compare EC binaries before/after this change; only the
datestamp should be different
Change-Id: I9c6282768c4562926397866ac3be218c393e3865
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175172
To test drivers, we need a way to fake I2C periphrals. With this CL, a
fake peripheral can be done by declaring its own I2C read/write
functions. The fake I2C peripherals may return EC_ERROR_INVAL to
indicate it's not responding. The emulator I2C read/write call scans
through all registered I2C peripherals and uses the first response.
BUG=chrome-os-partner:19235
TEST=Pass sbs_charging test with the next CL.
BRANCH=None
Change-Id: I9380dc40e147781b42e09eb6979c864bbd9f2ac4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169511
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This checks boot key combination like Power-F3-ESC and Power-F3-Down can
be properly detected.
BUG=chrome-os-partner:19236
TEST=Pass kb_scan test
BRANCH=None
Change-Id: I180918977299219a8421798dac2ab9fed84ef9a2
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167802
When running an unit test, the emulator is sitting in idle task for most
of the time. Since we don't have interrupt support now, the emulator is
just waiting for the next wake-up timer to fire. To save time, we can
actually just figure out which task is the next to wake up, and then
fast-forward the system clock to that time.
With this, all tests run faster and we can remove time-scaling for all
current tests. This improves not only run time but also stability.
If one day we have interrupt support, then we will have to modify this
to take into account the fact that an interrupt might wake a task before
any wake-up timer fires.
BUG=chrome-os-partner:19235
TEST=Run all tests in parallel for 1000 times.
BRANCH=None
Change-Id: I4cd33b041230267c110af015d425dd78d124f963
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167801
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before this change drivers had no way of knowing that a frequency
change was coming. This could cause problems for some drivers (like
i2c) that need to make sure that a transaction isn't happening while a
frequency change is happening.
The PRE_FREQ_CHANGE archiecture is very simple here and we don't allow
any way to cancel it.
At the moment, we guarantee:
- We won't call PRE_FREQ_CHANGE with interrupts disabled, so acquiring
locks / sleeping is OK.
- We'll call the actual HOOK_FREQ_CHANGE after the PRE_FREQ_CHANGE.
PRE_FREQ_CHANGE and HOOK_FREQ_CHANGE should not use deferred function
calls.
BRANCH=pit
BUG=chrome-os-partner:22093
TEST=With all patches together:
- on AP: suspend_stress_test
- on EC: battery 10000 50
Change-Id: I2731a3e85d41e749fa571fdb74b5c9b12043cda6
Signed-off-by: Doug Anderson <dianders@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/167101
(cherry picked from commit d84c0dbbf7c5a72917a820e292ecfdfa698d0fb9)
Reviewed-on: https://chromium-review.googlesource.com/167148
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The registers.h file should only be included by code in the chip/ and
board/ directories. Code outside those directories should not access
chip-specific registers.
(This change doesn't completely fix that, because
common/extpower_usb.c uses STM32-specific regs, but we'll fix that in
a separate CL.)
BUG=chrome-os-partner:18343
BRANCH=none
TEST=compile all platforms
Change-Id: Ic499f56690c38663083423b0593800161a68e6e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64382
Reviewed-by: Vic Yang <victoryang@chromium.org>
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>
All of these were defined on all but a few platforms, and those
explicitly #undef them. So define them as enabled by default in
config.h so the board.h files are cleaner.
No functional changes; just rearranging/renaming config constants.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; FEATURES=test emerge-falco chromeos-ec
Change-Id: I1201a1472ae29641e9e219c2a0347691ca64cd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63102
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reset flags should be set properly according to reset type. Also, on
system jump, current time should be preserved.
BUG=chrome-os-partner:19235
TEST='sysjump rw' and check time is the same.
TEST='reboot hard' and see '[Reset cause: hard]'
BRANCH=None
Change-Id: I00fd2c652d10c237f23cc6a33e0b667422bc625d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62958
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
By 'make coverage', lcov is used to generate test coverage report in
HTML format stored in coverage_rpt folder.
BUG=chrome-os-partner:19235
TEST=Generate a report.
BRANCH=None
Change-Id: I44142eaaeb897cf09179764781120370920144cd
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58203
This creates a separate thread that keeps reading characters from stdin
and feed to UART process.
BUG=chrome-os-partner:19235
TEST=Start up a emulator and type 'help'. See command list.
TEST=Pass all tests for 300 times.
BRANCH=None
Change-Id: I190c1d939b0b4ad0f8f0517d8d7b06f2f3df3832
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57866
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This enables ASSERT() for easier debugging.
BUG=chrome-os-partner:19235
TEST=Add ASSERT(0) in lid_sw test and see error message:
ASSERTION FAIL: test/lid_sw.c:91:run_test - 0
BRANCH=None
Change-Id: I7df7d5984e5d787fdc5ad2b6b24fec669e95c97e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56691
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When it was a naked call, if it doesn't jump somewhere, it just
falls through to whatever code happens to be next. Which happened to
re-enable bus faults - meaning that only the first fault was being
ignored. That's a problem for flash protection on STM32, where writes
to potentially-locked key registers come in pairs.
BUG=chrome-os-partner:19564
BRANCH=spring
TEST=manual, on pit:
1. Hack in a igbusfault console command to call ignore_bus_fault()
2. igbusfault 1
3. ww 0x40023c0c 0xdeadbeef -> no fault
4. ww 0x40023c0c 0xdeadbeef -> still no fault
5. igbusfault 0
6. ww 0x40023c0c 0xdeadbeef -> exception and reboot
Change-Id: I5cf74b06a76ebf0176a2905924be87b3d1c825ce
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55572
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This reverts commit c58c01b14c.
Let's add time scaling back, but keep the default scale to 1. The
emulator behavior should be entirely the same. If a test need to be
speeded up, the scale can then be set for that test only.
BUG=chrome-os-partner:19235
TEST=Pass all tests.
BRANCH=None
Change-Id: I648780577a1ae2f964c30c71077ccf9bf38b9735
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51550
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The timer is the only source of timing for the emulator. This means we
can make it go faster without breaking the tests. This CL sets the
default scale to be 3x faster than normal time.
BUG=chrome-os-partner:19235
TEST=Pass all tests. Check the tests run faster.
BRANCH=None
Change-Id: Ib9035884b34f41c4e9aa2206284b5f1ec8fc0d1f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50956
Several test utility macros have been duplicated across tests. Let's put
them in a single place.
BUG=chrome-os-partner:19236
TEST='make runtests', 'BOARD=spring make tests'
BRANCH=None
Change-Id: Ib0c9f829715425cc23e33b8ef456b17dfadab13c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50513
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On 64-bit platform, arrays should be aligned to 8 bytes. Also, change
the order of host_command fields so that it's packed on both 32-bit and
64-bit platforms.
BUG=chrome-os-partner:19257
TEST=Pass all tests. Print out and check the content of host commands.
BRANCH=None
Change-Id: I350a903bc11562d6d205c402548942f8967b75a5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50467
Perviously we use uint32_t for this, but this doesn't compile for 64-bit
environment (and likely doesn't for 16-bit either.) Use uintptr_t so that
we don't get size mismatch errors.
BUG=chrome-os-partner:19257
TEST=Run host emulated tests
BRANCH=None
Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is the first version of pthread-based RTOS emulator. With this, we
will be able to test high-level modules entirely on the host machine.
BUG=chrome-os-partner:19325
TEST='make runtests' and see tests passing.
BRANCH=None
Change-Id: I1f5fcd76aa84bdb46c7d35c5e60ae5d92fd3a319
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This will let us check the size of static array initializers.
Also moved this macro definition and ARRAY_SIZE into a new "tricks.h"
header, so that userspace utils can use it too.
BUG=none
BRANCH=none
TEST=manual
Built everything, tested on Link. Tried various assertions.
Change-Id: I612891108ea37dbca3572e0f25ab54a7bc0ed860
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49417
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The power button code is platform-independent. This change splits the
code out of the LM4 switch.c module so that a subseqent change to
STM32 platforms can start using it.
BUG=chrome-os-partner:18945
BRANCH=none
TEST=manual
1. Power+refresh+esc goes to recovery mode,
2. Press power button at recovery screen turns off.
3. With system off, power button turns system on.
4. Press power button for a second; screen locks.
5. Press power button while typing; blocks keystrokes while it's pressed.
6. Hold power button down for 8 sec; system forced to shutdown.
7. From EC console, with system on:
hostevent clear
hostevent -> event 0x04 is clear
press power button
hostevent -> event 0x04 is set
8. From EC console, with system off:
powerbtn -> system turns on
powerbtn 5000 -> system turns off, just like power button was held for 5 sec
Change-Id: If2a9b02514a201e1d03c857d128e2ccab51a16ef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49217
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CPU creates an exception frame on the main stack instead of the process
stack when the exception happens in a handler's context. So, we need to
save both msp and psp, and pick the right one to locate the exception frame.
Tested by marking the stack (as you see in the dump below) then triggering
divzero in svc_handler.
> crash svc
=== HANDLER EXCEPTION: 03 ====== xPSR: 6100000b ===
r0 :00000000 r1 :0000e237 r2 :000015cf r3 :000015cf
r4 :00000001 r5 :22222222 r6 :11111111 r7 :0000df01
r8 :00000000 r9 :2000545e r10:00000000 r11:00000000
r12:0000000d sp :20000fb8 lr :000055d7 pc :00000b40
Divide by 0, Forced hard fault
mmfs = 2000000, shcsr = 70080, hfsr = 40000000, dfsr = 0
=========== Process Stack Contents ===========
20002738: 11111111 22222222 33333333 44444444
20002748: 00000000 000003ad 000003c0 81000000
20002758: 00000000 0000557d 0000557c 21000000
20002768: 00000000 00000000 00000000 00000000
Rebooting...
BUG=chrome-os-partner:16901
BRANCH=none
TEST=mentioned above
Change-Id: I3ca08a1df20375953552b3dc926350e262b78b2a
Signed-off-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47495
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This changes current TASK() syntax to TASK_BASE() and TASK_NORMAL(),
where TASK_BASE is necessary for the EC to boot on a board and
TASK_NORMAL represents the task that can be removed in a test binary.
Tasks introduced by a test should be listed as TASK_TEST().
Note that this CL breaks current tests (many of them are broken anyway),
which will be fixed in up coming CLs.
BUG=chrome-os-partner:18598
TEST=Build link/bds/spring/snow/daisy/mccroskey. (mccroskey failed for
unrelated issue)
BRANCH=none
Change-Id: Ic645cdae0906ed21dc473553f1f43c2537ec4bb9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47531
1) Check vs. number of allowable deferred function calls is made at
link time.
2) Added a check for whether hook_call_deferred() has been made after
the start of calculating the time when the hook task should wake. If
it has, go back and recalculate the wake time. This works around a
race condition.
BUG=chrome-os-partner:18473
BRANCH=none
TEST=add a bunch of deferrable functions and recompile; generates a link error
Change-Id: Ie833e2a699c47b6702957ed67bf7d3925f2df099
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47266
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a cleaner way of deferring work from interrupt-time to
task-time without requiring a task for each module which needs this.
Replaces/supersedes delayed hook notification, which didn't scale well
(since every function would have needed to be its own hook type).
BUG=chrome-os-partner:18473
BRANCH=none
TEST=boot system. plug/unplug AC power; notifies the host properly
Change-Id: I50263fe1ce37e74c1ef8db3671379098997102ed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46953
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And tidy a few comments. No code changes, only comments and whitespace.
BUG=none
BRANCH=none
TEST=compile code (nothing to test)
Change-Id: I10faadc4f11147984cb911c4e630d05ac594cc56
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39796
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If interrupts are disabled and the deadline is across a 32-bit timer
boundary from the current time, udelay() can lock up. The fix is to
do 32-bit math directly in udelay().
BUG=chrome-os-partner:16472
BRANCH=link
TEST=manual
waitms 1 -> prompt returns almost instantly
waitms 500 -> prompt returns after 0.5 sec
waitms 1000 -> watchdog error printed, then prompt returns
waitms 2000 -> watchdog reboot
Change-Id: Ib8ca06cee414d48900c0142e629daa68aa0993c9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/38924
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The behavior of GCC seems to have changed between 4.6 and 4.7,
now it might generate unaligned memory accesses, so we need to
explicitly set "-mno-unaligned-access".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:16391
TEST=make BOARD=link dis, then check the generated assembly for
keyboard_scan_init
Change-Id: I326479a77d6319f1d74e17efe483f5cde56ff325
Reviewed-on: https://gerrit.chromium.org/gerrit/38758
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
PWM and temp sensor monitoring want to happen every second,
vs. several times a second for watchdog and LPC.
This is still considerably simpler than having tick functions declare
an interval at which they want to be called, which would require a
RAM-based array of pending tick functions and alarm times. If you
need that level of complexity, you still need a task.
BUG=chrome-os-partner:15714
BRANCH=none
TEST=temporarily add HOOK_TICK and HOOK_SECOND hooks and see that on
LM4, HOOK_TICK is called 4x a second and HOOK_SECOND is called every
second.
Change-Id: I5c09842fd356d3254021486949b2799142068b4f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36938
Commit-Ready: Simon Glass <sjg@chromium.org>
Adds a new HOOK_TICK event which is called every 250ms (LM4) or 500ms
(STM32). This will be used to consolidate a number of tasks which do
small amounts of work infrequently, and previously needed their own
task functions.
This CL adds the tick task; subsequent CLs will consolidate watchdog
and other tasks into tick hooks.
BUG=chrome-os-partner:15714
BRANCH=none
TEST=taskinfo shows TICK task as lowest priority
Change-Id: I9068ee99d56a5bf5c12afd86ad51998c013f4954
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36908
Reviewed-by: Simon Glass <sjg@chromium.org>
We'd defined them in a number of different files. This moves
definitions to timer.h, and uses them everywhere we have large delays
(since 10*SECOND is less typo-prone than 10000000).
Also add msleep() and sleep() inline functions. No need for mdelay()
or delay(), since any delays that long should use sleep funcs instead
of spin-waiting.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=boot system; taskinfo displays similar numbers to before
Change-Id: I2a92a9f10f46b6b7b6571759b1f8ab4ecfbf8259
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36726
