hwtimer ticks at 8 * 32768 Hz rather than 250 KHz, so adjust our timing
appropriately. Also ensure that udelay() will delay for at least the
requested time, taking into account our timer precision.
BUG=b:63858553
TEST=Generate square wave with 1000us udelay between GPIO edge toggle,
verify period is 1000us + code overhead. Also verify timer behavior on
overflow with 'forcetime' command. Also verify accuracy of system clock
to 0.2% with `timerinfo` and a stopwatch.
BRANCH=None
Change-Id: I5da41bd7250db87de5143cc54ebd0bb750fb7003
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578551
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The jittery clock and trng security features require high permissions to
be initialized. In the future these initializations and the permission
level drop may be moved to RO.
This change adds permission level checks before trying to access any
registers that require high permission, so when we update RO to change
the permission RW can still function fine.
BUG=chrome-os-partner:59107
BRANCH=none
TEST=Move the permission drop to the beginning of main and verify the
system still boots.
Change-Id: I5b7cb856decd0640288ad3476f875ec9edc42635
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405840
The high speed clock does not run when cr50 is in sleep. The low speed
timers do run in sleep and deep sleep. This change modifies the hwtimer
to use the low speed timers instead of the high speed ones.
With this change the system timer frequency is reduced and will only
tick once every 4 mircoseconds. Now the system will resume from sleep
whenever an event is scheduled, but still wont resume from deep sleep.
BUG=chromium:635620
BRANCH=none
TEST=manual
Disable sleep
add a function that prints something every second.
Verify the rollover works at ~4295s.
Change the system time using force_time.
Re-enable sleep and reduce the sleep delays in
board/cr50/board.c and chip/g/idle.ci so cr50 will go to
sleep more quickly. Verify the rollover and changing system
time works.
check that cr50 can go into deep sleep and that the print
statement wont wake it up.
Put the system into deep sleep. Use a wake pin to make it
resume. Verify it can be put back into deep sleep without the
wakepin interrupt constantly triggering.
Change-Id: I70bbc9312cd172661de53334d256949ebab6b5e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376800
This fixes two race conditions that lead to a watchdog timeout:
1) ticks_to_usecs()
common/timer.c:process_timers() wraps its body in a
"while (next.val <= get_time().val)" loop meant to ensure that
it never returns after having scheduled an expired timer
(to address potential __hw_clock_event_set() overflows/underflows).
However get_time() through __hw_clock_source_read() calls ticks_to_usecs()
which "expands" the hw_rollover_count by a truncated clock_div_factor which
causes that loop condition to observe a "current time" that is up to ~15us
in the past (assuming a 24MHz clock). This race arises frequently with
workloads that repeatedly sleep for a short duration.
2) __hw_clock_event_irq()
The HW timer rollover interrupt was configured to be higher priority than
the event timer interrupt (i.e. it can preempt it) which is problematic if:
- There is a scheduled deadline soon after a "clksrc_high / .le.hi" boundary
- An earlier (before the clksrc_high rollover) event timer interrupt kicks in
- After the event timer interrupt handler gets to "now = get_time()"
in common/timer.c:process_timers() the rollover interrupt triggers
incrementing clksrc_high (i.e. the overflow case)
- The rollover interrupt handler arms the event timer to trigger at
that deadline (mentioned in the first bullet) and returns
- The original event timer interrupt handler resumes execution but finds
no events to schedule since the "timer_deadline[tskid].le.hi == now.le.hi"
clause won't evaluate to true. It will then call __hw_clock_event_clear()
before returning causing a watchdog timeout
This commit also contains a fix to properly initialize the HW timer
after a sysjump.
BRANCH=none
BUG=none
TEST=Reproduced both races and successfully tested the fix. The workload I was
using to reproduce (typically within an hour) has been running smoothly
for the past 24 hours.
Change-Id: Ic0b0958e66e701b52481fcfe506745ca1c892dd1
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347465
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The new register definitions file has been supplied, it is not
defining some fields which were present only in FPGA. Some tweaks are
required to accommodate this.
BRANCH=none
BUG=chrome-os-partner:50141
TEST=new code successfully boots on the evaluation board
Change-Id: Ie4158554e0aaf039d59669558861a763a23f0ceb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326803
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This commit updates the cr50 watchdog and hwtimer drivers to use the
hardware header specified regdefs to determine the frequencies for
the cr50 device.
BRANCH=None
TEST=Verified gettime and watchdog behavior on cr51
BUG=chrome-os-partner:46737
Change-Id: Iec7dc56b160dbec1b71077cecfd5561436d6f3ab
Signed-off-by: Ewout van Bekkum <ewout@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/321867
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We were losing timer events because usecs_to_ticks(deadline) was
clipping the value when deadline was larger than 0x08888888 (deadline is
a timestamp rather than a delay).
The computation of the timer deadline has been modified to avoid the
clipping issue.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:34347
TEST=run on Cr50 with the watchdog activated and no longer see watchdog
warnings.
Run the "timer_calib" test and see that the 1s sleep is 1000038 us :
make BOARD=cr50 tests
fhl ../build/cr50/timer_calib/timer_calib.RO.hex
Change-Id: Id2200a89eb1b72099e536291af321609b24b4777
Reviewed-on: https://chromium-review.googlesource.com/233531
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This is fairly large change set to accomodate a new hardware
release. There are enough differences to require refactoring the
registers.h file. Autogenerated constants are now in gc_regdefs.h
and all constant names begin with GC_, while register names are
defined in registers.h and begin with GR_.
Yes, I know the new header files are wider than 80 chars, but we
agreed that was okay in some cases if it makes them more readable
(see commit 3500c28).
BUG=chrome-os-partner:33423
BRANCH=none
TEST=make buildall -j
Build and run on the development board.
Change-Id: I21bd88c490f4f359ad17b5af9d17d8caca8dc9e4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230513
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Implement the API expected by common/timer.c
BUG=chrome-os-partner:33699
BRANCH=none
TEST=manual
Run the "gettime" and "timerinfo" and "taskinfo" and "waitms"
commands. Compare the elapsed time with the real world. They seem
to match.
Change-Id: Ie5acae76780ee09e7dfb6cc0282de25f8063e96f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229642
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The serial console works. Nothing else is implemented yet.
BUG=none
BRANCH=ToT
TEST=make buildall -j
To build,
make BOARD=cr50 hex
Testing the result requires a development board. I have one. It
works with HW revision m3.dist_20140918_094011
Change-Id: I718d93572d315d13e96ef6f296c3c2796e928e66
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226268
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
