This adds hibernation support. The chip can be waken by either GPIO or a
timer. The maximum delay allowed is ~2 hours.
BUG=chrome-os-partner:24107
TEST=hibernate and wake by GPIO
TEST=hibernate and wake by timer
BRANCH=None
Change-Id: I1e064638a5008894a002a06a738bf6104f18636d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181202
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We noticed this on a baytrail board, but the same problem exists in
haswell as well. And while looking there, found that we skipped the
S5G3 state if the 5V rail failed to come up.
Fortunately, these are all rare corner cases; rails will always come
up on a good system. So this only affects systems during bringup and
factory, not devices in the field.
BUG=chrome-os-partner:24915
BRANCH=rambi (and technically haswell, but may not be worth merging)
TEST=Try booting a system with a bad power rail; see that SUSP_VR_EN=0
after the system fails to boot.
Change-Id: Ifd10841d298a0f2510a8b182250b717ea5643c99
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183733
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The PCH uses a 16 ms debounce, so need to assert the signal for twice
that to be assured of a reboot.
BUG=chrome-os-partner:25088
BRANCH=rambi
TEST=Alt+VolUp+R reboots the system
Change-Id: I51fd54fd992e4e54e6c3bc9c13f9fd59e9bf55ac
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183726
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Previously, the 5V rail was disabled unconditionally in the S0->S3
transition. Now, the rail is left powered if one or both of the USB
ports are powered.
BUG=chrome-os-partner:25178
BRANCH=rambi
TEST=Modify the OS to leave USB ports powered in S3. Then suspend. On
the EC console, 'gpioget pp5000_en' should be 1.
Change-Id: I3c73f3fe228e940317c0da7330f117c7ab0a6d0c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183548
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@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>
For the better naming for power/common.h, we rename CONFIG_CHIPSET_X86
to CONFIG_POWER_COMMON (no one is actually using it). But keep
CONFIG_CHIPSER_TEGRA for power/build.mk.
BUG=chrome-os-partner:25068
BRANCH=nyan,falco,link,peppy,rambi,samus,squawks
TEST=build only
Change-Id: Ibf1a4c24088dfddac39b38a95b3b887c195152d5
Signed-off-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182732
Some WiFi devices do not tolerate losing power in suspend
and will not function properly after resume if they have
lost power.
Enable this on the Rambi device.
BUG=chrome-os-partner:24114
BRANCH=baytrail
TEST=complete mutiple successful suspend/resume cycles on rambi
and ensure that wifi continues to function and not cause a crash.
Change-Id: Id421f3138e429b247bfb3f5ffb92a06c0353bb97
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183047
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Integrate with power/common.c -- a real state machine now. Also remove
duplicate and unused functions/consts.
BUG=chrome-os-partner:24831
BRANCH=nyan
TEST=on nyan rev 3.12.
re-plug AC: PASS, power on 2
reboot: PASS, power on 2
power off (S5), power on: PASS, power off 4, power on 5
power off (G3), power on: PASS, power off 4, power on 5
lid close / power off (S5)/ lid open: PASS, power on 3
lid close / power off (G3)/ lid open: PASS, power on 3
press power button and release: nothing happens after 15s.
button off (S5)/ on: PASS, power off 3, power on 4
button off (G3)/ on: PASS, power off 3, power on 4
power off (S5)/ button on: PASS, power off 4, power on 4
power off (G3)/ button on: PASS, power off 4, power on 4
button off (S5)/ power on: PASS, power off 3, power on 5
button off (G3)/ power on: PASS, power off 3, power on 4
button off (S5)/ lid open: PASS, power off 3, power on 3
button off (G3)/ lid open: PASS, power off 3, power on 3
is off, long press button (60s): power on 4, too long, shutdown, stay off
is on, long press button (60s): power off 3, stay off
apreset cold: entered to S5, power off 3, power on 5
apreset warm: power state is not changed, but reboots to BIOS.
Change-Id: Ie12fa4f79b6156f71f89155b2b01880914809c75
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182348
Reviewed-by: Randall Spangler <rspangler@chromium.org>
LPC mapped memory is not supported for MEC1322. We'll need a separate
communication module. Update comment to reflect this.
BUG=chrome-os-partner:24280
TEST=None
BRANCH=None
Change-Id: I1863c7c230f895cb2cef65459406ffcf1e2b515d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182798
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The main bottleneck on current LPC transfer speed is the delay required
between address write and data read/write. Using auto-increment mode, we
can not only skip most of the delay but also skip repeated address
write.
This gives about 30x speed-up (comparing the time spent on 4096-byte
read test.)
BUG=chrome-os-partner:24107
TEST=Measure speed of 'ectool readtest'
BRANCH=None
Change-Id: Ib34661474b149b19a900c60db884bd474881f742
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182797
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EMI module is the only LPC module suitable for port 80 implementation,
and thus let's move it to 0x80. Consequently the EMI mapped memory is
moved to 0x82-0x87.
BUG=chrome-os-partner:24107
TEST=Write to port 80 and see the data printed to console
BRANCH=None
Change-Id: I7d749650d6d109af2941a1db6e6c4a32e7482f61
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182796
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EMI module has the ability to set different read and write ranges. Let's
disable write on mapped memory.
BUG=chrome-os-partner:24107
TEST=Write to mapped memory has no effect
BRANCH=None
Change-Id: I88654bde9208376103d3c084ee54991d886ea4cc
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182795
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:25031
BRANCH=rambi
TEST=Manually
make BOARD=peppy
make BOARD=falco
make BOARD=rambi
make BOARD=squawks
On rambi and squawks, connect charger
ectool chargecontrol discharge
ectool i2cread 16 0 0x16 0x0a
It should return 16-bit negative integer.
Change-Id: I8a8dfa90d2ad82595ac7a420c3c8ffc13b12cde6
Signed-off-by: Justin Chuang <jchuang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182586
Reviewed-by: Dave Parker <dparker@chromium.org>
This significantly decreases the task swapping overhead when doing
many transfers.
Also fix a bug where on error, i2c_xfer() would issue a stop
condition, but not actually wait for it to complete before returning;
this could interfere with the next transfer in a back-to-back
scenario.
BUG=chrome-os-partner:25015
BRANCH=lm4 (more specifically, rambi and derivatives)
TEST=battery command should show the same info as before
i2cscan should show devices at bus 0 0x12, 0x16, bus 5 0x98
no charger errors on boot
Change-Id: I2195f0f9800b03a54fa33170dbae6705382578c7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182503
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
This includes:
- Remove an unused function argument
- Style fix
- Handle EOF by pexpect instead of catching exception
BUG=chrome-os-partner:19235
TEST=Run all tests
TEST=Make a test crash and check EOF is handled properly
BRANCH=None
Change-Id: I3636cdab6e68cacf97c4b245b14b2d57613a1674
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182049
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Watchdog module added. Off by default because of following limitations:
- When programming, the WD fires, and programming fails. For now, you
have to program twice.
BRANCH=none
BUG=chrome-os-partner:23575
TEST=Manually wrote in a while(1); and made sure watchdog warning
triggers first, prints IPC register, and then soon after the watchdog
timer resets the chip.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: Ia83f58f3ae108f755d2f139ada22a22e2fbdc2fa
Reviewed-on: https://chromium-review.googlesource.com/177397
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added system reset and reset causes for ITE chip. The only reset
causes available on this chip are watchdog reset or power on reset.
BRANCH=none
BUG=none
TEST=Used reboot console command with various args and verified reset
cause was recorded correctly on next boot.
Change-Id: Ie65f1e8f2b98c1e614b5c1d8bcbe9b3000ed9590
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179539
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change rambi LED id to battery and fix led command.
BUG=chrome-os-partner:24980
BRANCH=None
TEST=Manually,
ectool led power query => error
ectool led battery query => success
ectool led red => red
ectool led green => green
ectool led off => off
ectool led auto => default behavior
Change-Id: I151d63a010434ae8cd21b0ae0d935bb9d8c084c7
Signed-off-by: Justin Chuang <jchuang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182275
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
F13 is used to trigger the lock/password screen
for users logged into Chromium OS. F13 is already
used for this purpose on the USB Chrome keyboard.
BUG=chrome-os-partner:24376
BRANCH=clapper,glimmer
TEST=Run "kbpress 9 3 1" to simulate keypress.
Verify lock screen is entered in Chromium OS.
Set1:
Run evtest. Verify KEY_F13 scan code, value=5d
Set2:
Add kernel parameter "i8042.direct=1" to use RAW mode.
Run evtest. Verify KEY_F13 scan code, value=2f
Change-Id: I71200810681f683c17e30b383e1221784deae0cd
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182289
From DV2 board of pit, we'll use 3 color-LED instead of power LED on keyboard.
So, we have to remove pwm and power_led task from pit branch.
BUG=chrome-os-partner:24855
TEST=Tested on the pi and pit board about all power status.
BRANCH=pit
Change-Id: I875567d8f7d544cb5b9d6057b94c26d1989b0c67
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/181607
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@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>
The VBAT POR indication is unreliable for detecting a power-on reset,
and thus we often see "unknown" reset cause when we should see
"power-on". A better indication is to check for VCC1 POR, which
manifests by clearing watchdog count. The catch is that we still cannot
tell power-on reset from reset-pin reset.
Also, to distinguish soft/hard reset from actual watchdog reset, we need
to explicitly save soft/hard reset flag before triggering watchdog
reset.
BUG=chrome-os-partner:24107
TEST=Power cycle EVB and see 'power-on' reset cause.
TEST='reboot' and see 'soft' reset cause.
TEST='reboot hard' and see 'hard' reset cause.
TEST='waitms 2000' and see 'watchdog' reset cause.
BRANCH=None
Change-Id: I0075f5bf5cdb032d206c4a53c586b75b69093235
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182120
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Settings in test_config.h should only be applied #ifdef TEST_BUILD.
This fixes omitting vboot hash all time. It should only be omitted
for test builds.
BUG=chrome-os-partner:24892
BRANCH=all
TEST=boot system; 'hash' command works on EC and system is not stuck in
recovery mode.
Change-Id: I15f645824382e25caef9c1c045bb079f374fbb88
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The DPTF framework will sometimes set thresholds and not expect
to get another event if the current temperature is above both the
previous threshold and the new threshold.
When a threshold is set only initialize the over condition if the
threshold was previously disabled in order to prevent it from
firing again.
BUG=chrome-os-partner:23970
BRANCH=rambi
TEST=build and boot on rambi, start DPTF framework and observe
that when a threshold is crossed (going high) and a new threshold
is set at a lower value that it does not immediately result in a
new event.
Change-Id: I6bad956fb5a49027a5c5f9c49a6fd68a0a96d693
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182004
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds golden wake count for each task and check at the end of the
test. The golden wake count is calculated with the seeds and the pseudo
random number generator.
BUG=chrome-os-partner:23800
TEST=Pass the test
BRANCH=None
Change-Id: I7e90336b3f0b0355795ada7baf7c052a047ee302
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of requiring a GPIO definition, default to using the internal
SCI pin control.
BUG=chrome-os-partner:24550
TEST=Trigger SCI and verify with logic analyzer
BRANCH=None
Change-Id: I13ac3b8f1031d3c56ea0b8f6a6ed0c1aa4e77bb1
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182010
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
The external pull-up resistors are too weak, and cause slow-down on I2C
speed. Let's enable internal pull-up to compensate this.
BUG=chrome-os-partner:24389
TEST=Measure I2C speed with scope, and see better slew rate.
BRANCH=None
Change-Id: Iefb5fca3c88250bbd8cad29d7998d590a7cc7c35
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181999
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Now that we handle all UART input from interrupt context, we shouldn't
need to guard input buffer with mutex lock. Removing the stale TODO
comment and adding an assertion to ensure this argument is correct.
BUG=chrome-os-partner:23804
TEST=make buildall
BRANCH=None
Change-Id: If61eed4329a782b80fe8b16667bddaae8464620d
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181722
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
State machines implemented using deferred functions need to be able to
kick off deferred function from a HOOK_INIT handler. But tasks aren't
running in HOOK_INIT, so task_wake() fails.
Instead, hook_call_deferred() should check to see if the hook task has
had a chance to run yet. If it hasn't, then there's no need to wake
it; it'll get run eventually anyway.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Add a call to hook_call_deferred() in a HOOK_INIT handler. It shouldn't
crash, and the deferred function should be called.
Change-Id: I5c8077b636ae030a668a211fd8238549b6bcfa54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181953
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Unexpected EOF usually means error in the test code or assertion
failure. In this case, let's treat it as test failure.
BUG=chrome-os-partner:19235
TEST=Check assertion failure fails the test.
BRANCH=None
Change-Id: I9270d223d7252f611673a2c55af0c2d68b6116c4
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181747
The variable 'interval' is declared as unsigned integer, and this
sometimes causes an integer underflow when substracting it by SECOND,
and in turns leads to false test failure. Changing it to signed integer.
BUG=chrome-os-partner:19236
TEST=Repeatedly run hooks test
BRANCH=None
Change-Id: Ic6d8001f90fb8756b6bdadf811a668c02fbccb34
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181882
Reviewed-by: Vincent Palatin <vpalatin@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
On the IT8380, we should be able to map 16kB of SRAM to use as data
memory (aka DLM), but sometimes the 2 top 4k pages seem to be
mapped differently (ie not to SRAM, they do not retain writes ...).
As we have no documentation on that topic, for now use 8kB of DLM for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23575
TEST=build and run IT8380 dev board.
Change-Id: I4ed452f27e9c457e7ac717b82580781ca506b0d8
Reviewed-on: https://chromium-review.googlesource.com/179322
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
When jumping between image copies, we need to preserve the test fail
count. Otherwise tests failed before the jump would be silently ignored.
BUG=chrome-os-partner:19235
TEST=Fail a test case before sysjump and check the whole test fails.
BRANCH=None
Change-Id: Iebde40141f62ac067ddabf629add46e5d752d674
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181746
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The mock system_usable_ram_end() always returns the same address.
However, this causes the second jump tag to overwrite the first one.
Also, now that the jump data is properly placed, we can actually remove
the mock implementation.
BUG=chrome-os-partner:19235
TEST=Add two jump tag and check the first one is not overwritten.
BRANCH=None
Change-Id: If868895a7c028dd25399adb69e9708de45c84f10
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181745
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The mock power button GPIO is initially low, so we need to set it high
before testing it. Also, wait for all tasks to start before starting the
test to prevent race condition.
BUG=chrome-os-partner:19236
TEST=Pass the test
BRANCH=None
Change-Id: I813588a9c721815c1213882f7a9458daea4d78eb
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Initial support for the ITE IT8380 chip with the following peripherals :
- 8250-like UART module.
- HW timer (with a 128-us tick period).
- GPIO with pins initialization and edge interrupt support.
other functions are stubbed.
- Clock : basic fixed frequency setup only.
It also add the dev board configuration as a test vehicle.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23575
TEST=make BOARD=it8380dev
on IT8380 dev board, use the EC serial console, use gettime from
console.
Change-Id: Id4bf37d1beb21d1a4bee404c9a0bc500025fe787
Reviewed-on: https://chromium-review.googlesource.com/175481
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
It was udelay, which is busy-loop and other tasks have no chance to run.
usleep() could yield the CPU resource out.
BUG=None
BRANCH=nyan
TEST=other tasks get chance to run.
- Before:
[0.010242 not sysjump; forcing AP shutdown]
[0.060471 EC triggered warm reboot]
- After:
[0.010103 not sysjump; forcing AP shutdown]
[0.022985 event set 0x00000080]
[0.041828 Charge state init -> idle0 after 0.010393 sec]
[0.043327 Battery 98% / 1092h:15]
[0.060394 EC triggered warm reboot]
Change-Id: Id41a0b4fda5ac78b1b7f3e3f316b9721fcc3dd34
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181763
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement LED color policy (crosbug.com/p/23957)
Update battery vendor information (crosbug.com/p/24684)
BUG=chrome-os-partner:24885
BRANCH=rambi
TEST=manual
system on, lidclose -> power LED off
system on, lidopen -> power LED on
system suspended -> power LED blinks green every 2 sec
system suspended, lid closed -> power LED off
system off -> power LED off
plug AC in, battfake 95 -> charging LED green
plug AC in, battfake 94 -> charging LED orange
unplug AC, battfake 10 -> charging LED off
unplug AC, battfake 9 -> charging LED blinks orange
battcutoff -> after a few sec, system powered down
plug back in AC -> system comes back on
charger -> I_in < 1700
Change-Id: I89161e2c024d85197b8612a40a61dd50c106549e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181755
The SERIRQ signal will now be high-Z on the EC, which removes a
leakage path. This requires the BIOS to use PM3 for its keyboard IRQ.
BUG=chrome-os-partner:24424
BRANCH=rambi
TEST=boot system; keyboard still works
Change-Id: I0acf425125ced11a9ef6da58ee49979b83c92d5c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181718
