This was needed because we could not do a clean
reset with CF9 and were relying on the keyboard
reset pulse to trigger a cold reset.
However it has the downside of causing a kernel
panic to be a cold reset and the kernel panic
information in memory is lost.
Now that we have a VR workaround this hack can
be disabled and the keyboard can instead issue
a warm reset.
BUG=chrome-os-partner:11036
TEST=manual
1) install this EC on a Link device and boot
2) log in and execute "echo panic > /proc/breakme"
3) after reboot look for kernel entry in /var/spool/crash
Change-Id: I1134618f0a202d37aaae69a1d857fa8853a7e52c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27722
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- add settings for IR3570A
- disable low voltage fault and keep ready signal when SVID=0.
(on IR3571 and IR3570A)
- match IR3571 settings with IR3571_REV7_DRC_6_28_12 to ensure we are
meeting all power requirements.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8397 chrome-os-partner:10171
TEST=on Link EVT with IR3571 and Link EVT reworked with IR3570A,
test reboot and RC6+.
Change-Id: Ibe34e3c6f0de1e6a08d526fe5fce743feb42645c
Reviewed-on: https://gerrit.chromium.org/gerrit/27504
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When battery is nearly full, battery sometimes demands for very low
current and we are actually trickle charging. This causes the last part
of charging process very long, but the actual charged amount is only few
mAh. Let's set power LED to green in this case so that user doesn't feel
the device is charging forever.
BUG=chrome-os-partner:11248
TEST=Charge the battery to nearly full. Disconnect and connect AC power.
Check the power LED is green when we are trickle charging.
Change-Id: Ide108778232e9f1d3abe6b61af7518af25040d10
Reviewed-on: https://gerrit.chromium.org/gerrit/27264
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Uncomment back the old code and fix the bug of WRP bit definition and
also write_opt().
Note that to make this functional, wp_pin_asserted() always returns true.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: Ic09d3346ca68a2700697ff863f0fa08525129b11
BUG=chrome-os-partner:9849
TEST=run on lucas.
> flashwp set 0 0x1f000
> flashwp lock
> flashinfo # ensure the setting is right.
stm32mon -r to read the firmware.
stm32mon -w to write a different image.
stm32mon -r to read again and compare the firmware is non-changed.
> flashwp unlock
Command returned error 1
stm32mon -u to unlock write protection.
Reviewed-on: https://gerrit.chromium.org/gerrit/27503
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Tested-by: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Enhance the power command to support turning power on/off.
Do this by requesting the state of the main power control loop,
rather than hacking in new states or flags.
BUG=chrome-os-partner:11427
TEST=manual
Try 'power on' and 'power off' and see that it obeys.
Change-Id: Ie6db41dda16176818510f8902ab803e165494424
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27654
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It is useful to be able to see the current AP power state, and x86
has a command for this. Add one for gaia.
BUG=chrome-os-partner:11427
TEST=manual
(start with power off)
> powerinfo
off
(press power button)
> [batt] state idle -> pre-charging
AP running ...
Power button released
Setting pwron timer 10038870
powerinfo
on
> Releasing pwron
(after kernel boots, make device go into suspend by typing this at
kernel command line:
type echo mem > /sys/power/state)
> powerinfo
suspend
Change-Id: I3244b3a7fd0b6dd689f3470fb97ffe5a72c8d8f9
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27653
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Should print what command is being executed, to help debug software sync
BUG=chrome-os-partner:11087
TEST=power on system, look for updated debug message, for example
[1.636893 Executing host reboot command 5]
Change-Id: Ib543fc265fe881dc2089119ab3c0a52b0fce3b4d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27659
Since flash_common calls the top bank of flash pstate, use the same
nomenclature in config.h
BUG=none
TEST=build link
Change-Id: I22efe7d0fd3a24bc0b2b4a6632406f0e1e529dc6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27662
When system is off or suspended, board_i2c_claim() should not wait
for AP's signal.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:11285
TEST=manual
Put AP into suspend
Type 'i2c r 0x90 0' and see that no arbitration error is obtained.
Change-Id: I22243457fc29bc6c88f413ce0660c700e54f6761
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27498
The SUSPEND_L GPIO is marked interruptable, but this apparently
does not work, and the gaia_suspend_event() function is not updated as expected.
As a workaround, check the GPIO value on ever call to
chipset_in_state().
BUG=chrome-os-partner:11285
TEST=manal
Using new 'power' command check that the state updates when the AP
is in suspend from 'on' to 'suspend'.
Change-Id: I9c520e69b9910c649bf6d8381ee167da6facc634
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27652
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:11149
TEST=make link, snow, bds; on reboot,
sysjump rw
sysinfo <- should indicate current image is rw
Then on root shell,
ectool version <- should indicate rw
Change-Id: I833fcb814165379dd044e4cb46ae338e5da81212
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27660
All of our current EC configs have RO and a single RW image. Calling
that image 'A' is confusing, particularly when combined with EC
software sync (where the RW image is updated from either the A or B AP
RW firmware). So, rename it.
This changes all the build artifacts and constants. Internal EC
commands and host commands still refer to A/B; that will be fixed in
part 2.
BUG=none
TEST=build link, snow, bds
Change-Id: Icfed4914745f0799bb71befb6a6563cfd8bc90ab
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27649
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For EC update test, we produce binary-wise shifted image. To make it
easier to tell if update has succeeded, let's append "shift" to the
verison in this image.
BUG=chrome-os-partner:10264
TEST=Build shifted image and check the version string.
Change-Id: I16187611cf61fc97a74bc3707a77ad9ad5274f37
Reviewed-on: https://gerrit.chromium.org/gerrit/27577
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
I have a system with bad temperature sensors and the EC is
constantly shutting the system down, but provides no
visible indication that it is doing so.
I have serious concerns about the EC behavior in this case
as it seems to be doing things it shouldn't. However just
providing indication via the console about what it is doing
is at least useful for development and debug.
BUG=none
TEST=boot on system with bad temp sensors and see that
the EC indicates it is initiating a shutdown.
[14.008340 critical temperature; shutting down]
[14.008660 x86 power force shutdown]
[14.009153 LPC RESET# asserted]
Change-Id: I6beeb269a135bd8c245c0357670fe29648d48968
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27553
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is needed for flash pre-init to be able to hard reset to clear
uncommitted write protect flags without losing the reset flags.
BUG=chrome-os-partner:11368
TEST=manual
Use reboot and sysinfo commands...
1. reset with keyboard. flags -> reset-pin
2. 'reboot soft preserve' flags -> soft reset-pin power-on
3. 'reboot hard preserve' flags -> hard soft reset-pin power-on
4. 'reboot soft'. flags -> soft
5. 'reboot hard'. flags -> hard power-on
Change-Id: I6164a78d99c5c10330f90f651148c5795e7afdda
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27418
Reasons are really bitflags, not a single reason. This will make it
easier to implement flash protection on LM4, where hibernate is a
subset of power-on reasons.
Also added some additional flags we pass in a hibernate register so...
1) We don't recognize spurious RTC wake reasons
2) Hard reset via system_reset(1) is detected as a hard reset, not a RTC wake
BUG=chrome-os-partner:11368
TEST=manual
1. Keyboard reset = power-on reset-pin
2. Pull battery = power-on
3. reboot = soft
4. reboot hard = power-on rtc-alarm
5. hibernate 10 then push power button = power-on wake-pin
6. reboot 3 sec later = soft
7. hibernate 1 = power-on rtc-alarm
Change-Id: Icbbdbcf6dfd13c8a6a4f80a23f64cebebbfba26e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27417
According to its datasheet, LM4 doesn't support vectreset, but does
support sysresetreq. Using sysresetreq properly resets all
peripherals and cleanly resets the LM4.
Auto-erase makes the flash command faster.
BUG=none
TEST=flash_link_ro, flash_link_a, flash_link, all with different images
Change-Id: I80b72de2ee0f42cee1b0f2f2a53062384d2c29aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27416
Link battery pack specification suggested a lower charging current
when voltage pass 8.0V. But the lowering the current in constant
current phase leads voltage drop. And the battery goes back to
high current zone, < 8.0V.
This CL adds a 10 seconds debounce time to prevent charging current
change too quickly.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:9572
TEST=manual
watch battery V+ on oscilloscope when charging voltage cross 8.0V
Change-Id: I002f941e33b029e38f813ab2e292c6b73a054352
Reviewed-on: https://gerrit.chromium.org/gerrit/27275
Commit-Ready: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Kernel and U-boot define it elsewhere, but coreboot doesn't. So put
it here for greatest compatibility.
BUG=none
TEST=if it builds it works
Change-Id: I595910e9198e37bc97d23cd4c249454e1ed64cd8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27375
Changed the parameters from int to uint32_t (which is how it was called
anyway).
BUG=chrome-os-partner:11045
TEST=manual
No visible change. Nothing should break.
Change-Id: I4fbe34f67df7d37f5039987a7a89e626916d6eb6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27382
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Make sure that a negative 'num' param won't be accepted if passed by a
malicious caller.
BUG=chrome-os-partner:11048
TEST=manual
No visible changes, everything should continue to work.
Change-Id: I8128d24adc99e5ff954a6b8065e1bfa8bf20630e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27386
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Make sure it doesn't run off the end of the I2C device list.
BUG=chrome-os-partner:11051
TEST=manual
No visible changes. Everything should continue to work.
Change-Id: I43182361cda6be578e57acef01afb27260cea80a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27390
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The charger task relies on calc_next_state() performing a delay before
returning. My reading of the code suggests that this doesn't happen
always. For example:
When pre-charging:
if (battery_temperature(&batt_temp) == EC_SUCCESS)
return ST_CHARGING;
When discharging and capacity is low:
/* Check remaining charge % */
if (battery_state_of_charge(&capacity) == 0 && capacity < 10)
return notify_battery_low();
I would like to suggest that the code be refactored to more like:
int next_checkms = 5000; /* next time to check battery */
while (1) {
int action = ACTION_NONE;
err = get_state(&state);
if (!err) {
action = calculate_action(&state);
err = perform_action(action, &next_check_ms);
}
usleep(next_check_ms * 1000);
}
so that the delays are really clear, the state is all read at once,
there is no reliance on earlier state, and we always delay even on
error.
In the meantime, this CL inserts a mandatory 5 second delay in the
loop, which should prevent the charger task lockup.
BUG=chrome-os-partner:11285
TEST=manual
(please do this test before committing)
1. boot to kernel, see that battery can be seen
2. suspend and resume device
3. see that the charger loop does not cause an EC watchdog reset and
AP power off/reset. There should be no watchdog warning message on the
EC console.
Change-Id: I141e374933c4dc0ec60bcdccf96443f57067c585
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27353
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Ready: Katie Roberts-Hoffman <katierh@chromium.org>
These commands are used in factory test. If system is locked, GPIO
commands are disabled for security reason.
BUG=chrome-os-partner:11164
TEST= - 'ectool gpioget enable_backlight' gives 1.
- 'ectool gpioset enable_backlight 0' turns off display.
- Lock system. Check these commands return error.
Change-Id: I3ea41285075ebe963ba7d30e4ae183cef9b1c105
Reviewed-on: https://gerrit.chromium.org/gerrit/27019
Commit-Ready: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
This command should only be accessible when flash write protect is
unlocked.
BUG=chrome-os-partner:9716
TEST= - Check we can charge and discharge normally.
- Connect AC and force idle. Check battery current is 0 mA.
Change-Id: I74a318c1f5562d6a23b722736615fd1f883dc35a
Reviewed-on: https://gerrit.chromium.org/gerrit/27259
Commit-Ready: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
This is set when the EC boots and sees the recovery key combo.
This is preferable to the memmap'd keyboard recovery switch, which the
host has no way of clearing. The idea is that the host RO firmware
reads this event and sets the recovery reason.
I will be removing the memmap'd keyboard recovery switch once U-boot
and coreboot check this new event.
BUG=chrome-os-partner:10034
TEST=manual
1. power+esc+refresh; should see this even in EC log
[0.000838 event set 0x00004000]
(time of event may vary)
2. reboot EC; should NOT see the event
Change-Id: Id0672749f63c5022624a72ec91d30dcadfea5ef8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27328
Now both copies of the event state live in host_event_commands.c, and
lpc / memmap just shadows the main copy.
BUG=chrome-os-partner:11172
TEST=manual
Boot system. should see events 0x2000, 0x80, 0x08 get set and then cleared.
At U-boot prompt, type on keyboard. Should set event 0x1000 get set,
but only on the first keypress (because U-boot doesn't consume that
event).
Then from EC console,
hostevent clear 0x1000 -> see event 0x1000 clear
hostevent clear 0x1000 -> no debug output (it's already clear)
hostevent clearb 0x1000 -> see event copy B 0x1000 clear
hostevent clearb 0x1000 -> no debug output (copy B is already clear)
Change-Id: I855c035865649ba1490cd9027157d5bcdcc9895f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27321
U-boot and ectool need this to see what events have occurred, in a way
which doesn't conflict with ACPI/SCI/SMI.
BUG=chrome-os-partner:11172
TEST=manual
- boot EC
- look at event set / event clear debug output; that's for copy A
- from ec console,
hostevent -> events=0, events-B = 0x2088
hostevent clearb 0x2000 -> events-B = 0x88
Change-Id: If842b157914426df593d82af2bfb08a923caa34b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27317
Both EC and ectool are still backwards-compatible to the old interface.
BUG=chrome-os-partner:11275
TEST=manual
From U-boot prompt: mkbp hash // test old host talking to new EC
From root shell: ectool echash // test new host talking to new EC
You can also update just the OS and use an old EC, and verify that
'ectool echash' still works, which tests a new host talking to an old
EC.
Change-Id: I2afbb208cb16836f842ba119b74b1ab6a38ce5d5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27313
Saves 2 params being passed around needlessly.
BUG=chrome-os-partner:11275
TEST=mkbp hash from u-boot console should still work
Change-Id: I958e4a09f16413e4d051e278dc0384aa9b791aa4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27312
And retain compatibility for old requests.
BUG=chrome-os-partner:11275
TEST=from u-boot prompt, 'mkbp hash'
from root shell, 'ectool flashread 0 68084 /tmp/foo'
then compare to first 68084 bytes of ec.bin
Change-Id: Id82068773703543febde79fc820af7486502e01f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27226
These commands are only available when system is unlocked.
BUG=chrome-os-partner:9716
TEST=When system is unlocked, check we can read/write I2C bus.
When system is locked, check the commands return error.
Change-Id: I8c4a8a42ab13d62c7e47bf33e2a7abc6f61e43fa
Reviewed-on: https://gerrit.chromium.org/gerrit/27254
Reviewed-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
The spec of link internal battery pack changed. This CL adds
parameter for new pack, and renames vendor specific source file
accordingly.
The new trickle charging current limit should fix the slow
pre-charging issue.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=chrome-os-partner:11298,10201
TEST=manual
The minimum trickle charging current should be very close to
0.01 C (85mA). Previous battery pack firmware uses 5mA in pre-
charging.
Change-Id: I0bad679db7dd087894297e6eb0e85c9b12fdf444
Reviewed-on: https://gerrit.chromium.org/gerrit/27256
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
This is necessary for an imminent change which passes version data
from the host bus (LPC/I2C/SPI) into the host command handler.
BUG=chrome-os-partner:11275
TEST=from u-boot prompt, 'mkbp hash'
Change-Id: If34d0d7c6dc320ad5632becf512c30900fd61aca
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27190
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added version mask field to DECLARE_HOST_COMMAND() because it's
convenient to do so when I'm touching all host command
implementations, but all commands simply declare version 0 and nothing
checks it yet. Will add version support in a followup CL.
This change is internal to the EC; it does not change the data sent
over the host interface.
BUG=chrome-os-partner:11275
TEST=manual
ectool version && ectool echash; should get sane data from both
ectool flashread 0x80 0x40 /tmp/foo && od -tx1 /tmp/foo
should match data from offset 0x80 of ec.bin (od -j128 -n64 -tx1 ec.bin)
Change-Id: I5699f72b8d5e1ac23929353c9a34158d76c44206
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27172
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
