Instead of how it is now, where the boot key combinations are only
tested if it was a keyboard-controlled reset. This is important for
testing/debugging EC software sync, which has a tendancy to blow away
your RW EC as soon as you flash a test EC and it reboots. Now you can
hold down refresh+downarrow while flashing.
This does not affect keyboard-controlled dev switching, since that's
done in the AP after the EC boots. It also does not add any new key
combos, just makes it possible to trigger the existing ones without a
Silego reset.
BUG=chrome-os-partner:13753
BRANCH=link
TEST=manual
1. Boot normally. Works.
2. Power+Refresh. Boots normally.
3. Power+Refresh+Esc. Boots to recovery.
4. Power+Refresh+Down. EC reboots, system powers down.
5. Hold down Esc and reboot from EC console. Boots normally.
6. Hold down Refresh+Esc and reboot from EC console. Boots to recovery.
Change-Id: Iabe4fd13589428a40b83f591ea679cbc6f83959d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32425
Reviewed-by: Simon Glass <sjg@chromium.org>
Increase stack size slightly for vboot hash task since the vboot
SHA256 function allocates ~300 bytes of stack data. Reduce stack size
for watchdog, power LED, and a few other tasks with simple call trees
where we can be sure an error path isn't going to blow past the
reduced stack.
This frees up ~1KB of RAM on STM32.
BUG=chrome-os-partner:13814
BRANCH=all
TEST=boot system; shmem should show more unused RAM; taskinfo should show
tasks still have unused stack
Change-Id: I47d6b77564a0180d15d86667cc0566a8919b776e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32608
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a precursor to supporting task-specific task sizes. I've
benchmarked this vs. the current stack pointer method; no measurable
performance difference.
BUG=chrome-os-partner:13814
TEST=boot EC; taskinfo; if it boots and doesn't print garbage, it worked
BRANCH=all
Change-Id: Ia326c3ab499ac03cce78dbacaa52f735601a171e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32603
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This (re-)configures the I2C arbitration lines as floating inputs
when the AP powers off, and restores them strictly before the AP
powers on. This is intended to prevent leakage when the AP is off
and arbitration is not needed. This CL does not impact the AP
on/suspend case.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:12573,chrome-os-partner:12381
TEST=manual (see notes below)
- PA4: SPI1_NSS / AP_CLAIM, input w/ pull-up when AP on
- PA6: SPI1_MISO / EC_CLAIM, output when AP is on
- Both floating when AP off
8 = input with pull up/down, 4 = floating input, 1 = output
AP off (before this CL):
> rw 0x40010800
read 0x40010800 = 0x41484144
> gpioget SPI1_NSS
0* SPI1_NSS
> gpioget SPI1_MISO
1 SPI1_MISO
AP off (after this CL):
> rw 0x40010800
read 0x40010800 = 0x44444144
> gpioget SPI1_NSS
0* SPI1_NSS
> gpioget SPI1_MISO
0* SPI1_MISO
AP on or suspended (before and after this CL):
> rw 0x40010800
read 0x40010800 = 0x81484144
> gpioget SPI1_NSS
1* SPI1_NSS
> gpioget SPI1_MISO
1* SPI1_MISO
Additional testing:
- "pmu 10000" and "cros_test i2c" in u-boot only showed the FET2
control changing (as expected).
- "pmu 10000" and "while [ 1 ] ;
do i2cdump -f -y -r 0-24 4 0x48 b ; done" and ran
"suspend_stress_test" for a couple dozen iterations. The
registers only changed as expected (FET1 and FET6 turned off
when suspending).
Change-Id: I72f5cb1883d01b1faad6c2db65dfa09d477e1885
Reviewed-on: https://gerrit.chromium.org/gerrit/32078
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Previously, the i2c init code would only preform a software reset of the
i2c peripheral it is initializing when it was already BUSY. It turns
out it's always BUSY and the init functions are now used in two other
places where they always want the software reset as well, so this pulls
out the conditional, and makes it always do it.
BUG=chrome-os-partner:13388
TEST=Standard i2c stress tests. Running a loop of i2cdumps from the AP
while looping i2c transactions on the EC run without any errors. Even
across multiple reboots, and jumping back and forth from RO to RW on the
EC via sysjump while the AP is still stressing the bus.
BRANCH=snow
Change-Id: I6b3aaae0042844033bb04cf5cb4171c8be041ad9
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32397
Reviewed-by: Simon Glass <sjg@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>
The I2C peripheral on the EC can get confused if there is a very
specific kind of noise introduced to the line. This can be manifested
by jiggling the battery jack. It gets the I2C into a state where
everything seems fine outwardly, but the device refuses to even transmit
START bits on the line. It appears that one of the stray pulses on the
i2c bus gets the device off set from the actual bytes, leaving it
misinterpreting everything and waiting forever. In this case, there is
only one way to recover (as you can't directly access these aspects of
the internal state) and that is to do a software reset of the i2c
peripheral.
Here I add some code to check for the condition where the EC was unable
to even send a START bit, and do a software reset of the i2c to recover.
BUG=chrome-os-partner:13161
TEST=With a faulty-battery-jack-board: Boot board, test that i2c works
by running "pmu" on the EC console. Jiggle battery jack repeatedly
until errors are displayed on console. Try to run pmu again. Make sure
that it recovers gracefully, and do this many times.
BRANCH=snow
Change-Id: I91b8ef0c6f6079bc63f4a6a1bc91f67d19db9fc0
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32286
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If the EC got reset while some device on the bus was midway
through a transaction, the bus may we wedged and all of our i2c
transactions will fail. Try our best to unwedge the bus at
bootup. Do this even if the bus doens't look wedeged because
some device on the bus may be in a quiescent state at the moment
but be waiting to pounce on the bus when it sees the clock start
running.
BUG=chrome-os-partner:13378
TEST=Capture scope trace in normal bootup
TEST=Capture scope trace in failure bootup with an extra print
statement in the code when scl/sda were not high at bootup. Forced
this case by looping i2c transactions to tpschrome and rebooting
midway through.
BRANCH=snow
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
(Note: Credit for this patch goes to Doug, I just uploaded the
initial work-in-progress version to gerrit --dhendrix)
Change-Id: I8da69b5294160048f91461159c039f8f2093e971
Reviewed-on: https://gerrit.chromium.org/gerrit/32168
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
The UART probably shouldn't have such a high priority. Reduce it to
below that of comms driver interrupts.
BUG=none
BRANCH=none
TEST=manual
Boot and see that UART console still functions
Change-Id: If906c9c4c37617d076ad8415d126b50f52d8b09e
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32077
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There are a number of ways for the i2c to fail, and some are quite
rare and have thus been overlooked. It's easy enough to handle these
rationally, but we have to check for them. This checks that the i2c
peripheral is actually in slave mode when it gets a slave event firing
(stopping it from accidentally sending garbage on the tail end of
another request) and makes sure a STOP bit is sent in the event that the
BUSY signal isn't set at the moment we check it (if we check it at the
moment that it is sending a 1, it may not be set). Finally, if the i2c
can't send a STOP bit, the peripheral is reset to get it back to a sane
state, specifically it needs to not be stuck in master mode forever.
BUG=chrome-os-partner:13380
TEST=Boot machine normally, from AP run "while true; do ectool version;
done" to start a loop of the long transaction that sends lots of
spurious reads too. Then on the EC, run "pmu 10000" and then "battery
1000" to stress the bus from all sides. Once the EC is done, stop the
AP's side of the stress test, and make sure the bus is still
functioning. Tested the resetting, by making it reset the peripheral
every 150 times, and confirmed that the following transfers work just fine.
BRANCH=snow
Change-Id: I265b3cddd25e1fd6ab4e8cf9c7290c875fad89f8
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32188
Reviewed-by: Doug Anderson <dianders@chromium.org>
This only adds support in the EC; it doesn't add an ectool command.
We'll add that later. This also fixes a bug where the reserved byte
in the panic data structure wasn't being set to 0.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. crash unaligned -> system crashes
2. hostcmd 0xd3 -> returns a hex string 01010100...506e6321
3. hostcmd 0xd3 -> returns a hex string 01010500...506e6321
Change-Id: I1de8e19c44c835055d893986b42d152dc704c35f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32183
Reviewed-by: Simon Glass <sjg@chromium.org>
Old i2c code uses protocol v1, which cannot handle veriable-length
response (unknown lenght to calculate checksum).
So, upgrade to procotol v2 anyway since command v1 needs protocol v2.
BUG=chrome-os-partner:11608,
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BRANCH=None
TEST=on snow, and both command v0/v1 are working on protocol v2.
ectool version
ectool hello
ectool echash
ectool flashinfo
ectool flashprotect
ectool flashwp
Change-Id: Id8532fe51359dce18839d37de8a8c8669754041c
Reviewed-on: https://gerrit.chromium.org/gerrit/31838
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
The TMP006 IR sensors are calibrated against the temperature measured on
the *external* side on the casing using a thermocouple stick at the
vertical of the sensor.
The hinge sensor is sending back strange values, and the Tobject from
there should not be trusted.
The DC-Jack C-case sensor is not calibrated (and will be removed soon).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=on Link DVT, compare EC temperature values against thermocouple
readings.
BRANCH=link
Change-Id: I03375dd1c2f3a0aa56b0d2f343dad3b8f7581bc2
Reviewed-on: https://gerrit.chromium.org/gerrit/32156
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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
Now that the panic stack goes at the end of RAM, there's no overhead
to using it on all platforms. When it was a dedicated block of
memory, we needed to turn it off on some low-RAM platforms
(e.g. Snow).
BUG=chrome-os-partner:7466
TEST='crash divzero' or 'crash unaligned'; should print dump and reboot
BRANCH=all
Change-Id: Iddfeb134e237538215df51abe4e16ee831b3ae2d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32037
Reviewed-by: Simon Glass <sjg@chromium.org>
This is in preparation for saving panic data across reboots for later
retrieval.
BUG=chrome-os-partner:7466
TEST='crash divzero' or 'crash unaligned'; should print dump and reboot
BRANCH=all
Change-Id: I997d160b00d03759eb9c69b53ab0f7a5ae144183
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31951
Reviewed-by: Simon Glass <sjg@chromium.org>
Added a warm reboot key combination that resets the CPU while preserving
RAM contents. This will be helpful in debugging CPU/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:12780
TEST=reboot the system using alt-volume_up-r key combination. Upon
rebooting, check pstore contents with "cat /dev/pstore/console-ramoops"
and ensure that they are same as dmesg from the previous boot.
BRANCH=link
Change-Id: I0ec835a4646f442997c04dc3a086d4fac0cf01cf
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31992
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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 re-factors i2c initialization to simplify it and make it follow
the correct order. This is intended to fix a bug where the I2C lines
could be driven low for no good reason on EC startup, potentially
causing issues with other devices.
The ordering should be:
1. Setup pins as inputs on EC startup.
2. Initialize I2C module(s)
3. Re-configure pins as alternate function.
(Thanks to dianders for pointing out this bug)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:13443
TEST=Tested by examining scope traces during EC reboot
Change-Id: Ibb845f3fd538da387132b1c822929f8613de077d
Reviewed-on: https://gerrit.chromium.org/gerrit/31647
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
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
gpio_set_alternate_function() for STM32F is not used, and even if
it were it would be incorrect. So for now it just takes up space.
Unlike STM32L, alternate functions rely on toggling bits in AFIO
remapping registers rather than setting a simple AF number. This
would make writing a working version of this function trickier,
and it may not be worth the effort.
Signed-off-by: David Hendricks <dhendrix@chromum.org>
BRANCH=snow
BUG=none
TEST=locally compiled for snow
Change-Id: I2ce1e7aba2760a94819500af4e322812f3346ad3
Reviewed-on: https://gerrit.chromium.org/gerrit/31630
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This prevents the host from rewriting them during the checksum operation.
BUG=chrome-os-partner:13202
TEST='ectool version' should still work
BRANCH=link
Change-Id: Ib44f45b027c0a54ba40f70052728ba427dc71849
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31511
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
