summaryrefslogtreecommitdiff
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
* CHERRY-PICK: MKBP event signalling implementationVic Yang2014-11-112-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | This implements a new API for EC modules to define MKBP event sources and send MKBP event to the AP. Also, a new host command EC_CMD_GET_NEXT_EVENT is added for the AP to query the pending MKBP events. Each event type may have custom event data sent along with the event. BRANCH=None BUG=chrome-os-partner:33194 TEST=Enable MKBP event on Ryu. Set a host event from EC console, run 'ectool nextevent', and see MKBP event 0x01 (HOST_EVENT) and the set host event. Change-Id: Ic3ceff8b5ff6f3d8df7b74b74d535112fe4c09fb Signed-off-by: Vic Yang <victoryang@chromium.org> Original-Change-Id: I28a1b7e826bcc102bbe39016c9bb3e37d125664c Reviewed-on: https://chromium-review.googlesource.com/224905 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/229107 Reviewed-by: Mohammed Habibulla <moch@chromium.org> Commit-Queue: Mohammed Habibulla <moch@chromium.org> Tested-by: Mohammed Habibulla <moch@chromium.org>
* CHERRY-PICK: Slow down time when running unit testsVic Yang2014-10-102-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ie890e16310197a46c9c0f0f81f73a1b307d9ecdc Original-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> Reviewed-on: https://chromium-review.googlesource.com/222870 Reviewed-by: Mohammed Habibulla <moch@chromium.org> Commit-Queue: Mohammed Habibulla <moch@chromium.org> Tested-by: Mohammed Habibulla <moch@chromium.org>
* Add options to disable rarely used console commandsVic Yang2014-09-242-0/+4
| | | | | | | | | | | | | | | | | | | '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>
* cortex-m0: stm32f0: use RW vector table when running RW codeAlec Berg2014-07-292-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: add 64-bit multiplicationVincent Palatin2014-07-102-1/+75
| | | | | | | | | | | | | | | | | | | | 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>
* better unhandled exception panic without runtimeVincent Palatin2014-07-033-8/+3
| | | | | | | | | | | | | | | | | | | | | | 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>
* stm32: add USB driverVincent Palatin2014-06-182-0/+40
| | | | | | | | | | | | | | | | | | 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>
* Add cprints() and ccprints()Vic Yang2014-05-214-6/+6
| | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: fix hard-faults during software interrupt calls part 2Alec Berg2014-05-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: fix hard-faults during software interrupt callsVincent Palatin2014-04-251-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m: store FPU regs on context switchAlec Berg2014-04-182-14/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m0: add more thumb1 helpersVincent Palatin2014-04-111-11/+53
| | | | | | | | | | | | | | | | Add other helpers for compact switch on ARMv6-M. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=none Change-Id: I711ee8361ff1545acd978974d9f9fc306ca43b78 Reviewed-on: https://chromium-review.googlesource.com/190711 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* cortex-m: Add task_wait_event_mask() helper functionChromeOS Developer2014-03-261-0/+29
| | | | | | | | | | | | | BUG=chrome-os-partner:27180 BRANCH=rambi TEST=Tested indirectly via subsequent patches to use this call in the adc and i2c handlers for the lm4. Change-Id: I53501fdf47d606ea6c7705facb66e945e25d9745 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191300 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cortex-m: Add debug config option for disabling buffered writesChromeOS Developer2014-03-261-0/+10
| | | | | | | | | | | | | | | 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>
* make the common runtime optionalVincent Palatin2014-03-226-4/+16
| | | | | | | | | | | | | | | | | | | | | 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>
* it8380dev: fix firmware can't startup (re-generate)Dino Li2014-03-182-4/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* discard unused functions at link timeVincent Palatin2014-03-113-63/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add Cortex-M0 core supportVincent Palatin2014-03-1114-0/+1734
| | | | | | | | | | | | | | | | | | The Cortex-M0 core is based on ARMv6-M instruction set rather than ARMv7-M as Cortex-M3 and M4. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=run console on STM32F072, and pass all available unit-tests on target. Change-Id: I9bdf6637132ba4a3e739d388580a72b4c84e930e Reviewed-on: https://chromium-review.googlesource.com/188982 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* force the compiler to use a valid register allocation for irq handlersVincent Palatin2014-03-113-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 CLZ emulation to common codeVincent Palatin2014-03-062-39/+5
| | | | | | | | | | | | | | | | | | | 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>
* emulator: Move trace dump to a separate moduleVic (Chun-Ju) Yang2014-01-226-85/+142
| | | | | | | | | | | | | | | 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
* emulator: Use udelay() for usleep() if task hasn't startedVic (Chun-Ju) Yang2014-01-211-0/+6
| | | | | | | | | | | | | | 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>
* Use pthread_equal() to compare thread IDVic (Chun-Ju) Yang2014-01-111-1/+1
| | | | | | | | | | | | | | 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>
* emulator: Guard interrupt status with mutex lockVic (Chun-Ju) Yang2014-01-081-2/+8
| | | | | | | | | | | | | | 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>
* Dump stack trace on emulator test failureVic (Chun-Ju) Yang2014-01-083-5/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Process emulator UART events in interrupt contextVic (Chun-Ju) Yang2014-01-061-0/+9
| | | | | | | | | | | | | | | | | 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>
* Add interrupt support for emulatorVic Yang2014-01-062-22/+171
| | | | | | | | | | | | | | | | | | 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
* cleanup: Remove checkpatch warningsRandall Spangler2013-12-193-21/+19
| | | | | | | | | | | | | | | | 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
* Protect inactive EC image from code executionDaisuke Nojiri2013-12-172-54/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change configures MPU to prevent instruction fetch from the flash image that is not running at the time system_disable_jump is called. Violating the protection causes instruction access violation, then the EC reboots. RO image protection is tested as follows: ... [6.255696 MPU type: 00000800] [6.255874 RAM locked. Exclusion 20005680-200056a0] [6.256168 RO image locked] ... > sysjump 0 Jumping to 0x00000000 === PROCESS EXCEPTION: 03 ====== xPSR: 60000000 === r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8 r4 :200032f0 r5 :00000000 r6 :20002b70 r7 :20002df4 r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000 r12:00000002 sp :20002358 lr :0002a1a7 pc :00000000 Instruction access violation, Forced hard fault mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0 =========== Process Stack Contents =========== 200023c0: 00000098 00000000 00000000 0002a785 200023d0: 00000002 20002dfd 00000007 20002b70 200023e0: 00000002 00025777 00000000 20002dfd 200023f0: 20002df4 20002dfc 00000000 00000000 Rebooting... Memory management fault status register has bit0 set, indicating there was an instruction fetch volation. FYI, RAM protection is still working: > sysjump 0x20000000 Jumping to 0x20000000 === PROCESS EXCEPTION: 03 ====== xPSR: 60000000 === r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8 r4 :200032f0 r5 :20000000 r6 :20002b70 r7 :20002df4 r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000 r12:00000002 sp :20002358 lr :0002a1a7 pc :20000000 Instruction access violation, Forced hard fault mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0 =========== Process Stack Contents =========== 200023c0: 00000098 00000000 20000000 0002a785 200023d0: 00000002 20002e06 00000007 20002b70 200023e0: 00000002 00025777 00000000 20002e06 200023f0: 20002df4 20002dfc 00000000 00000000 Rebooting... TEST=Booted Peppy. Tested lid close & open. Ran Flashrom from userspace to update main firmware then software-synched an EC image. BUG=chrome-os-partner:16904 BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: Id4f84d24325566a9f648194166bde0d94d1124dc Reviewed-on: https://chromium-review.googlesource.com/169050 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Daisuke Nojiri <dnojiri@google.com> Tested-by: Daisuke Nojiri <dnojiri@google.com>
* nds32: WORKAROUND for toolchain bug on rodataVincent Palatin2013-12-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ite: Port OS layer to Andestar v3m architectureVincent Palatin2013-12-1011-0/+1310
| | | | | | | | | | | | | | | | | This will be used to support ITE IT8380 chip which contains an Andes N801 core. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=make BOARD=it8380dev Change-Id: I91f9380c51c7712aa6a6418223a11551ab0091ce Reviewed-on: https://chromium-review.googlesource.com/175480 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* extract common core codeVincent Palatin2013-12-053-466/+34
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add a BSS section for large alignmentVic (Chun-Ju) Yang2013-12-021-4/+9
| | | | | | | | | | | | | | | | | | 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>
* Remove the printf prompt in idle task.Louis Yung-Chieh Lo2013-11-131-7/+0
| | | | | | | | | | | | | | 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>
* Move core-specific toolchain configuration to core/ directoryVincent Palatin2013-11-073-2/+18
| | | | | | | | | | | | | | | | This is preparatory work to introduce a second core architecture. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=./util/make_all.sh Change-Id: Icae8a7e475a4ba2a13f0d8f95629e8498a5a61da Reviewed-on: https://chromium-review.googlesource.com/175419 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* Enable stack overflow checking on all context switchesRandall Spangler2013-11-072-3/+40
| | | | | | | | | | | | | | | | | | | | | | | | 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-m: ensure we use the right subset of the instruction setVincent Palatin2013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: Improve / remove more TODO commentsRandall Spangler2013-11-011-4/+9
| | | | | | | | | | | | | 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>
* cleanup: Use actual Thumb2 SVC instruction instead of hard-coding the opcodeRandall Spangler2013-11-011-6/+2
| | | | | | | | | | | | | | | 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
* Fake I2C device support for emulatorVic Yang2013-09-171-0/+20
| | | | | | | | | | | | | | | | | 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>
* Introducing MPU module for Cortex-M3Daisuke Nojiri2013-09-054-0/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preventing instruction fetch from RAM for Link except iram.text, which is used for hibernation. Stm32 on Snow does not support MPU. Tested on Link using commands 'crash nxtext/nxdata/nxstack', which run code from .iram.text, .data section, and the stack, respectively: ... RAM locked. Exclusion 20005980-200059a0 ... > crash nxtext Running from 20005984 > crash nxdata === PROCESS EXCEPTION: 04 ====== xPSR: 61000000 === r0 :00000000 r1 :0000dff2 r2 :00000005 r3 :0000086d r4 :00000000 r5 :00000032 r6 :2000544c r7 :00000000 r8 :00000000 r9 :20005456 r10:00000000 r11:00000000 r12:20005961 sp :20002748 lr :000008d7 pc :20005960 Instruction access violation mmfs = 1, shcsr = 70001, hfsr = 0, dfsr = 0 =========== Process Stack Contents =========== 200027b0: 0000086d 00000002 0000d504 00009f27 200027c0: 2000544c 20005452 00000000 00000000 200027d0: 00000000 00000000 00000000 00000000 200027e0: 00000000 00000000 00000000 00000cbb Rebooting... > crash nxstack === PROCESS EXCEPTION: 04 ====== xPSR: 20000200 === r0 :00000070 r1 :00000047 r2 :00000000 r3 :200027a8 r4 :00000000 r5 :00000001 r6 :2000544c r7 :00000000 r8 :00000000 r9 :20005456 r10:00000000 r11:00000000 r12:00000002 sp :20002740 lr :00000913 pc :200027ac Instruction access violation mmfs = 1, shcsr = 70001, hfsr = 0, dfsr = 0 =========== Process Stack Contents =========== 200027ac: 00000070 00000047 00000002 0000d57c 200027bc: 00009f9f 2000544c 20005452 00000000 200027cc: 00000000 00000000 00000000 00000000 200027dc: 00000000 00000000 00000000 00000000 Rebooting... BUG=chrome-os-partner:16904 BRANCH=master TEST=stated above Change-Id: I7c6593c527f29609442f33550f9d16755f32297c Signed-off-by: Daisuke Nojiri <dnojiri@google.com> Reviewed-on: https://chromium-review.googlesource.com/51337 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add boot key testVic Yang2013-09-051-0/+6
| | | | | | | | | | | | | 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
* Implement emulator clock fast-forwardingVic Yang2013-09-041-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* stm32l: Add a "PRE_FREQ_CHANGE" hook to allow other code to prepareDoug Anderson2013-08-292-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove unneeded includes of registers.hRandall Spangler2013-08-021-1/+0
| | | | | | | | | | | | | | | | | | | 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>
* Add hook for changes in the charge state machineDave Parker2013-08-012-0/+8
| | | | | | | | | | | BUG=chrome-os-partner:20145 BRANCH=falco,peppy TEST=Manual. Tested with charging timeout logic. Change-Id: Iab1c9746dcab5820fcdeb3e0d94bfcb0c47e57f2 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/63537 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Reboot emulator with execv()Vic Yang2013-07-241-1/+10
| | | | | | | | | | | | | | | | 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>
* Clean up debug config optionsRandall Spangler2013-07-232-9/+5
| | | | | | | | | | | | | | | | | 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>
* Fix reset flags and sysjump time for emulatorVic Yang2013-07-232-1/+24
| | | | | | | | | | | | | | | 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>
* Test sysjump tag in kb_8042 testVic Yang2013-07-232-7/+3
| | | | | | | | | | | | | This checks that keyboard state is preserved across system jump. BUG=chrome-os-partner:19236 TEST=Pass the test BRANCH=None Change-Id: I53c5bb68246fd117b351d89c3907daf028bc4ef3 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/62908 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status