Added a warm reboot function that reboots the AP while preserving
RAM contents. This will be helpful in debugging AP/OS hard hangs since
in conjunction with PSTORE_CONSOLE in the kernel, the kernel log messages
from the previous boot will be preserved.
BUG=chrome-os-partner:13249
TEST=1. From EC console issue the "warm_reboot" command. Upon rebooting
"cat /dev/pstore/console-ramoops" and ensure that the contents are dmesg
of previous boot.
2. Reboot the system using alt-volume_up-r key combination. Upon
rebooting, check pstore contents in the same manner as case#1 above.
BRANCH=snow
Change-Id: Ic8f0415da6182f4c1bc2d35b91302ceda5c19569
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31523
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
By pulling line gio_A15 high, you can for a hard reset of the pmic after
the stuff resistor is changed. This change adds a function that you can
call from the EC and trigger this event (board_hard_reset). The user has
access to this command over the EC console by running "pmu reset" and
it will force the emergency reset.
The board_hard_reset function is used in the pmu's reset code. Whenever
it is trying to initialize or shut down the pmu, it resets many or all
of its registers over i2c. If the i2c commands fail to get a response
from the pmu, the EC will now force a hard reset of the system, which
restores everything, allowing for a restart to fix any situation where
the pmu has gotten its configuration trashed.
BUG=chrome-os-partner:12913
TEST=boot the machine. From EC console check the pmic's register
values, then alter them. Run "pmu reset" to force a reset, and check
the values again. They should be safe values, which you can confirm
by powering on the AP. Repeat this from various starting states: only
the EC on, AP on as well, and setting various registers to 0x00's and
0xff's. To stress test the hard-reset ability from the EC's POV, run
while true; do echo "pmu reset"; sleep 5; done | cu -l DEVICE -s 15200
BRANCH=snow
Change-Id: I911fb9623a7c106d1f993ee4681258c05d4dedae
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31524
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds hooks to re-configure SUSPEND_L (GPIO PA7) when the system
turns on/off. When the system is turned on, PA7 will have its internal
pull-up enabled. This is required since SUSPEND_L is driven by an open-
drain buffer. When the AP is off, we can disable the pull-up
(configure PA7 as floating input) to reduce leakage.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12700,chrome-os-partner:13200
TEST=see notes below
1. Dump GPIO_A CRL when system is off:
read 0x40010800 = 0x41484144
2. Dump GPIO_A CRL when system is on:
read 0x40010800 = 0x81484144
3. Dump GPIO_A when system is put into suspend:
read 0x40010800 = 0x81484144
4. Resume, see power LED react quickly.
5. Soft poweroff, dump GPIO_A CRL:
read 0x40010800 = 0x41484144
Change-Id: I62f02324a2a1fbfb6eff539fc6fdc35a035fa020
Reviewed-on: https://gerrit.chromium.org/gerrit/31315
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The cut-off command is manufacturer-specific. Thus the logic is implemented
in gas gauge IC code. For those boards using this gas gauge, define
the CONFIG_BATTERY_BQ20Z453 in board.h.
BUG=chrome-os-partner:12962,
BRANCH=snow
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
TEST=Tested on snow
ectool batterycutoff ; expect system is off immediately
; if AC power is not connected.
Change-Id: Idd290c76439f3263c1c812b236b79623878f73b2
Reviewed-on: https://gerrit.chromium.org/gerrit/31466
Reviewed-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
When battery temperature t in range 0C to 10C, default charging current
is 50%. And it will take longer than 3 hours to charge battery from 0%
to full.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13172
TEST=manual
Check pmu register 0x4. FASTCHARGE bits[4:2] should be 0b100.
Change-Id: I133acee21c0886b0739b4b41766ca077bb4babbc
Reviewed-on: https://gerrit.chromium.org/gerrit/31458
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
TPSCHROME NTC readings didn't match battery gas gauge temperature. The
charging was turned off by TPSCHROME too early, and was resumed too
late.
This change disables TPSCHROME thermal protection in T40 by set charging
voltage and current to 100%.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12221
BUG=chrome-os-partner:13171
TEST=manual
Check pmu register settings. VSET/ISET are equal in T23,T34,T40
ranges.
Change-Id: Ic60cc2bf606ed02496aad80b02360a19efafd3c0
Reviewed-on: https://gerrit.chromium.org/gerrit/31457
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
EC won't be accessing BIOS SPI, so no need to compile in this code.
BUG=chrome-os-partner:11232
TEST='spi' command on EC console should no longer be valid
BRANCH=link
Change-Id: I09d5e99dbe1fd63cb7839454030067d29249a9ed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31516
Reviewed-by: Vic Yang <victoryang@chromium.org>
Only setup the arbitration GPIOs when CONFIG_ARBITRATE_I2C is set.
BUG=chrome-os-partner:13064
BRANCH=snow
TEST=manual
build and boot on snow
On the EC:
> pmu 1000
In U-Boot:
cros_test i2c
See that there are no failures.
Change-Id: I8a7724700ff79406527c3db8708833728eb9a978
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31305
This feature is not actually used on current platforms. Avoid setting
up the GPIO unless it is specifically enabled.
BUG=chrome-os-partner:13064
BRANCH=snow
TEST=manual
build and boot on snow. See the AC power GPIO does not change when
un/plugging power.
Change-Id: I6731625a19f30f6dd35471b126f3083b39747203
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31304
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It is useful to be able to perform some board init after GPIOs are
set up. When defined, configure_board_late() will be called after
GPIOs are ready.
BUG=chrome-os-partner:13064
BRANCH=snow,link
TEST=manual
build and boot on snow with later changes. See the AC power GPIO does
not change when un/plugging power.
Change-Id: Idc56c0acde9f7bd46b4379731b973d1fce760b3f
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31303
At present GPIOs must be staticly defined in a table. This is efficient
but inflexible, and requires error-prone and correponding #ifdefs both
in the board's gpio.h and gpio.c files.
Create a GPIO_UNSET option for GPIOs. This allows them to be assigned
an enum value, but have the actual use under program control.
BUG=chrome-os-partner:13064
BRANCH=snow,link
TEST=manual
build and boot on snow with later changes. See the AC power GPIO does
not change when un/plugging power.
Change-Id: Iab58275923d7d6cfce62c890b5db9b6758279a4c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31302
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If a bug causes the pmic's internal registers to be overwritten with
garbage, they won't go away and can cause long lasting problems. This
change overwrites them all whenever the EC or AP turn on with known,
safe values, so if that happens, a reboot will restore them instead of
forcing the user to pull the battery. It also overwrites a few of them
when the AP shuts down, to prevent AP bugs from leaving the pmu powering
a bunch of peripherals that it doesn't need after it has turned off.
BUG=chrome-os-partner:12913
TEST=from EC console run "i2c w 0x90 0x0c 0xff" to screw up one of the
pmic registers. Reboot the EC, and the AP should be able to boot just
fine. Once the AP is booted, run that command again. This time, just
reboot the AP, it should come back on like normal. Try again with "i2c
w 0x90 0x0c 0x00". Without the change, this fails to work.
BRANCH=snow
Change-Id: If3f0764f23e0112cc11be60b413f51e1b66e54a7
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31259
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Current *_RW_NOW/RW_AT_BOOT is used to lock the entire flash. This could
lead confusion in the future. So, rename them.
Since the bit definition is unchanged, thus the callers (u-boot, flashrom)
is fine if they don't change the name.
BUG=chrome-os-partner:12951
BRANCH=snow,link
TEST=build in chroot only:daisy,snow,link,bds
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: I2395e93793f590e6fb8aae7006eb8e5c836002bc
Reviewed-on: https://gerrit.chromium.org/gerrit/31199
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
use the watchdog instead of the hibernation mode and RTC wake-up to
accomplish the hard reset.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13126
TEST=on Snow, in U-Boot console, type "mbkp reboot cold" and see the AP
rebooting properly.
BRANCH=snow
Change-Id: Ic8b83f033e9dd4ccf1dff664226bf0ae6b9c47e5
Reviewed-on: https://gerrit.chromium.org/gerrit/31373
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The response size was wrong. It should be right.
BUG=none
BRANCH=link
TEST=none
Build the lbplay tool, copy it to the DUT.
cd src/platform/ec
make BOARD=link
scp build/link/util/lbplay root@LINKIPADDR:/tmp/
Run /tmp/lbplay on DUT. It used to print a warning message. Now it doesn't.
The lightbar will glow green, then red (that's what lbplay does).
Change-Id: Iee02a026f08b6f761e5f28f20b79bcb9f4704a43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31403
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The logic introduced by CL 28139 was incorrect
(ie it just sets to 0 the auto_power_on variable which is already 0)
For software sync, we always want to power the AP.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:13126
TEST=on Snow, cold reset the EC and see the AP firmware booting.
in U-Boot console, type "mbkp reboot cold" and see the AP rebooting
instead of shutting down.
BRANCH=snow
Change-Id: Ib88f75a8b159015df708c041cdc14153fe8736a9
Reviewed-on: https://gerrit.chromium.org/gerrit/31370
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
At the moment we don't seem to have any pull downs configured,
but they wouldn't work. That's because:
* GPIO_PULL_UP => 0x0006
* GPIO_PULL_DOWN => 0x0002
...so if we've got GPIO_PULL_DOWN in flags and then we run
the test "if (flags & GPIO_PULL_UP)", we'll actually test TRUE.
Oops.
BUG=None
TEST=Code inspection.
BRANCH=snow
Change-Id: Ie46ae291fe7edfc9f5237cf8bba3791de9755c5b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31278
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The existing state machine does the following:
- when power button is pressed it
1. powers on the AP
2. sets a timer of 1 sec and then
3. waits for power button to be released
When the timer fires it checks xpshold is set by the AP and if so
it clears the pwron signal (which is used by the AP to detect power
button is pressed).
The problem occurs when the user holds the power button for more than a
second. The AP turns on xpshold, then notices that pwron is still on
and subsequently powers down because it thinks the power button is
pressed. When the button is finally released, since it was held down
for more than a second, the timer routine notices that xpshold is not on
and therefore shuts down the system.
Another problem found while analysing this state machine is that loop
checking for poweroff only triggers on the rising edge of xpshold. This
means that if the AP powers down the EC might miss a possible power
event.
Here is the proposed fix:
When the power button is pressed the EC will:
1. power on the AP
2. Check for xpshold to be asserted with a 1 sec timeout
3. If uboot is healthy xpshold should come on pretty quickly; the EC
then waits for the power button to be released in less than 8 seconds
4. If the power button is released then the EC waits for power off
events.
5. If the power button is not released it waits for upto 8 seconds
before turning off the AP.
The added wrinkle is how to address a borked uboot case. In the case
where xpshold doesn't come on in < 1 second, the EC will allow the AP to
stay on for upto 16 seconds so that USB boot can finish. The user must
hold the power button down until uboot boots and sets xpshold. The
assumption here is that USB boot takes < 16 seconds.
BUG=chrome-os-partner:12748
TEST="follow instructions in bug report"
Change-Id: I5b582a6c3ae3449238e2813e4a581bd8f92dd846
Signed-off-by: Puneet Kumar <puneetster@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31291
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
On snow, there are reports of the following warning in the i2c master
reciever code:
Stop event deadline passed: CR1=0000001000000001
I've been running this torture test, and even with the timeout feature
completely removed, it never hangs. The stop bit is always sent
eventually, even through thousands and thousands of transactions (of which
a couple take too long for the current timeout).
I timed a lot of these and it looks like the vast majority are fine but
just a few are really really slow. To this end, I'm increasing the
timeout. It seems that the wait loop is getting preempted for a while
before it can go back and check, causing these timeout messages. So every
now and then the process get pre-empted for a long time causing what
looks like a long timeout. The thing is, the stop bit is always getting
sent, we're just not noticing for a while. So even in the really slow
cases, everything should be fine.
Since the bit's getting sent either way, it seems like increasing the
timeout all but fixes the problem where the EC thinks it didn't send.
However, since the timeout is quite high now, I added a sleep
in the busy loop so that if a message is messed up and the stop bit doesn't
send, the task won't steal the cpu for the entire time.
Note: This also fixes a bug in the i2c error handler where it was trying
to print ints and strings and ads a little more information to the
timeout warning in case it starts showing up again.
BUG=chrome-os-partner:12742
TEST=From the EC console run "battery 100000" while running
"while true; do /usr/local/sbin/i2cdump -f -y 4 0x48; done" to seriously
stress test the i2c bus. Then reboot the machine several times. There
should be no Stop bit warnings, or failed i2c transfers
BRANCH=snow
Change-Id: I590a9458783d16e57987102b1ec1299d5ddb0fa2
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31024
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It wastes time to erase blocks that are already erased and it is faster
on stm32 to check first. Add a check in flash_physical_erase() on all
chips, using a common flash_is_erased() function.
BUG=none
BRANCH=snow,link
TEST=manual
Do software sync in U-Boot and see that it succeeds. This tests that
we can still erase and then boot a written image. It typically saves
a second on a full sync over i2c.
SMDK5250 # cros_test swsync -f
SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
Flashing RW EC image: erasing, writing, done
Flashing RO EC image: erasing, writing, done
Full software sync completed in 22.949s
SMDK5250 #
Also see that second erase is faster:
SMDK5250 # time mkbp erase rw
time: 0.952 seconds, 952 ticks
SMDK5250 # time mkbp erase rw
time: 0.054 seconds, 54 ticks
SMDK5250 #
Change-Id: I3699577217fdbb2f212d20d150d3ca15fdff03eb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30851
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we set the TIM3 hardware timer match interrupt (used for 16-bit MSB
of the 32-bit microsecond counter), as the STM32 hardware block is not
triggering an interrupt on an exact match (only on the transition from
N-1 to match value N), we need to check whether the counter has been
incremented to the match value before we set the interrupt enable bit.
In that case, we simply fallback to the existing code to set the LSB
match interrupt.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12715
TEST=use Snow board and see we are no longer getting EC watchdog in the
idle task.
BRANCH=snow
Change-Id: I4ceeb46425c799e328603ae0e99b678547d88fbe
Reviewed-on: https://gerrit.chromium.org/gerrit/31228
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Charger LED is controlled by TPSCHROME chip. And it blinks only when
hardware detected charging error. On other charging error conditions
not detected by TPSCHROME, we set the temperature thresholds to make
charger generate the error blink.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12224
TEST=manual
Plug AC power, heat up battery to 65 C. The charging LED should
start blinking instead of green.
Change-Id: Ib1c38a88c026471a52fbbb4f803e3b2aba93ab40
Reviewed-on: https://gerrit.chromium.org/gerrit/31139
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
The i2c driver was returning the result from task_wait_event() as an
error code when it failed. However, this function returns an event
mask, not a valid error code. It has been replaced to return
EC_ERROR_TIMEOUT instead when the even times out.
BUG=chrome-os-partner:13057
TEST=Booting the machine, and normal use works fine. Running i2c stress
tests also work without error. No functional changes were made, only
the error codes for debugging.
BRANCH=snow
Change-Id: I3e48f97c08c82fd50b811e8289f3bd378ecb3171
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31214
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ec used to have to check the state of the AP since it would leave
the arbitration lines when it suspended. That meant you couldn't trust
the arbitration lines without checking the power state. Now the AP
pulls the arbitration lines high when it suspends, so it no longer needs
to test this when trying to acquire master.
BUG=chrome-os-partner:12460
TEST=First, on the EC console run "battery" and "pmu" to make sure they
work. Then repeat those steps after putting the AP in suspend by
running powerd_suspend, they should still work. Then shutdown the
machine entirely and try them again. Note: pmu needs the AP to be on to
work, so if it fails here that's okay, just make sure it's not an
arbitration error.
BRANCH=snow
Change-Id: I335156bbce4888949111f74e8a83fe9d184a7a63
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30906
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The AC status GPIO also indicates power button. When power button is
pressed, EC should return VACG in pmu_get_ac() funtion. If this function
is called in interrupt context with power button pressed, return 1.
Charging task will play nicely in charging mode without real AC. But in
discharging mode, it will shutdown application processor if battery
remaining capacity is too low.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12738
TEST=manual
With AC plugged, press and hold power button.
Run uart console command "pmu" and check output, "ac gpio" should be 1.
Change-Id: I26d1a5a7a4ed2ff26a35e965a3ca2307a9c231e9
Reviewed-on: https://gerrit.chromium.org/gerrit/31112
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:12412
BRANCH=snow
TEST=none
The current constant is wrong. It was broken before, now it still may be
broken but hopefully less so.
Change-Id: Ia425bc45c4ccb0b4623fa802d4e5913389cb9d22
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is intended to prevent accidental AP reboot when soft rebooting
the EC, e.g. via sysjump during firmware updates. For our platforms,
the PMIC_PWRON_L causes the AP to see a keyboard power button press.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12650
TEST=sysjump via "ectool reboot_ec RW" or firmware update no longer
causes AP to reboot,
Change-Id: Ife227285499d5cd52d6a0cb0ebe5df2f51d706d4
Reviewed-on: https://gerrit.chromium.org/gerrit/30291
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
USART1 has always had its Tx and Rx pins configured as "alternate
function output". However, this turns out to be incorrect since
there is no concept of an AF input on the STM32F. Instead, the
Rx pin should be configured as an input (and the Tx remains an
AF output).
This also simplifies the console resume code since we only need to
enable/disable the interrupt rather than reconfiguring the GPIO.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12223
TEST=flashed on snow, EC console works
Change-Id: Ia92dbbac16fc55d0db62381dfb487aeb4f4121b4
Reviewed-on: https://gerrit.chromium.org/gerrit/30941
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
I keep getting asked to build an EC image to manually control the lightbar
patterns so that the Powers That Be can look at it. This change just makes
it possible to turn that mode on and off for yourself. You'll need a root
shell or the EC console to do it, though.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
From the EC console, type
lightbar demo 1
OR from the root shell run
ectool lightbar demo 1
After that, these keys should change the lightbar appearance (transitions
may be slow and subtle - that's intended):
UP = battery is more fully charged
DOWN = battery is less fully charged
RIGHT = battery is charging
LEFT = battery is discharging
BRIGHT = increase lightbar brightness
DIM = decrase lightbar brightness
Note that this does not interfere with the normal function of any keys. It
only adds some additional EC behavior.
Change-Id: Ia1a9855188244d74b670f9dbfdf60e3ac0343460
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30899
This also moves flash related tests to use new 'hostcmd' console command.
BUG=chrome-os-partner:10262
TEST=Test passed
BRANCH=none
Change-Id: I5616bfa93bcde0beb4cb2baf2d38e8b5d827c275
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30665
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When AC power is not connected, EC doesn't update battery information in
mapped memory. This makes battery information unavailable is AC is not
present when EC boots.
BUG=chrome-os-partner:12858
TEST=Unplug AC and reset EC. Run ectool and check we can see battery
info.
BRANCH=link
Change-Id: I23339962a6aa1bbbf6806c1184b96e949466208f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30820
Reviewed-by: Rong Chang <rongchang@chromium.org>
Usually the power LED is driven by the PWM mode so that its nominal
brightness can be set to a "soft" on value. However, when
the LED is to remain off the LED should be switched to floating
input mode. This reduces voltage leakage.
This CL updates the power_led_task to configure the LED however is
appropriate and adds board functions to re-configure the GPIO.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12381
TEST=LED responds as expected in suspend and on/off states, also
tested that leakage is reduced with multimeter
Change-Id: If90ac78aaffe7358cce80dd02ec1423c2cb4f664
Reviewed-on: https://gerrit.chromium.org/gerrit/29705
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This splits out the GPIO config logic from gpio_pre_init() into its
own function so that it may be used by code elsewhere.
TODO: Improve alternate function setting, and clean up Snow's board.c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=none
TEST=flashed onto Snow, everything came up as expected
Change-Id: I47888c89d4d2bedd0c37b95406a64f024f1ec354
Reviewed-on: https://gerrit.chromium.org/gerrit/30762
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
There was a usleep put into a function that can be called from in an
interrupt context, which doesn't work. This just switches it over to
udelay which will work in an interrupt.
Also flips the condition on the i2c if/else that might send it there.
It was backwards before
BUG=chrome-os-partner:12688
TEST=Run "battery" "pmu" boot the machine and use the keyboard. Then
replace the in_interrupt_context() function with "1" to force it to use
polling and repeat the test. Everything should work in both cases.
BOARD=snow
Change-Id: Ib2a8c7f9e5e2eb3f6b00678d6307afc9dd5f0518
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30575
Reviewed-by: Simon Glass <sjg@chromium.org>
Erasing the flash can take a while, by which time the host may have timed
out. So pass an in-progress message back to the host before starting, and
when done, stash the result for later collection.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: I5566a5519a1c8b320573b20e1ea7660217b32a5e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30471
To reflect the CL 00799d5 that moves the pstate to 0xf000.
BUG=chrome-os-partner:12799
TEST=Build in chroot.
snow: WP_RO is changed from 0:0xf000 --> 0:0x10000.
daisy: WP_RO is unchanged.
link: WP_RO is unchanged.
Change-Id: I572bae3f624744e60d13a762875211beffc6c516
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30670
Reviewed-by: Vic Yang <victoryang@chromium.org>
When a command is marked as in-progress, provide an interim EC_RES_IN_PROGRESS
response and then stash the real response (when available) ready for a
EC_CMD_RESEND_RESPONSE message.
Track whether the host_command processor is busy internally within this
driver. Provide this information through an EC_CMD_GET_STATUS message.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: I5acece074ad8408c978ca36b73d1330fa51575ae
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30470
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The serial console was showing that the CPU was being forcefully shut down,
but I couldn't figure out why. Add a debug message so I'll know next time.
BUG=none
TEST=none
BRANCH=none
Change-Id: I6216711d03fd5e08190b9f0528a4bd8948b74dd8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30606
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the AP is suspended, we are using the timer TMR2 to do the power
led "breathing", so we cannot cut the clocks as they are used for this
PWM.
The EC will be in idle mode instead of stop mode during S3.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, suspend the AP and see you can still type in the EC
console and the power led is "breathing".
Change-Id: Ib4cce36c5a9bf649996bf627baeb30ef2a3221a8
Reviewed-on: https://gerrit.chromium.org/gerrit/30057
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: <arscott@google.com>
Some commands take a long time. For interfaces which are not synchronous the
host wants an immediate response to know that the command is in progress.
Provide this new result code, and set LPC to ignore it.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Change-Id: If801c21e6cf96746858dfa64f6ce1f1631d3e6e5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30469
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Rather than have the send_response() handler called willy nilly from
around the EC code, provide an official function for doing this step.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Tried 'mkbp reset' command on snow but it did not seem to work properly
Unable to test on link at present
Change-Id: I8d9146639efb2af482d80563b403771cee961942
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30468
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fixing a couple problems in the error handling for i2c interrupts. The
code could fail and not notice if master_start() returned an error code
with the TASK_EVEN_WAKE bit set. Now it stores the return values
separately to prevent this.
Also, the task id's that the ISR's use to wake up the i2c task after the
transfer is complete were uninitialized. They should always be
initialized by a call to dma_enable_tc_interrupt() but just in case, now
they all get a default value in dma_init() which is called on startup in
board.c
BUG=chrome-os-partner:12405
TEST=confirm that i2c is still working in both slave and master mode by
using the battery and pmu commands from the EC console, then booting up
the machine and using the keyboard. Confirm there are no error messages
on the cpu console.
Change-Id: I49c3da0bf17d0853247a37131cac9719face7ed4
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30417
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This change corrects charger interrupt event handling, charger enable
gpio, battery full condition, EC deep sleep mode support when AC
unplugged, and lid controlled power off.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12573,12574,12575
TEST=manual
- ec console command 'gpioget':
- SPI1_MISO should be 0 when AP off
- CHARGER_EN should be 0 after AC unplugged
- charging led should be off after AC unplugged
- when battery remaining charge < 3%, system should be powered off
without AC.
- ec console command 'sleepmask 0', turn off AP:
- deep sleep only when AC unplugged
Change-Id: I0f63835dae67d90de7a8c8c6c3537ca9a16faed4
Reviewed-on: https://gerrit.chromium.org/gerrit/30316
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
To make software Sync work, they need to be able to call
i2c_send_response() from within host_command_received() while still in
an interrupt context. This won't work if you're using interrupts to
know when the dma transfer has completed. This puts a switch in that
will toggle between interrupts and polling the interrupt flag based on
if the program in in an interrupt context or not.
BUG=chrome-os-partner:12688
TEST=Run "battery" "pmu" boot the machine and use the keyboard. Then
replace the in_interrupt_context() function with "0" to force it to use
polling and repeat the test. Everything should work in both cases.
Change-Id: Ie989c1a6ad29529a7ec390065b310ad4af8cf0bf
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30483
Reviewed-by: Simon Glass <sjg@chromium.org>
To reduce the amount of time spent polling to see if the i2c bus has
completed its transfer, I'm converting it over to interrupts. Before
starting a dma transfer, the i2c code now enables dma interrupts with an
ISR that will just wake up the i2c task when the transfer is complete.
This leaves the cpu free while the dma is handling all the i2c work.
The slave-receiver didn't require any updates as it is already interrupt
driven, via the i2c events. The other three cases: master-receiver,
master-transmitter, and slave-transmitter, have all been converted over
to use the dma interrupts. With these changes, the cpu should spend
very little time waiting for i2c transfers to complete.
BUG=chrome-os-partner:12405
TEST=To test the master modes, from the EC console run "battery" and
"pmu." If those work, then master mode is functioning. For slave
modes, power on the machine and monitor the cpu console for errors.
When it's on, try typing and confirm there are no errors there either.
Change-Id: I1ca020911b7be6762389ca2b858b2b973f8754bc
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30229
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is better than having the 0xea byte only appended in ec.bin,
since now the byte is present in ec.RW.flat and ec.RO.flat. Needed
for EC software sync.
BUG=chrome-os-partner:12412
BRANCH=link,snow
CQ-DEPEND=30305
TEST=manual
1. xxd ec.RW.bin | tail; should end with 0xea
2. xxd -g4 build/link/ec.bin | grep -C3 454e44ea
That word should be the last one before a bunch of 0xfffffff bytes.
There should be 2 matches (since there's RO and RW firmware)
Change-Id: I0de5cc78083f1a9b49202fbe2305a3101f401db3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30303
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
