When there is an interrupt event, N8 CPU will save PSW register to IPSW
register and clear GIE then jump to interrupt service routine. N8 will
restore PSW from IPSW after "iret" instruction (the above are purely
hardware mechanism).
Nested interrupt will occur if we set GIE again in interrupt context.
symptom:
power button pressed while LID open -> exception or unknown reset.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. Manually pressed power button x200.
2. Console "eflash" erase and write eflash OK.
Change-Id: Ic04a23d473ebc6417dffea814a27583cb8d63a1f
Reviewed-on: https://chromium-review.googlesource.com/289437
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
This commit changes the way in which tasks are started. Instead of
having all tasks marked as ready to run upon initialization, only the
hooks task is marked as ready to run. HOOK_INITs are now run at the
beginning of the hooks task. After the HOOK_INITs, the hooks task calls
back to enable the rest of the tasks, reschedules, and proceeds as
usual. This also allows the removal of checks for task_start_called().
BUG=chrome-os-partner:27226
BRANCH=None
TEST=Built and flash EC image for samus and verified that EC boot was
successful as well as AP boot. Additionally, verified that charging,
keyboard, tap-for-battery were all still functional.
TEST=make -j buildall tests
Change-Id: Iea53670222c803c2985e9c86c96974386888a4fe
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/283657
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
If 2 interrupts happen at the same time, there is a chance that the nested
interrupt will not call svc_handler when it needs to. In extreme cases this
could lead to tasks not getting woken up when they're supposed to and watchdog
resetting.
The reason stuff worked was because there were enough other interrupts
around to eventually call the scheduler and switch to the ready task.
This change modifies the interrupt calls to not call the scheduler directly
(because in nested interrupt situation this causes problems), but defer the
call to scheduling until after the irq finishes by triggering a low priority
interrupt which will for sure call svc_host at the end. The PendSV irq was
used for this purpose.
BUG=chrome-os-partner:36193
TEST=No more SPI errors caused by scheduler problems
TEST=usleeps now are more accurate, they're guaranteed to not take forever now
BRANCH=veyron
Change-Id: I42acde6b3eb7be2540a0de9a8562dee2ea2be7ab
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248902
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Fix potential junk at end of PD TX transmit by adding to the DMA
transmit complete interrupt a blocking wait for SPI to finish and
then immediately disable SPI clock. This means we block in an
interrupt function for approximately 45us at the end of every
transmit. But, this is the highest priority thing going on anyway.
Note, there is still a potential for junk if both ports are
transmitting at the same time and finish very close to the same time.
BUG=chrome-os-partner:34600
BRANCH=samus
TEST=load onto samus and test communications with zinger. tested
specifically with an old zinger CL,
https://chromium-review.googlesource.com/#/c/226118/11,
which watchdogs when samus has junk at end of transmit. Tested
without this CL and verified we could never successfully flash zinger
over PD due to this watchdog and verified on scope presence of junk.
Then tested with this change and was able to successfully flash
zinger using ectool on both ports in both polarities.
Change-Id: If0cd9ab0551d36a7d7dc10232b6476dd56735972
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239244
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We already have interrupt handlers for channel 4 to 7. We need channel 3
for the new Ryu boards. Add the handlers for channel 1 to 3. Also,
instead of copy-pasting interrupt handlers, define a macro and declare
interrupt handlers with it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Check PD communication on the new Ryu board (with other CLs to
enable the new boards.)
Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224175
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds back DECLARE_IRQ() support when building without common
runtime. With this, we can enable only a subset of IRQs and avoid
linking in other unused IRQ handlers.
Note that after this change, all boards without common runtime need to
have a ec.irqlist file.
BUG=None
TEST=Build Keyborg and check it still works.
TEST=make buildall
BRANCH=None
Change-Id: If68062a803b9a78f383027a1625cf99eb3370d3f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203264
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Without common runtime, we need to use IRQ_HANDLER to define IRQ
handlers. Previously IRQ_HANDLER is only implemented in irq_handler.h
which is not included by task.h when building without common runtime.
This causes problem when we want to use code that includes task.h and
uses IRQ. By adding IRQ_HANDLER to task.h, we don't need to include
irq_handler.h in any case, and thus avoid that problem.
BUG=None
TEST=make buildall
TEST=include task.h instead of irq_handler.h. Check Keyborg still
builds.
BRANCH=None
Change-Id: I1213506132025fc656630565f58686b9e7de940c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203084
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added storing of FPU regs on context switches when CONFIG_FPU is defined.
On context switches, EXC_RETURN[4] is checked in order to tell which tasks
have used floating point and which have not. The FPU regs are only stored on
task stacks for tasks that use the floating point. Tasks that use floating
point will therefore require roughly an additional 128 bytes of stack space,
and context switches will take about 32 clock cycles longer for each task
involved in the switch that uses FP.
For tasks that don't use floating point, the stack usage actually decreases
by 64 bytes because previously we were reserving stack space for FPU regs
S0-S15 on every context switch for every task, even though we weren't doing
anything with them.
If a task only uses the FPU for a brief window, it can call
task_clear_fp_used() in order to clear the FP used bit so that context
switches using that task will not backup FP regs anymore.
BUG=chrome-os-partner:27971
BRANCH=none
TEST=Tested on glimmer and peppy. Added the following code, which uses the
FPU in both the hooks task and the console task. Note, I tested this for
a handful of registers, notably registers in the group s0-s15 which are
backed up by lazy stacking, and registers in the group s16-s31 which are
backed up manually.
float dummy = 2.0f;
static void hook_fpu(void)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.3f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Hook float 0x%08x\n", tmp.i);
/* write FP reg. */
tmp.i = 0x1234;
asm volatile("vmov s29, %0" : : "r"(tmp.f));
}
DECLARE_HOOK(HOOK_SECOND, hook_fpu, HOOK_PRIO_DEFAULT);
static int command_fpu_test(int argc, char **argv)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.7f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Console float 0x%08x\n", tmp.i);
if (argc == 2) {
char *e;
tmp.i = strtoi(argv[1], &e, 0);
if (*e)
return EC_ERROR_PARAM1;
/* write FP reg. */
asm volatile("vmov s29, %0" : : "r"(tmp.f));
} else {
task_clear_fp_used();
}
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(fputest, command_fpu_test, "", "", NULL);
When you call fputest 5 from EC console before this CL, then on the next
HOOK_SECOND, the value of register s29 is 5, instead of 0x1234 because
register s29 is not saved on context switches:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00000005
When this CL is in use, the register holds the correct value for each task:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00001234
> fputest
Console float 0x00000005
Hook float 0x00001234
Change-Id: Ifb1b5cbf1c6fc9193f165f8d69c96443b35bf981
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194949
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This prevents other task events from continuing the ADC
conversion prematurely; potentially leading to a panic
if the conversion interrupt occurs after the ADC has
been powered down.
BUG=chrome-os-partner:26919
BRANCH=rambi
TEST=Perform ADC conversions while running a deferred function
calling itself on a 10mSec delay. Verify no panics after ~6 hours.
Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to achieve really tiny firmwares, make our runtime (tasks,
hooks, muxed timers, GPIO abstraction ...) optional.
Add 2 new build options for it : CONFIG_COMMON_RUNTIME and
CONFIG_COMMON_GPIO which are enabled by default, and ensure all the
source files are built according to the right configuration variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
build a minimal board with no runtime.
Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f
Reviewed-on: https://chromium-review.googlesource.com/189403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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
To create a token by concatenating already-defined macros and new
text, it's necessary to use multiple levels of macro. We'd already
done that in several places in the code such as STM32_CAT; this now
standardizes it into a single place.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=Build all platforms; examine ec.RO.map to see that irq_*_handler and prio_* symbols
evaluated the same as before. (Other macro evaluations would simply fail to compile
if they were incorrect, since the concatenated tokens wouldn't fully expand.)
Change-Id: Ic9bf11d27881a84507fe7b6096dab6217c6c6dc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63231
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The time out value passed to task_wait_event() is signed 32-bit and
thus waiting for 24 hours will cause overflow. Limit max wait time.
BUG=chrome-os-partner:15797
BRANCH=link
TEST=Disconnect AC, shut down system, and close lid. From ec console,
do 'hibdelay 8000' and then wait 2.5 hours. EC should have
hibernated. (8000 is more than twice the max time for
task_wait_event())
Change-Id: I5fa505554182e8bad6399c12a382ff71bb123d8f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/37095
Reviewed-by: Vic Yang <victoryang@chromium.org>
This manifested as the lightbar task missing transitions between CPU states.
The underlying cause was that when a task talks over the I2C bus, the I2C
communication was using the task scheduler to wait for an interrupt to
signal completed I2C traffic without blocking the other threads, but while
doing so it was not preserving pending events. This CL seems to fix it.
BUG=chrome-os-partner:12431
BRANCH=all
TEST=manual
The original bug is tricky to reproduce without adding some delay to the I2C
task code, but you can do it. Boot the CPU, then from the EC console
repeatedly alternate these two commands:
lightbar seq s0
lightbar seq s3
You should see the lightbar pattern turn off and on, but occasionally you'll
type the command and the EC won't change the pattern.
With this change applied, it should *always* work.
Change-Id: Ie6819a4a36162a8760455c71c41ab8a468656af1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33805
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a precursor to supporting task-specific task sizes. I've
benchmarked this vs. the current stack pointer method; no measurable
performance difference.
BUG=chrome-os-partner:13814
TEST=boot EC; taskinfo; if it boots and doesn't print garbage, it worked
BRANCH=all
Change-Id: Ia326c3ab499ac03cce78dbacaa52f735601a171e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32603
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
...so I can use usleep() for eeprom delays in the CL coming next...
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:10200
TEST=if it boots, it worked
Change-Id: I564578f24452a4ac39abe79ff28cfff4b665ad2f
1) When frequency changes, reload the watchdog timer right away, or it
may expire before the next reload. (Only matters when re-enabling the
PLL.)
2) Split out the timer/task debug output used by the watchdog into
their own routines, instead of assuming it's safe to call the command
handlers. Also make the flushes in those print routines safe to call
from interrupt level.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=waitms 1500; should print task dump again
Change-Id: I07e0ed24a526ae499566dab0bbeb0f5755cd5be6
Also tracks the distribution of IRQs, so we can see what's triggering
interrupts.
Task profiling is optional, enabled via CONFIG_TASK_PROFILING.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7464
TEST=taskinfo
Change-Id: I266f2b49bff9648cda446210d5a302b460fec244
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8971
TEST=manual
waitms 1500
(see watchdog trace)
waitms 1500
(should see watchdog trace again)
waitms 3000
(should see trace, then system should reboot)
Change-Id: Ieb5009d7a7bc9e1ed795e58efb0cb44a1eeb2706
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7461
TEST=manual
make BOARD={bds,link,daisy}
make tests
flash link system and make sure it boots
Change-Id: I1241a1895c083e387e38ddab01ac346ca4474eb9
This is necessary at init-time for verified boot to jump from RO to
one of the RW images.
It's also used by factory EC update to update one image and then jump
to the updated image to finish the update. In this case, the x86 does
NOT reboot.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8449
TEST=manual
1) power on x86 and log in
2) sysjump a --> system is in a; x86 has not rebooted
3) sysjump ro --> system is back in RO; x86 has not rebooted
4) reboot -> system is in RO; x86 HAS rebooted
Change-Id: I9dbadcf9775e146a0718abfd4ee0758b65350a87
Implement enable_fpu() and disable_fpu().
enable_fpu() disables interrupt and then enables FPU.
disable_fpu() disables FPU and enables interrupt.
Also added a CONFIG_FPU flag.
BUG=chrome-os-partner:7920
TEST=none
Change-Id: I2d71f396d9c7d7ac4a6a2d525f3d86f8aae87521
Signed-off-by: Vic Yang <victoryang@chromium.org>
Expand the macros before building the priority variable name in order to
ensure we have a valid name.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=check manually preprocessor expansion for several combinations.
Change-Id: I926821d42c966ac674e7d24254c9f22779f93ca2
Preparatory work to introduce a second SoC : 1/5
Instead of putting hardcoded IRQ SoC name in the vector table,
upgrade the DECLARE_IRQ macro to expand its argument.
Also add a parameter to set the size of the NVIC table to save flash
memory.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=run EC on BDS and see timer IRQs firing.
Change-Id: I44fefdabdd37d756492a71f24554979c72c1b50f
They are designed to protect shared hardware resources (e.g. I2C
controller).
Please refrain using them as a general purpose synchronization primitive
for the tasks to avoid unintended slippery effects (e.g. priority inversion),
use the provided message-passing functions instead for that purpose.
The mutex variable (ie the "struct mutex") should be initially filled
with 0, but this is the default compiler behavior if you declare it as a
global variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=make qemu-tests
Change-Id: I328f7eadf5257560944dbbbeda0b99d5b24520e8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7456
TEST=if it runs, it works
Change-Id: Ib82afab7d53203af31eefc9887feb98679266ac1
The constants don't work with the DECLARE_IRQ() macro yet, because it
relies on stringizing the IRQ number.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=none
Change-Id: Ie6ddecd79e28c319b095089131579ba994a17da3
(cherry picked from commit e24904644a977f2618f51629cc066b93a3d53595)
