We recently changed the way host messages are passed to the EC to make it
work nicer across I2C. When we did, we updated all the internal structs
except those used for lightbar commands. This CL updates the lightbar
commands too.
BUG=chrome-os-partner:11277
BRANCH=all
TEST=manual
This shouldn't change anything, but you can ensure that by poking at the
lightbar manually. On Link, run this from a root shell:
ectool lightbar seq stop
ectool lightbar 4 ff 00 ff
ectool lightbar seq run
With the first command, the lightbar pattern should freeze.
With the second command, it should turn magenta.
With the third command, it should resume pulsing as before.
Change-Id: Ic5dc4c827b3b4459288d7d9bd7d06af8a5176b3c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33798
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some designs will have the PMU not directly connected to the AP but
behind the EC.
For easier bring-up, it's nice to be able to force power rails.
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10912 chrome-os-partner:14324
TEST=manual
On snow, switch on and off the backlight using the API
BRANCH=none
Change-Id: I74e05308043546cb11f7f2cdbe644944c0a0a35e
Reviewed-on: https://gerrit.chromium.org/gerrit/26234
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
At other times, the battery should follow the normal charging rules.
Using the trickle charging logic has 2 problems here:
1) Battery voltage is near maximum, so trickle charging logic starts
out with voltage less than the actual battery voltage, and less than
the charging spec.
2) Trickle charging only exits when battery requests more current
(which it won't if it's near full) or on 4-hour timeout, not when
battery reads 100%. So this can cause overcharging.
Note that we still limit the charging current to what the battery asks
for, but if that's less than the minimum current from the charger we
simply provide the minimum and don't fiddle with the voltage since
that may interfere with the battery's ability to determine it's fully
charged.
BUG=chrome-os-partner:14402
BRANCH=link
TEST=manual
1. charge laptop to full
2. quickly unplug and plug charger
3. look at debug log; should either not charge at all (if charge is currently
100%) or charge at 8400mV (if charge is less than 100%).
Change-Id: Ifd5a9eb2e9bb791f74196713b645d1c9211eb736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33729
Reviewed-by: Rong Chang <rongchang@chromium.org>
the PMU VACG signal used to detect AC state is connected to a GPIO, so
it's a board specific configuration.
On top of that, Daisy variants have custom logic on that line which is
not present on the next boards, so we need to update it before doing BSP
for next-gen boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14313
TEST=make BOARD=snow && make BOARD=daisy
on snow EC console, type "pmu" command with AC plugge and unplugged, see
that the "ac gpio" line reflects the right value.
BRANCH=none
Change-Id: If1e19b89b2f2de45d8dddc8340931e56c5f7f0a5
Reviewed-on: https://gerrit.chromium.org/gerrit/33630
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This solves the problem where the AP updates EC-RW as part of software
sync, then tells the EC to jump to EC-RW. On the next boot the EC
still returned the saved old RW hash, causing a needless cold boot.
This change is backwards/forwards compatible; existing RO code will
simply save a hash new RW code won't look at, and existing RW code
already knows to recompute the hash if the RO code didn't save it.
Hash computation is done in the background and takes ~350ms, so this
should have no noticeable effect on performance.
BUG=chrome-os-partner:13511
BRANCH=all (not needed for FSI, since RW code with this change will do
the right thing with existing RO code)
TEST=at the EC console, "sysjump RW" and look at the EC debug log for
"hash done".
Change-Id: Ie5255727b9d896b7c4e4f537e91d831682afc7f6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33634
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
CL 31370 almost fixed the power on bug except in the sysjump mode. While
EC firmware is being updated, the EC would sysjump between RO and RW.
So that gaia_power_init() would be called and accidentally set auto_power_on
to 1, which makes the next shutdown reboot instead. Thus, clear the
auto_power_on if the system is already on.
Also added more debug for future debug and fixed the XPSHOLD message output.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BRANCH=Snow
BUG=chrome-os-partner:14183,
TEST=On snow:
; reboot successes. power on 1 (XPSHOLD seen)
ssh root@snow_ip "ectool reboot_ec RO; ectool reboot_ec A; reboot"
;
; system halts (no more automatical power-on, ending loop 3)
ssh root@snow_ip "ectool reboot_ec RO; ectool reboot_ec A; shutdown -h now"
Change-Id: Iad54377d53701b986ff4f0c9996f02f8f17f070a
Reviewed-on: https://gerrit.chromium.org/gerrit/33601
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
Previously, after the first error when trying to reset the pmu over i2c,
the ec would immediately give up and force a hard reset. Since i2c can
be a little flaky from time to time, to prevent unneeded resets this
allows the EC 3 attempts to configure it nicely it before it forces the
whole system to reset.
BUG=chrome-os-partner:14156
TEST=Boot machine successfully multiple times. Add a line in to force a
failure whenever the pmu is accessed to simulate a total failure and
check the EC logs, it should try 3 times on startup and on shutdown
before finally resorting to a hard reset. If you add a fake failure that
only triggers once, the machine should still turn out without incident.
Without any fake failures, everything should work as normal.
BRANCH=snow
Change-Id: I1f453e9a6acc59d63e4cc80cffb58684f104ca6d
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33466
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Otherwise the host needs to tell the EC how big this image is (which
it knows, but it's inconvenient for it to provide).
BUG=chrome-os-partner:13511
BRANCH=all
TEST=manual
1. ectool echash recalc ro -> prints hash of RO code (offset 0)
2. ectool echash recalc rw -> prints hash of RW code (offset non-zero)
In each case, size should be an exact number and not the size of the
whole RO or RW section. So for link, output should be something similar to:
localhost ~ # ectool echash recalc ro
Hashing EC-RO...
status: done
type: SHA-256
offset: 0x00000000
size: 0x00012a64
hash: 03a66c076d6dd4b4aa9ed6386713f45291f5143f9af2093003e632485899daf1
localhost ~ # ectool echash recalc rw
Hashing EC-RW...
status: done
type: SHA-256
offset: 0x00014000
size: 0x000123d1
hash: 0d6225e70f0b1e0419e987370371e00783f945827ef25915a8fb8549159dd2a4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
3. At ec console, 'hash ro' or 'hash rw' should regenerate the same
hash values printed above.
Change-Id: I3f6085d29927b8cdf9dabc6930f0fdc7222bd8b5
Reviewed-on: https://gerrit.chromium.org/gerrit/33123
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
This allows recomputing hash after EC boots.
BUG=chrome-os-partner:13988
BRANCH=all
TEST=manual
1. hash 2048 2048
2. hash 0 2048
3. hash -> hash value should be different than in step 1
Change-Id: Id66d0655a143b5190b5d8949b0fa9a18dbbc05f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33118
Reviewed-by: Simon Glass <sjg@chromium.org>
Previously this was in lightbar.h. ec_commands.h should not require
other header files.
Also make brightness local variable static, so it won't leak outside
lightbar module.
This is simply code cleanup; values themselves have not changed.
BUG=none
TEST=if it builds, it's fine
BRANCH=none (not required in link branch since it's just cleanup)
Change-Id: I5722fb677fcec99e0826e3dfc0b22033781b576f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32815
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
The moving average window contains previous discharging state of charge
values after state change. This change resets the index to make it
calculate only new battery readings.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13846
TEST=none
Change-Id: Ifc6c6208dea8edf262e7294972d7321501b709e2
Reviewed-on: https://gerrit.chromium.org/gerrit/32865
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This logic doesn't really belong in drivers, since to enable another
driver (like SPI) we must repeat it all. This is tricky if we enable
both I2C and SPI.
Move the logic into host_command.
BUG=chrome-os-partner:10533
BRANCH=none
TEST=manual
Use U-Boot to test comms status functionality on snow:
SMDK5250 # mkbp write rw 40000000
SMDK5250 # mkbp erase rw
SMDK5250 # mkbp erase rw
Change-Id: I3f90aada80208cd0540be14525f73f980ad33292
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32075
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Report the reason for a power on, to assist with debugging.
BUG=chrome-os-partner:11307
BRANCH=snow
TEST=manual
Build and boot on snow
See that power on reason is now reported
> 0.003508 power on 2
[0.028674 AP running ...]
...
12.163780 ending loop 2
Shutdown complete.
[batt] state discharging -> idle
17.801167 power on 4
Overriding CHARGER_INT with CHARGER_INT on EXTI4
[17.825873 AP running ...]
17.826071 XPSHOLD seen
[batt] state idle -> discharg
Change-Id: I2044419b330a74d19d8c4e63fa8853aa477b4df1
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32301
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This makes build_info fixed-length so that it can be properly
transmitted via I2C. The host buffer size will be used, which may
in fact be quite a bit longer than necessary. Build info will be
truncated if it's longer than the max response size.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:11608
TEST=Tested on Snow, logic analyzer confirmed NAK and STOP condition
set properly after final byte transmitted via I2C (see BUG)
Change-Id: Iccae0f3c2905d442c8eebff42aa19bf940e5f71f
Reviewed-on: https://gerrit.chromium.org/gerrit/32290
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This would improve boot speed when compared to storing in eMMC because
initialing eMMC is slow.
So far other platforms do not have this need because CMOS is quite
efficient; thus it is left unimplemented in lm4.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:10660,13094
TEST=On Snow, see VbNvContext is preserved across power cycles (you have
to patch U-Boot to test this)
Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36
Reviewed-on: https://gerrit.chromium.org/gerrit/31832
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
It was putting the entire parameter buffer for a host command on the
stack. Now it uses shared memory.
BUG=chrome-os-partner:13613
TEST='hostcmd 4' should not cause a crash several seconds later
BRANCH=link (snow is also affected, but doesn't have enough shared memory to put the command buffer there either)
Change-Id: I8405d88857ee92a5cee429e156df5e645d5d864d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32181
Reviewed-by: Vic Yang <victoryang@chromium.org>
Old Snow board (non-MP) don't have the capability to hard-reset their
pmics unless they've been manually fixed to do so. This means that if
you have an old board, with a new copy of the EC on it and it tries to
hard-reset the system, it will hang forever and trigger the watchdog.
Since there's no way for the EC to check if the hardware fix exists on
its board, this adds a timeout after trying to reset. If the board has
the fix, it will reset before the timeout expires. Otherwise, it will
print a warning message before returning, to prevent it hanging.
Additionally, it also fixes the places board_hard_reset() is called to
deal with the new possibility of it returning.
BUG=chrome-os-partner:13508
TEST=On a machine with the hardware rework and one without it, go to the
EC console and run "pmu reset" to try and force a reset. The one with
the fix should reset immediately, and the one without should warn you
that it tried (and failed) to reset.
BRANCH=snow
Change-Id: I493122ee4da539f363a31f624ab9dd7db8068ec8
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32043
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Jump data now precedes the panic data, if any, in memory.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. boot system
2. sysjump rw --> display should stay on and keyboard should still work
(this verifies jump data is properly read across sysjump still)
3. crash unaligned --> system should reboot
4. panicinfo --> should print the same crash dump as before, with (NEW)
5. panicinfo --> ditto, without (NEW)
6. sysjump rw
7. panicinfo --> ditto, without (NEW)
Change-Id: I88285724e82a15553ab25877e3d8ec4c74a4dd5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32051
BUG=chrome-os-partner:13439
BRANCH=snow
TEST=manual
1. Ctrl+Refresh+Esc; should go to INSERT screen
2. Ctrl+D; should show TODEV (this confirms it's still possible to get into
dev mode the right way)
3. From EC console, 'sysjump rw'
4. Ctrl+D; should NOT show TODEV (this confirms the bug is fixed)
Change-Id: Ic4879cb0a7fc47527eac1a5a727f3225744ff880
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31932
This moves the PMU register initialization from pmu_init(), which gets
called whenever the EC reboots/sysjumps (even when the AP is running),
to a hook which will can called selectively when the AP is cold
booting.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13315
TEST=tested on snow - jumping between RO <--> RW no longer causes
the screen to turn off due to resetting FET control regs.
Change-Id: I5453bf86af50b84a05a259dc896f04d818b5641b
Reviewed-on: https://gerrit.chromium.org/gerrit/31740
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This CL updates ap_suspended usage so that it's only updated when it
makes sense to do so:
- Clear ap_suspended during power_off() since it can only be reliably
determined when the pull-up on PA7 is enabled (when AP is on).
- chipset_in_state() should not re-assign ap_suspended. That was a hack
to try to get around earlier brokenness. However, that does not
really work since SUSPEND_L can appear to be asserted when AP is
off and could cause ap_suspended to become inconsistent with the
actual AP state.
- When AP is on, ap_suspended should be managed by gaia_suspend_event.
When AP is off, ap_suspended should be 0 (
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13200
TEST=tested on Snow using "power" command at EC console
1. AP running
> power
on
2. after running powerd_suspend
> power
suspend
3. "power off" at EC console
> power
off
Change-Id: I88dad9f02d57fe7244bf607eea2088ee0b80b75a
Reviewed-on: https://gerrit.chromium.org/gerrit/31627
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>
"Auto" mode is observed to cause problems and thus is removed. This
leaves only three modes:
- Standard downstream port. USB 2.0 mode. 500mA.
- Charging downstream port. BC1.2. 1500mA.
- Dedicated charging port. BC1.2. 1500mA.
BUG=chrome-os-partner:11550
TEST=Check all modes work as expected. Check no discharge between the
first two modes.
BRANCH=link
CQ-DEPEND=31639
Change-Id: I41102a8bc3ac34ff9a1bf4e47c89cdb93a2c4eb5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31616
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
