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>
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>
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
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>
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>
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>
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>
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 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>
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>
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
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>
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>
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>
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>
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>
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>
Changes made by this patch:
1. Create IRQ handler for the TPS65090 IRQ. IRQ wakes up charger task.
2. Charger task sets the AC_STATUS GPIO based on the AC status.
3. Initialize PMU at power-on.
BRANCH=snow
BUG=chrome-os-partner:11739
TEST=Power on the system, with servo v2 connected to EC console. Plug
and unplug AC. The IRQ handler should be triggered.
Change-Id: Ice23411c275111fdb56d2c47ba28c3c44dee4d71
Signed-off-by: Simon Que <sque@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29914
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is to prevent temperature value being read before the first time we
poll sensors causes unexpected error.
BUG=chrome-os-partner:12614
TEST="sysjump RW" and then "temps" immediately. Check all temperature
readings are near 300 K.
Change-Id: I5c84d9696b4876fdfcf14c3a416cbc09c040d4ee
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30138
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Add a special port80 event for LPC reset assertion and use that event
to store the previous post code.
- Add a new command to retrive the last saved post code so I can easily
query it at boot/resume and log unusual codes.
BUG=none
TEST=manual (with additional coreboot/mosys changes)
- interrupt boot process by issuing x86reset on EC console or
by using warm reset button on servo
- read event log with mosys on next boot
78 | 2012-08-13 09:24:04 | System boot | 262
79 | 2012-08-13 09:24:04 | Last post code in previous boot | 0x9e
80 | 2012-08-13 09:24:04 | System Reset
Change-Id: I7b9f10442b9c468d89fde4e75adb94b0c07c2c8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29995
Reviewed-by: Randall Spangler <rspangler@chromium.org>
system_hibernate(0, 0) now hibernates until a wake pin assert, with no
RTC wake.
BUG=none
TEST=manual
command -> expected reset flags from 'sysinfo'
1. reboot -> soft
2. reboot hard -> power-on hard
3. hibernate (and press power button) -> power-on wake-pin
4. hibernate 3 (and wait for timeout) -> power-on rtc-alarm
5. hibernate 10 (and press power button before 10 sec) -> power-on wake-pin
hibdelay 10
then shut system down and run on battery
10 sec later, system should hibernate.
Change-Id: I399413d265f6fcf808adf9ed1db7b812a1b12fc2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29923
Reviewed-by: Vic Yang <victoryang@chromium.org>
update settings according to IR3570Axxxx_REV5_DRC_7-27-12.
This should fix the spurious UVLO during reboot,
so it re-activates the fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:11947
TEST=on Link EVT reworked with IR3570A, run software and check we can
reboot normally and we have no GPU warning.
Change-Id: I5882f1d25a65c81fdaa4326ead913bc080b71ee9
Reviewed-on: https://gerrit.chromium.org/gerrit/28650
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:12483
TEST=from root shell, 'ectool console', then on the ec console, type
'help list' a few times to generate lots of debug output, then repeat
'ectool console'. Then on EC console, 'syslock', and then 'ectool
console' should fail.
Change-Id: Ie1c74c7e35d6b8228615d20192fd90093977de64
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29825
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Adds shmem command to print amount of shared memory. This is also a
useful indicator of how much IRAM is left, since shared memory will
expand to fill all unused IRAM.
Removes never-implemented wait param to shared_mem_acquire().
BUG=none
TEST=shmem
Change-Id: I798ff644d701dcba52219b70bec99c06a23d03ec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29809
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It was previously only enabled for 1500us during boot, but in a way
that triggered a needless round of notifications to other modules.
This is cleaner.
This also fixes adc_init() not initializing the task IDs to wake when
interrupts come in, and removes some unneeded code from other init
functions.
BUG=chrome-os-partner:12472
TEST=boot system and run adc command. Should still provide reasonable data.
Change-Id: I9ae5857d988c727caf5d53f551a2f12b30974c0f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29806
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the AP is not running and we have enough time go to STOP mode
instead of simple idle.
The EC consumption should drop from 12mW to a few mW.
This is currently not activated by default, you need to type "sleepmask
0" in the EC console to activate it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8866
TEST=on Snow, check the software is still working properly when STOP
mode is activated and measure power consumption on 3v_alw rail.
Change-Id: I231d76fe6494c07b198c41694755b82d87c00e75
Reviewed-on: https://gerrit.chromium.org/gerrit/29315
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Superseded by EC software sync (hash-based).
Sig-based vboot was correctly implemented, but ended up being too slow
to be useful given the limited processing power of the EC chips, and
we also couldn't come up with a manageable way to handle A/B
autoupdate of signed EC firmware.
This change and an associated vboot_reference change shrinks the EC
binary by ~2KB.
BUG=chrome-os-partner:11232
TEST=build link,snow; boot link and check that 'hash' command still works.
Change-Id: I3f03ae2d0a4030977826980d6ec5613181e154c2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29496
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:12353
TEST=hack the thermal monitoring and/or battery code to trigger a shutdown
then see that the events get set
Change-Id: I5ef2ac03cdd793ab0c50c0db518cba1ede3ea036
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29429
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
- 'port80 intprint' toggles printing port 80 codes in interrupt
handler (turning that off speeds up port 80 capture a bit, if you're
sending port 80 codes very rapidly)
- 'port80 flush' flushes the log buffer
- log buffer expanded to 256 entries
- log buffer tracks S3->S0 power state transitions, so you can tell
where each boot starts
This uses ~500 bytes more RAM on the EC, but we've got piles of RAM
(with this change we're using 17KB out of 32KB).
BUG=none
TEST=manual
- boot system
- port80 -> prints data
- port80 intprint -> now disabled
- reboot; wait for reboot; no port80 debug output during boot
- port80 -> prints data from previous boot AND this one
- port80 flush
- port80 -> nothing in log
Change-Id: I64ee72fb13ab0fdd85d04b9640b5390fdac31400
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29420
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
To save power, make the EC hibernate after we go into G3 for 24 hours.
BUG=chrome-os-partner:9386
TEST=Use "hibdelay 5" to change the delay to 5 seconds.
Remove AC power, power down and check device hibernates after 5
seconds in G3.
Connect AC power, power down, wait for G3. Remove AC power and
check device hibernates after 5 seconds.
Change-Id: I6fb907c904798076a763f22bd35f53f7424d6200
Reviewed-on: https://gerrit.chromium.org/gerrit/29400
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
It is possible that power LED goes off while AC still connected. Let's
set power LED periodically to aviod this problem.
BUG=chrome-os-partner:10386
TEST=Disconnect power LED while leave AC connected. Check LED goes off.
Connect LED again and check it comes back after few seconds.
Change-Id: I2a199446be5da772af8027b735b9f431f697bacd
Reviewed-on: https://gerrit.chromium.org/gerrit/29403
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
CONFIG_FW_RW_OFF is already relative to the base address of the flash,
we don't need to substract it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=on Snow, run with CONFIG_VBOOT and CONFIG_VBOOT_HASH activated and
see the hash is correctly computed and display.
Change-Id: I1643b07a59459baa973bfd7ee80cbf98963a85d4
Reviewed-on: https://gerrit.chromium.org/gerrit/29276
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Prints all x86 signal power state transitions at interrupt level, so
we can see lines toggle more precisely.
BUG=chrome-os-partner:12229
TEST=manual
1. power on system
2. no debug output that looks like [501.001742 x86 in 0x563f]
3. reboot
4. x86indebug 0xffff
5. power on system
6. should see lots of lines that look like [501.001742 x86 in 0x563f]
Change-Id: Ie3b346ee4d4beee3f13ac1245f1eb022b48dabf4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29192
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the user is logged in a closes/opens the lid of the laptop the
lid_changed flag gets set, but never cleared. Normally, it would get
cleared when it powered back on from being opened, but without powerm
running or is the machine is only suspended, then that never happens.
This fixes the problem by additionally clearing the flag whenever the
computer is powered down. This forces the computer to not turn on
based on anything that happened to its lid before it was turned off,
which is the behavior you'd expect.
BUG=chrome-os-partner:12189
TEST=Log in to your Chomebook completely. Close, then open the lid.
Shut the computer down. It should stay off now. Once it's back on
close the lid and confirm that it still suspends correctly. Now
open the lid and make sure it turns back on. Repeat these steps, but
kill powerm first.
Change-Id: I2275b3125115b4eacc6a5d074978d7a1d51b0695
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29111
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Prints when a host command returns an error code.
When 'hcdebug on', hex-dumps the host command params and response.
BUG=none
TEST=manual (> is ec console, $ is root shell)
$ ectool gpioget foobar --> EC console shows error 2 returned
> hcdebug on
$ ectool hello --> EC console shows params and response as hex
> hcdebug off
$ ectool hello --> no extra output on EC debug console
Change-Id: I2dbc77be5b59125f394d970cf1c83c2a976e926e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
