It would be really nice to be guaranteed to see watchdog warnings
before we actually hit a watchdog reset even if something strange is
going on with the CPU. Let's increase the margin between the timer
and the independent so that the hardware watchdog is really hit as a
last resort.
It seems like a 1.6 second hardware watchdog wouldn't be the end of
the world so let's bump that way rather than increasing the number of
warnings.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST="waitms 1000" on EC console no longer ever reboots and "waitms
2000" usually does.
Change-Id: Ic5e5ddec22fb8484cc7c552b19d3f2043c105d0c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204895
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On stm32 we were programming the WATCHDOG_HELP timer with the same
value as the independent watchdog (which automatically resets the
CPU). That means we weren't guaranteed to see the WATCHDOG_HELP. It
happened to work most of the time due to the the LSI oscillator fudge
(we assumed the watchdog was on a 56 kHz oscillator when it was
probably on a 38 kHz one), but let's give ourselves a guaranteed gap.
It's unlikely that this extra gap will actually help on most machines
(if we're running at 53 kHz or lower we already had this much margin),
but it's nice to be safe.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST=Increase margin to 400 (instead of 50) and type "waitms 300".
Sometimes hit watchdog warning.
Change-Id: I7f876757c15d7775116720c408a4127b4b94adfa
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204894
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug and actually increase watchdog timeout to 1.8s.
BUG=none
BRANCH=none
TEST=put a 3 second blocking delay in pd_task and make
sure watchdog reboots. set blocking delay to 1.5seconds
and make sure no reboot.
Change-Id: Ie66621a3bd98354f9fd22b9b10a866d004277340
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204471
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: 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>
Increase watchdog timeout to 1.8 second. The pd_task can delay up
to 1.5 seconds, so the watchdog must be at least that value.
On Zinger, the new timeout period will be 2 seconds with LSI clock at 50kHz
and 3.36 seconds with LSI clock at 30kHz.
Note: the LSI frequency range is tighter on STM32F0 and cannot go up to
56kHz.
BUG=none
BRANCH=none
TEST=add 1.5 second blocking delay to pd_task and make sure
watchdog is normally not firing.
Change-Id: I444639ccacd3452181a5fb6caab8e5df7ef3c847
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204333
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
If board.h or config_chip.h is included before config.h, CONFIG_* flags
may be incorrect. For example, if config.h says:
...
#define CONFIG_DEFINED_FLAG
...
#include "board.h"
...
And board.h says:
#ifndef __BOARD_H
#define __BOARD_H
...
#undef CONFIG_DEFINED_FLAG
...
#endif
Then this code:
#include "board.h"
#include "config.h"
would results in CONFIG_DEFINED_FLAG being defined, instead of undefined
as stated in board.h.
Avoid this by emitting error when board.h or config_chip.h is included
before config.h.
BUG=None
TEST=make buildall
BRANCH=None
Change-Id: Ic4a8b68e8ab1ef2a4cf9e926ab9008d2b106b943
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203265
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On samus battery, when the battery is dead it reports 0 for desired
voltage, current, and state of charge. In this case we should allow
charging.
Added a CONFIG option for this that should be removed as soon as
the battery side is fixed.
With this CL, when a dead samus battery is used and a charger is
connected, we attempt to charge it.
BUG=chrome-os-partner:29465
BRANCH=none
TEST=test on a samus with a dead battery. w/o this CL, the battery
never charges because the charging not allowed flag is set. With this
CL, the battery charges.
Change-Id: Ic61f27a27237166d33cb9ea5f024d3ef6360ce82
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202603
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When this option is configured, two changes take place.
First, the AP doesn't power on by default when the EC reboots. To boot it,
you can run the "powerbtn" command, or poke the power button manually, or
any of the normal things.
Second, we watch for power-related signal changes (anything that's connected
to the power_signal_interrupt() function) and keep track of them as they
happen. After a second with no further changes, we print the time and value
of each change. For example:
[19.939212 Port 80: 0x29]
[19.967971 HC 0x23]
[19.976236 Port 80: 0x3a]
[19.995700 HC 0x87]
[20.567884 Port 80: 0x73]
11 signal changes:
19.638241 +0.000000 PCH_SLP_SUS_L => 1
19.654378 +0.016137 PCH_SLP_S5_L => 1
19.654457 +0.000079 PCH_SLP_A_L => 1
19.654535 +0.000078 PCH_SLP_S3_L => 1
19.654587 +0.000052 PCH_SLP_S4_L => 1
19.659630 +0.005043 PGOOD_1_5V_DDR => 1
19.663199 +0.003569 PGOOD_1_5V_PCH => 1
19.664751 +0.001552 PGOOD_1_8VS => 1
19.668735 +0.003984 PGOOD_VCCP => 1
19.671883 +0.003148 PGOOD_VCCSA => 1
19.868406 +0.196523 PGOOD_CPU_CORE => 1
[21.908551 Port 80: 0xf0]
[21.908855 HC 0x48]
BUG=none
BRANCH=ToT
TEST=manual
Build with CONFIG_BRINGUP, notice those two changes.
Change-Id: I55fd2021a0eae7dbfd1aaf5d93971f65bf2367b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202574
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Imported code from VBoot firmware cryptolib and slightly reformat it for
the EC code base.
We already have SHA-256, but for updates over PD, the maximum payload
size is 192 bits, so SHA-1 seems a better trade-off.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28336
TEST=none
Change-Id: I6da7b71a9af03c6689accfa3c59cfcf7776fcfc6
Reviewed-on: https://chromium-review.googlesource.com/199553
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Typically bq24xxx charging chip limits input current to minimum of
register value and ILIM pin. For fruitpie, the current limit will
be decided solely in software, and the hardware pin will be ignored.
BUG=chrome-os-partner:28611,chrome-os-partner:28311
BRANCH=none
TEST=Tested on fruitpie. Verified that current limit can be set
above the ILIM pin value of 500mA.
Change-Id: Ia687446f95f9d18fde9d2b4ebb0e1c093aebf885
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198940
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added config option CONFIG_USB_PD_TX_USES_SPI_MASTER which switches
to use SPI master for PD transmit. The advantage of SPI master mode
is at the end of the tranmission, we don't have to send any dummy 0
bits. When the option is set, the CPU_CLOCK must be set to 38.4MHz,
so that the SPI master can generate the correct clock frequency.
BUG=chrome-os-partner:28309
BRANCH=none
TEST=Tested by connecting two fruitpies together across CC1. One
fruitpie has been modified such that the MISO and MOSI lines are
swapped and is running PD TX in SPI master mode with 38.4MHz clock,
while the other is running PD TX in SPI slave mode. On EC console
ran pd charger on one board and pd dev on other board. Verified
that communication works with no errors. Ran for 10 minutes in each
configuration.
Change-Id: Ib24030d34d95d59f4ac6c2dae98bf7adda1ada01
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197215
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Also adds 'battparam' console command.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=Run 'ectool batteryparam set 0 0x1234'
'ectool batteryparam get 0'
and on the console:
'battparam 0'
'battparam 0 0x1234'
on a board that implements parameter 0.
Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181
Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197162
So that host and EC commands will be defined in common/battery.c.
The board-specific battery.c can focus on the proprietary method.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=make buildall runtest
Tested "cutoff" in EC console on big.
Change-Id: I213c0d601d0241c8dea309d6ac60c72452d2d100
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
add support for CRC-32, it's using the USB variant for the constants and
bit ordering (same polynom as Ethernet).
This code is using an (evil) "stateful" design to be compatible with the
hardware CRC controller : you should NOT do concurrent accesses without
external locking (but it's good enough and ligthweight for current
usage)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run interoperability testing against other 3rd parties USB
implementations.
Change-Id: I1a07b2c4e2e71e15f9d257611652061bcfb0de9c
Reviewed-on: https://chromium-review.googlesource.com/189865
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add support TI BQ24773 1S/2S/3S NVDC battery charger.
This is not a "Smart Battery" compliant charger IC, it should and cannot
use the sbc_ helpers.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on FruitPie, run "charger" command on the EC console,
add the charger task and see the battery charging.
Change-Id: I6f470184f0ce424a05007e493d802dcdb2156477
Reviewed-on: https://chromium-review.googlesource.com/191212
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The charger driver code has no dependency on the charger task,
we do not need to force the de-activation when the charger task is not
running.
This allow to debug new charger code without the task acting in
background and should not have any drawback.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
and run "charger" command on Fruitpie without the charger task.
Change-Id: I49a4885a2abf0e5d9e652e037941b1c4672beb7a
Reviewed-on: https://chromium-review.googlesource.com/191211
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Added ability to disable the keyboard to wake from suspend when the lid
is outside a certain angle range. This has been added to glimmer by
defining CONFIG_LID_ANGLE_KEY_SCAN in its board.h.
Also modified the lid angle calculation to include a reliability
flag which can be used to tell when the hinge aligns too closely
with gravity and the lid angle value is unreliable.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
In S3, verified that when the lid is open past ~180 deg, the keyboard
does not wake the machine. Also verified that if you align hinge with
gravity, the keyboard enabled/disabled status remains the same (since
we can't actually trust the lid angle value).
Change-Id: I45b2c7c3c4bbcae61d3a0f8b5baa461ab8dabfb0
Original-Change-Id: If1a1592d259902d38941936961854b81b3a75b95
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190061
Reviewed-on: https://chromium-review.googlesource.com/191612
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Adding in support for accelerometer interrupt for use currently
in clapper and glimmer. This is disabled by default and can
be enabled with CONFIG_ACCEL_INTERRUPTS.
BUG=none
BRANCH=rambi
TEST=Manual test on a glimmer using accelint console command.
On console enter:
accelint 0 32
When you tap the lid, it should fire the interrupt and print msg
to console.
accelint 1 32
Tap the base and it will fire another interrupt.
Change-Id: Iaab324945e34d527140399ec4f06efd812a62840
Original-Change-Id: I0329112fdcae3c8adc0ca07e74fef7a591d4b9a1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190099
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191549
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>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We don't have available GPIO pin for power button as the hibernate
(stand-by) wake-up source. Also, we don't want to do board change.
So, put the EC in a decent infinite loop to pretend the hibernate mode
and wait for particular wake-up event. This should be fine because
the AP is already down before EC hibernates.
BUG=chrome-os-partner:25435
BRANCH=Nyan
TEST=see comment #6 of issue for detailed test steps.
Change-Id: I2cae131789f9ca5808b60d5f2495222ca9016e7c
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186061
Reviewed-by: Randall Spangler <rspangler@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 EC had inputs with internal pullups on SUS_STAT#, SUSPWRDNACK, and
SLP_SX#. But we never used those signals for anything. The pullups
cost 1.5 mW power in S3. So, remove those signals and their pullups.
They can be turned back on via CONFIG_CHIPSET_DEBUG.
BUG=chrome-os-partner:25568
BRANCH=rambi
TEST=build with and without CONFIG_CHIPSET_DEBUG. Verify gpioget and
powerindebug show the signals only when it's defined.
Change-Id: I0851243615c91a3aa8aa1b28df70809b578d2e74
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188389
Reviewed-by: Dave Parker <dparker@chromium.org>
Previously, the AP could only set the current wireless power state.
It couldn't determine what the EC would do in S3, nor could it get the
current wireless power state. Extend the wireless command to do so,
and add an EC console command to aid in debugging.
BUG=chrome-os-partner:25655
BRANCH=rambi
TEST=manual; expected numbers are from EC 'wireless' command
AP off -> 0x0, 0x9
AP on -> 0xd 0x9
AP suspended -> 0x9 0x9
AP on -> 0xd 0x9
ectool wireless 0x1 -> 0x1 0x9
ectool wireless 0xd -> 0xd 0x9
ectool wireless 0 0 0 0 -> 0xd 0x9 (and prints 0xd 0x9 to root shell)
ectool wireless 5 -1 -1 0 -> 0x5 0x9
AP suspended -> 0x1 0x9 (doesn't turn on 0x8, just turns off 0x4)
AP on -> 0xd 0x9
ectool wireless 0 0 0 -1 -> 0xd 0x0
AP suspended -> 0x0 0x0
AP on -> 0xd 0x9
Change-Id: I8ead2d4a4423b51ec4f638bf94c62de98726b25c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187273
Added motion sense task to Clapper and Glimmer. This task samples
the accelerometers and calculate a lid angle. Note that as
the machine is rotated towards the hinge angle aligning
with gravity, the lid calculation becomes less trustworthy.
Added a math_util file to hold various mathematical functions
useful for calculating lid angle that may be helpful in other
places.
For each board with accelerometers we need to define some
orientation specific data in board.c. There is a calibration
procedure through the EC console that can be enabled by
defining CONFIG_ACCEL_CALIBRATE. The calibration procedure can
help determine the orientation data required.
For debugging purposes there is a console command to regularly
print to the EC console the accelerometer data and derived lid
angle. The console command can be enabled by defining
CONFIG_CMD_LID_ANGLE.
BUG=none
Original-BUG=chrome-os-partner:24703
BRANCH=rambi
TEST=Ran the calibration procedure on a Glimmer unit, and then
rotated the machine in space. Verified that the lid angle
calculated roughly matched actual lid angle.
Original-Change-Id: I63a5e384b7f6b628b4ea01de49843355fb8d6ebe
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
(cherry picked from commit efb07945a5159fa0e7a746c666b2519ebdca9c22)
Conflicts:
board/clapper/board.c
board/clapper/ec.tasklist
board/glimmer/board.c
board/glimmer/ec.tasklist
Change-Id: Ibc492ef5c11e7084e87f01338c4d7775f9a08c18
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187433
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added accelerometer driver for kxcj9 accelerometers. Currently
the accelerometers aren't being used by anything, but there are
console commands, accelwrite and accelread, to perform transactions.
BUG=none
BRANCH=rambi
TEST=Used EC console commands to test that accelerometers respond
and data looks reasonable.
Original-Change-Id: I6ddcf04ec278adeacb148c19b10c3c296b467954
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184693
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 5e1d2052b034b2400b98b2126243e01397a2ce56)
Conflicts:
board/clapper/board.c
board/clapper/board.h
board/glimmer/board.c
board/glimmer/board.h
Change-Id: If8744ddc3273fc08e29830adfd068dc302dd120a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187432
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is experimental for now; the capsense chip simply reports its buttons
as the number keys on the keyboard (1-8).
BUG=chrome-os-partner:23382
BRANCH=samus,ToT
TEST=manual
To test, you'll need a reworked and correctly programmed capsense module.
Boot the system, and switch to VT2. Touch the capsense bar and you'll see
the input appear on the console as though you were typing numbers.
Note that the capsense hardware is still buggy. Refer to the bug for
workarounds.
Change-Id: I4c3a8b70b8197ffd538c38c59c9336383365afa7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185434
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
BUG=chrome-os-partner:24912
BRANCH=baytrail
TEST=Manual. Enable CONFIG_POWER_BUTTON_IGNORE_LID
on a device, boot it, and go into dock mode with
external monitor attached. Fake-close the lid with a
magnet or servo. Verify the power button still sends
press/release events to the host with evtest.
Change-Id: Idb05375eee0743a8a2c459070854c03fe3afe894
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184493
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This should reduce EC power consumption in S3 and S5.
BUG=chrome-os-partner:25377
BRANCH=baytrail
TEST=make sure jtag is not active (not running openocd via servo)
boot system; suspend system
wait 60 seconds; should see "Disabling console in deep sleep"
type on console; should still allow typing
wait 60 seconds; press spacebar; should still resume from suspend
Change-Id: I47e33e158c1b90077f944a6af4374f39efa68d94
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184165
Reviewed-by: Alec Berg <alecaberg@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>
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>
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
It will be used by all variants of Rambi, so #ifdef BOARD_RAMBI is too
restrictive.
BUG=chrome-os-partner:24864
BRANCH=rambi
TEST=boot rambi 1.5 board; plug in USB mouse
Change-Id: I0ff02077388a6c6621c5746a693dde894cf8ad77
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181682
Reviewed-by: Alec Berg <alecaberg@chromium.org>
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual: Verify that CONIFG_PECI_TJMAX set per-board matches
the value queried over the PECI bus with the restricted
"peciprobe" command.
Change-Id: I8e99a23a66f26d6101e01cc751d0a8ca79686321
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179682
Reviewed-by: Alec Berg <alecaberg@chromium.org>
