As per James advice :
- increase fan speed at low temperature up to maximum "silent RPM",
this will give us more margin for later operations.
- lower the maximum fan RPM threshold to 86 C to try to lower CPU
temperature impact on skin temp.
- do not take into account "object" temp sensors, they are too random
at the moment.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=adhoc
Change-Id: I3b60570e33f82e4015c6588d9e2ae538a33ad14f
Reviewed-on: https://gerrit.chromium.org/gerrit/27921
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Now that we have hibernate ability, we can use this to perform a hard
reset.
BUG=chrome-os-partner:11579
TEST=Build success and working on 'snow':
'reboot' and see reset cause is 'reset-pin soft'.
'reboot hard' and see reset cause is 'hard'.
Build success on 'daisy'.
Change-Id: I18132eee2f0d574d7d1674f7be25249dbe19749d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27930
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds hibernate support to stm32f. Watchdog can wake us but cannot
be stopped unless system resets, so the longest time we can hibernate
for now is about 26s. And wake from wake pin is not working.
Nevertheless, we can use this for hard reset for now, and fix these
problems later.
BUG=chrome-os-partner:11579
TEST='hibernate 1' and see system wakes after 1 second. See reset cause
is 'hibernate'.
Change-Id: Iafa42012b59c12b70e18a7908c5d864c6e8bd2b4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27909
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use these functions to get charging state and battery percent. Use
power_ac_present() from power_button.h to find out if AC adapter is present.
BUG=chrome-os-partner:8039
TEST=none
Change-Id: Ied670c297be316b0b8fa56a450a1566470099b5b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27830
In theory this should be done by a kernel driver,
but there is already a suspend hook so it is easy
to have the EC turn off the backlight if it is
not done by the host.
BUG=none
TEST=manual
1) boot Link device
2) log in and run 'powerd_suspend'
3) observe that keyboard backlight is turned off
Change-Id: I10b83505d681f5b6d9cb32c1bef62dc21dd038e1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27721
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently the only way to exit force idle state is to unplug AC power.
Let's add a host command to do so.
Signed-off-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:9716
TEST=# ectool chargeforceidle 0
- Check nothing happened
# ectool chargeforceidle 1
- Power LED blinking green. Check current = 0.
# ectool chargeforceidle 0
- Power LED back to yellow. Check charging.
Change-Id: Ia8f504b6cf9f42b7d57af3ce2d240f3b00a095f1
Reviewed-on: https://gerrit.chromium.org/gerrit/27768
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
GAIA power module should send hook notification when power state
changes.
BUG=chrome-os-partner:11536
TEST=Hook a console message to HOOK_CHIPSET_SHUTDOWN and check this
message is printed to console when system shuts down.
Change-Id: I5bc3e69eeefeeda453526625887f852b9095ac08
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27814
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Make EC FMAP more compliant to existing devices (EC_RO, EC_RW, RW_FWID),
eliminating unnecessary areas (RO_SETION, EC_IMAGE), and add more detailed
comments to each area.
BUG=chrome-os-partner:11360
TEST=emerge-link chromeos-ec; dump_fmap -x ec.bin
Change-Id: I3d30d6fe0d3cee2e944009dccef488f7215b6395
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27739
Everything now uses flash_dataptr() to get at flash memory rather than
calling the read function, since the read function adds a needless memcpy().
BUG=chrome-os-partner:11150
TEST=manual
flashwp enable
reboot
flashinfo -> should show ro_at_boot
flashwp disable
reboot
flashinfo -> should no longer show ro_at_boot
Change-Id: I1830e2f036cf6777115c782c1737335ff2eb4ce0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27796
Since that already monitors the WP signal for reporting it as a
switch. And if we have that code in two places and the WP signal
polarity changes, we'll inevitably forget to change it in the other
place...
BUG=chrome-os-partner:11150
TEST=manual
flashinfo -> WP pin asserted
remove WP screw
flashinfo -> WP pin deasserted
Change-Id: I6091c8bb470c357e02ede8a5b184b2a76b70dc60
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27720
This uses the new keyboard recovery EC event to determine when
keyboard recovery is requested. It is paired with a change to the EC
to stop reporting keyboard recovery as a switch, since that didn't
provide a good mechanism for the AP to tell the EC to stop reporting
the switch value.
This REQUIRES an updated BIOS; without it you won't be able to get
into recovery mode manually. You'll need to press space at the
developer screen, or use the debug console to request recovery. Your
BIOS must have https://gerrit.chromium.org/gerrit/27509.
BUG=chrome-os-partner:10034
TEST=manual
1. boot using power+refresh+esc. See insert screen.
2. power button to power off
3. power button to power on. Boots to Chrome OS (not insert screen).
Change-Id: I699ce004ed1190044170c4ea810b8969b40f523b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27508
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Now that read-only code is protected iff the persistent state is
locked, we don't need to track per-block in the persistent state.
BUG=chrome-os-partner:11150
TEST=if it builds and boots, it's fine
Change-Id: I80e6a85c0c72136b7ed8964ce02c8abdbaafe637
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27719
1. If the flash protection state is locked, RO firmware is explicitly locked.
2. Protecting flash now locks the entire flash.
BUG=chrome-os-partner:11150
TEST=manual
flashinfo -> nothing protected
flashwp now
flashinfo -> unlocked,applied; everything protected
reboot
flashinfo -> nothing protected
flashwp lock ->
flashinfo -> locked,applied; now has 40 Y's at start and 1 at end
reboot
flashinfo -> locked,applied; now has 40 Y's at start and 1 at end
remove WP screw
reboot
flashinfo -> locked, not applied; nothing protected
flashwp unlock
flashinfo -> nothing protected
Change-Id: I2cf0e8bfe82ab7a5bf88b9161b7a05b889cae71a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27717
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>
