Do not allow rescheduling tasks if task_start() has not been called.
This fixes a bug in which if console input occurs between uart_init()
and task_start(), the MCU crashes because uart_init() enables uart
interrupts which attempts to wake up the console task when RX data
is received, which then tries to task switch before we initialized
task scheduling.
BUG=chrome-os-partner:32561
BRANCH=samus
TEST=add while(1) loop to adc_init() to simulate stalled ADC
initialization. When stalled, send console character and observe
that without this CL MCU crashes, and with this CL the MCU does
not crash.
Change-Id: I34418e88ebe0063acf1cc55ab5a57b5fddcd9d23
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221599
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>
The Zinger RW is now signed with 2048-bit RSA key (using SHA-256 as
digest).
This CL implements the verification mechanism.
note: the RSA key used for signing must be provided as a .pem file.
The path to .pem file must be provided in the PEM environment variable.
By default, it's using the dev key stored in zinger_dev_key.pem.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:28336
TEST=on Zinger, run with properly signed RW firmware and corrupted
firmware and check the serial traces.
Change-Id: Ia58482458904a3ed72d6b0e95996cae86a0ead83
Reviewed-on: https://chromium-review.googlesource.com/220178
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
'powerindebug' is only used when there is a problem with power
sequencing. 'taskready' is rarely used and the same info can be
retrieved by 'taskinfo'.
Put both behind config flags and disable 'taskready' by default. Also
disable 'powerindebug' for Ryu.
BUG=chrome-os-partner:32203
TEST=Build Ryu and check flash space used.
BRANCH=None
Change-Id: I753a1f5411d6e840a80aba03afc94f9640d381a8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219490
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, on stm32f cortex-m0 systems, interrupts are always being
directed to the RO vector table. This can cause strange problems when
running RW software because it is still calling IRQ handlers in the RO
code.
Unfortunately, on cortex-m0 the ability to specify the vector table
location in flash (VTOR register) is optional, and stm32f0 parts do not
have it. Instead, in order to run RW IRQ handlers, at init time, this
CL copies the vector table from flash to the base address of SRAM
(0x20000000), and then selects SRAM to be mapped to 0x00000000 where
the core looks to find the vector table.
BUG=none
BRANCH=none
TEST=Tested on zinger.
- Verified that vector table is copied to SRAM by printing out 48 words
from SRAM base address 0x20000000 in main() and verifying that it matches
the vector table in flash in the disassembly.
- Verified the vector table at SRAM 0x20000000 points to the RW handlers
when in RW and the RO handlers when in RO.
- Also printed out PC in one IRQ handler and verified it was in the
appropriate section of code.
Also, ran on samus_pd and did a sysjump RW to make sure at least one other
system works.
Change-Id: I22aff1b5e0de9b23fd3324f0cbe4f6c45a81967e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Import code to do 64-bit multiplication on Cortex-M0 core without SMULL
instruction.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
add a 64-bit multiplication and see it compiled properly.
verify in .map files that the code is discarded for cortex-M0 based
platforms not using the 64-bit multiplication.
Change-Id: I0a91b3502f4bee4bb79b193fe0854e56a7d498f7
Reviewed-on: https://chromium-review.googlesource.com/207132
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
On panic, reboot properly the CPU rather than just jumping to the reset
vector as that might lead to some incorrect initializations.
Properly plug the div by 0 to the panic handling.
Add a small trace if the debug output is activated.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29840
TEST=add adhoc code triggering a data abort and see the firmware
printing a trace, then rebooting immediatly in a working state.
Change-Id: I1d5a98d9113c8ae08e05588a40f941d1ed22cebe
Reviewed-on: https://chromium-review.googlesource.com/206268
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is another patch to fix the bug which causes a HardFault exception
at the "svc" instruction in __wait_evt().
The HardFault is due to a priority escalation problem in which "svc"
is called when the PRIMASK is high, meaning interrupts are disabled.
The issue was that an interrupt can occur just before the "svc"
instruction, and when an interrupt fires that performs a context switch,
the IRQ handler disables interrupts setting the PRIMASK reg high.
The arm v6 reference manual specifies that "PRIMASK unchanged on
exception exit". So, therefore, we must clear PRIMASK by running "cpsie"
before exiting IRQ handler.
BRANCH=none
BUG=chrome-os-partner:28296
TEST=
Reproduce the problem on a fruitpie by inserting dummy for loop in
__wait_evt() before "svc" call:
asm volatile("isb");
for (i = 0; i < 250; i++) ;
__schedule(1, resched);
Then, when running pd dev, the system gets the HardFault exception
within a few minutes because there is more time for an interrupt
to occur and disable interrupts right before call to "svc".
After applying this patch, the code has run for > 3 hours without
a HardFault.
Change-Id: Ic50252b09c40c7d76975ff7f16d799c9eae2bde6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197839
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
From time to time (usually under heavy interrupt load), the runtime on
Cortex-M0 was panic'ing at the "svc" instruction with a HardFault
exception (inside the wait_event() function).
The issue was probably the following :
the wait_event() code is doing an atomic_read_clear() whose critical
section disables interrupts and re-enables them using "cpsie i",
then do __schedule() call which is essentially a "svc" instruction.
According to ARMv6-m reference manual :
"If execution of a CPS instruction:
increases the execution priority, the CPS execution serializes that
change to the instruction stream.
decreases the execution priority, the architecture guarantees only that
the new priority is visible to instructions executed after either executing
an ISB instruction, or performing an exception entry or exception
return."
So, when we are executing the "svc", PRIMASK.PM can still be seen as 1
(while it was set to 0 by "cpsie i") and in that case the software
interrupt is replaced by a HardFault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=run Firefly board under load for extended periods of time.
Change-Id: Ie355c36f06e6fe2fee5cca8998a469fa096badad
Reviewed-on: https://chromium-review.googlesource.com/196659
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@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 can be helpful when debugging "Imprecise" data bus errors.
BUG=None
BRANCH=None
TEST=Write to a memory-mapped register such as LM4_ADC_ADCISC
for a hardware block that is powered down.
Check the exception trace for a "Precise" error.
Change-Id: Ia246c3661b482e212bb0ce37b9c2d383021de639
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191392
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>
Some section(entry point, interrupt vector, e-flash signature
and so on) of linker script file are not linked.
The start address of e-flash signature should always at 00000080h.
Default firmware treats VCC logic high to prevent pin 11 logic low
but use following functions.
(EC2I, KBC, SWUC, PMC, CIR, SSPI, UART, BRAM, and PECI)
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=Firmware can startup on IT8380 emulation board.
Change-Id: I9860ac5b99dcc6e9e00dbc9d1e79a141237b7789
Reviewed-on: https://chromium-review.googlesource.com/190008
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Dino Li <dino.li@ite.com.tw>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Put each functions in a separate section by using -ffunction-sections,
then discard the non-referenced ones in the linker with -gc-sections.
Force keeping a few special symbols by using the KEEP() linker
directive.
This modification is not saving a lot of spaces per se, but will enable
larger code pruning with future optional features.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall, manually check discarded symbols in the .map file
and run on Spring and Link.
The size delta is the following:
Link: total 85.7k -> 84.9k (.text 60.3k -> 59.5k)
Spring: total 59.2k -> 57.2k (.text 44.4k -> 42.5k)
Change-Id: Ib6eb0d3f2cc4fc172c9fc26acac2e486921690a3
Reviewed-on: https://chromium-review.googlesource.com/189224
Reviewed-by: Randall Spangler <rspangler@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>
Move the CLZ instruction emulation C code to the common directory, so it
can be reused for all CPU cores missing a CLZ instruction (e.g. CortexM0).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board with Cortex-M0 core,
and pass all available unit-tests on target.
Change-Id: Ief56cac7430fcb0fbced8a8925250c89cbd0bcfc
Reviewed-on: https://chromium-review.googlesource.com/188981
Reviewed-by: Alec Berg <alecaberg@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
If the task scheduler hasn't started yet, use udelay() for any call to
usleep(). This is what we do for real core now.
BUG=chrome-os-partner:19235
TEST=Call usleep() in init hook
BRANCH=None
Change-Id: Ia5d14ee165ab25bfa231497af1aa8c87fbc324f0
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183271
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Pthread document explicitly stated that == operator should not be used
to compare thread IDs. Let's use pthread_equal() to be safe.
BUG=chrome-os-partner:19235
TEST=Check trace dump can be generated from non-main thread
BRANCH=None
Change-Id: I5011e0e380db0ce43c4fcf8fca0d94d5b3108f55
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This prevents an interrupt from being triggered when we happen to be
enabling/disabling global interrupt.
BUG=chrome-os-partner:19235
TEST=Repeatedly run interrupt test
BRANCH=None
Change-Id: I0163aff801ddbcee4aedba7a78966d97336c79ca
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181920
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Emulator test failures are sometimes hard to debug, especially when the
test is stuck somewhere and times out. Let's have the emulator dump
stack trace when an assertion fails or a test times out.
The produced stack trace is in this format:
#0 build/host/kb_8042/kb_8042.exe() [0x412421]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:104
#1 build/host/kb_8042/kb_8042.exe() [0x4124a9]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:129
#2 build/host/kb_8042/kb_8042.exe(run_test+0x3a) [0x412e2c]
/home/victoryang/trunk/src/platform/ec/test/kb_8042.c:262
#3 build/host/kb_8042/kb_8042.exe(_run_test+0x11) [0x4061de]
/home/victoryang/trunk/src/platform/ec/core/host/task.c:90
#4 build/host/kb_8042/kb_8042.exe(_task_start_impl+0x79) [0x406b72]
/home/victoryang/trunk/src/platform/ec/core/host/task.c:408
#5 /lib64/libpthread.so.0(+0x70b1) [0x7f6dc2fa10b1]
??:0
#6 /lib64/libc.so.6(clone+0x6d) [0x7f6dc2cd8efd]
??:0
The file name and line number in the trace is generated by addr2line.
BUG=chrome-os-partner:19235 chromium:331548
TEST=Put in a infinite loop in a test, and see stack trace when it times
out.
TEST=Add a failing assertion, and see stack trace when it fails.
BRANCH=None
Change-Id: I4494ffd1ebc98081ce40e860a146202084aa2a1e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181730
Currently emulator UART input/output are processed in various context,
including UART thread, individual tasks, and tests. By moving the
processing to interrupt context, the way it works resemble real chips
more. Also, this provides a cleaner cut between emulated UART device and
UART processing code.
BUG=chrome-os-partner:23804
TEST=make buildall
BRANCH=None
Change-Id: I58127e66f4058a68d37be9029e9ddbbd798381c6
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181590
Reviewed-by: Vincent Palatin <vpalatin@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
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
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>
