The ARM EC was being rebooted when both the power and one of several other keys
were pressed. (LCtrl, Tab, Reload, t, [, ], y, Dim Screen and Mute) It should
only do this when the key combo PWR + Reload is pressed.
To fix it, keyboard scanning is disabled whenever the power button is
pressed. It locks a mutex indicating that scanning should be disabled,
and the main keyboard scanning task blocks on the step where it sets up
the keyboard and waits for the mutex to unlock.
BUG=chrome-os-partner:10889
TEST=Pick one of the troublesome keys. First press it, then quickly
press the power button. Then press the power button followed
by the troublesome key. Repeat this process several times for each key,
it should not reset the system.
Press power + reload, this should still reset the system.
Pressing and holding power should initiate a shutdown.
Change-Id: Ib60d2ebbb57eb8a3c135662514ec622c37a7eb07
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28402
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes a bunch of unnecessary typecasts, since you can assign
to/from void * without them. This also uncovered a few cases where
const was being cast away for the input params; now fixed.
BUG=none
TEST=mkbp hash from u-boot console, and/or system boots ok
Change-Id: Ic314b9d2ca06226ea8a09703ef5c1a912eb7146d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28500
The area_offset of following area are wrong which is related to the CPU
view in the STM32 chip:
FMAP
RO_FRID
RW_FWID
Add a macro RELATIVE() to calculate the real offset in flash.
BUG=chrome-os-partner:11269
TEST=build in chroot for link and snow.
Those fmap afddress are related to the start of flash.
Change-Id: I691814e2f53b1de0ecf9fd385bed8d5c598373a7
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28388
Commit-Ready: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Reviewed-by: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Tested-by: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Otherwise, EC software sync protects the entire firmware except in recovery mode, regardless of the WP pin.
BUG=chrome-os-partner:11847
TEST=boot with WP enabled but RO-at-boot disabled; flashinfo should show
entire flash still writable
CQ-DEPEND=28444
Change-Id: I58d60adfaa952b127e8695213f95f6da0e34821d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28445
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When updating the EC and BIOS, we have to run for some times the new EC
with the old BIOS (after we have upgraded the first half of the EC and
before rebooting the machine), let's handle the ACPI request so the
kernel is not sending them into a loop triggering a reboot of the
machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:11821
TEST=update a Link EVT using "chromeos-firmware --mode=factory" from
current BCS binaries (EC v1.1.104-b8d7d8f / Firmware 2476) to next
candidates ( EC v1.1.301 / Firmware 2657).
Change-Id: I115a42e6c33c143cbdc38341dcf7e0f61a8bd771
Reviewed-on: https://gerrit.chromium.org/gerrit/28409
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
This is used only in selected platforms, and installed
by the temp-metrics package in the private overlay for
those platforms.
BUG=chrome-os-partner:11631
TEST=manually using about:histograms
Signed-off-by: Luigi Semenzato <semenzato@chromium.org>
Change-Id: I89dffed6aa34d683ff78a360988fdfb84c2dc641
Reviewed-on: https://gerrit.chromium.org/gerrit/28311
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Commit-Ready: Luigi Semenzato <semenzato@chromium.org>
No need to hash a bunch of 0xff's at the end. We explicitly set a
0xea byte after the end of the code in firmware_image.lds.S.
BUG=chrome-os-partner:11087
TEST=look for the hash start line in the EC debug output:
[0.011543 hash start 0x00014000 0x00011590]
The second number is the code size. It should be the same size as
ec.RW.bin, instead of 0x14000.
Change-Id: Ibc94851dc1a09eb46cad46bb97dc5762f9c521f0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28300
This is a significant rewrite of the flash module, since it turns out
that much less of the flash logic is actually common between stm32 and
lm4.
BUG=chrome-os-partner:11699
TEST=on link,
(enable hardware wp)
flashinfo -> wp_gpio_asserted
flashwp enable
flashinfo -> wp_gpio_asserted ro_at_boot
reboot
flashinfo -> wp_gpio_asserted ro_at_boot ro_now
flashwp disable -> error 7
flashwp now
flashinfo -> wp_gpio_asserted ro_at_boot ro_now rw_now
reboot
flashinfo -> wp_gpio_asserted ro_at_boot ro_now
(disable hardware wp)
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> (no flags)
Change-Id: If22b02373946ce1c080d49ccded4f8fa3e380115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28200
Reviewed-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:8039
TEST=manual
Boot the system, look at the lightbar. It should pulse colors slowly on
battery, faster on AC.
Change-Id: I0184973d11eda51db87d652aa2c92995f5a25588
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27810
It's a bit odd that the drivers package up a command to be processed
by host_command, but then host_command calls a global function to
pass the response back.
This adds ambiguity in the host_send_response() implementations as to
whether the command being responded to really is using the same
buffers that the driver set up.
Add a function pointer to the command, and have host_command call
that. Add status to the args structure also, which removes some of
the special case logic for error handling.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: I816738150bce3f8d78e7cd32abf361621aa12312
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28154
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BDS has been slowly rotting as we make changes for Link. I haven't been able
to test the BDS image for some time (I think due to openocd updates that no
longer like the BDS configs), and now it doesn't even compile. This is
gating the Link schedule, so I'm just turning it off. If we ever need the
BDS again, well, what fun.
BUG=none
TEST=none
It already doesn't work, so it should continue to not work.
Change-Id: I2b365623903590a56948dfceb986a2300699f541
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28181
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Keys I keep hitting should work like I expect them to.
Home or Ctrl+A = move to beginning of line
End or Ctrl+E = move to end of line
Del = delete-right
Ctrl+K = delete to end of line
Ctrl+L = clear screen and reprint current line
Ctrl+N = next command
Ctrl+P = previous command
Also, improve filtering of escape sequences and non-printable
characters, so hitting unsupported keys or control codes doesn't mess
up the current line of input.
BUG=chrome-os-partner:11666
TEST=manual
type 'fhelpbar'
home -> cursor moves to beginning of line
Ctrl+E -> cursor moves to end of line
Ctrl+A -> cursor moves to beginning of line
(of course, if you're using Minicom, you'll need to type Ctrl+A A, since
Minicom uses Ctrl+A as its control key)
del -> 'helpbar'
end -> cursor moves to end of line
left-arrow 3 times -> cursor moves under 'b'
Ctrl+L -> screen clears, cursor still under 'b'
Ctrl+K -> 'help'
Ctrl+Y Page-Up Page-Down -> nothing printed
enter -> prints known commands (output of 'help' command)
Ctrl+P -> 'help'
Ctrl+N -> empty command line
Change-Id: Id893c93b26db8f3deed6ea8be5aab88a3daaead4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28143
Since we only have one RW firmware, let's remove _A to prevent confusion.
Also change "BOOT_STUB" to FR_MAIN to reflect the fact that it's not just
bootstub - it's a full firmware area just like FW_MAIN.
BUG=chrome-os-partner:11360
TEST=emerge-link chromeos-ec; dump_fmap -x /build/link/firmware/ec.bin
Change-Id: Ia84062ada5959164b2b4e0f9cc5fcc032ca6f71e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27971
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Assorted minor cleanup; make protocol a bit more efficient, and add a
missing line of output to flash protect status.
BUG=none
TEST=ectool flashprotect; should print valid bits = 0x3f on link
Change-Id: I9bea78506b3ed367df731d358982d3e2febb13af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28097
Reviewed-by: Vic Yang <victoryang@chromium.org>
And tidy reporting fan/thermal via memmap.
BUG=chrome-os-partner:11628
TEST=manual
ectool pwmgetfanrpm -> should report fan speed
ectool temps N ->
should work for N=0-9
reports error for N=15-23
reports invalid sensor ID for N<0 or N>23
Change-Id: I484f81399f5e9dae9c759401091cc6f5acc733ff
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28032
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently, I2C commands look like this:
Input:
cmd8 [params bytes] checksum
Output:
response8 [response_ptr bytes] checksum
Use a prefix byte of (0xDC + cmd_version) to indicate the command
version. This is compatible with the existing protocol, since there
are no host commands in the range 0xDC-0xFB. If the first byte of
the from-host data is 0x00-0xDB, it's a version 0 command.
There is no change to the output format, since the EC needs to hand
back a response which matches the version requested by the host.
New input:
(0xDC+ver8) cmd8 paramlen8 [params bytes] checksum
New output:
response8 responselen8 [response_ptr bytes] checksum
If the host gets a response of EC_RES_INVALID_COMMAND, it knows it's
talking to an old EC, and at most version 0 of the command is supported.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet, so far only snow is tested)
Check that snow and link still process commands correctly over I2C
from U-Boot.
SMDK5250 # mkbp test
Old interface:
New interface:
Test passed
Change-Id: I1c21f2b036091e9122b4f980ca5f5af34f7fc070
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27470
We are about to add more logic here, so move it this code out of
the event handler and into its own function.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: I5387eb5533ab6faa27769f4cf21075387357371d
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27469
It's a bit odd that the drivers package up a command to be processed
by host_command, but then host_command calls a global function to
pass the response back.
This adds ambiguity in the host_send_response() implementations as to
whether the command being responded to really is using the same
buffers that the driver set up.
Add a function pointer to the command, and have host_command call
that. Add status to the args structure also, which removes some of
the special case logic for error handling.
BUG=chrome-os-partner:11317
TEST=manual and a bit ad-hoc:
(note, this testing is not completed yet)
Check that snow and link still process commands correctly over I2C
from U-Boot. At this stage only the old interface is supported.
SMDK5250 # mkbp test
Old interface:
New interface:
Version 0: ec_command() returned error
Test failed with error -1
SMDK5250 #
Change-Id: Ic4afdcd7689666cc0f6af228abc6cffe41b0fcbf
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27468
When we do parallel 'make', it fails intermittently. We might be hitting
a make bug: http://savannah.gnu.org/bugs/?30653
Let's remove the intermediate file for now and see if this happens
again.
BUG=chrome-os-partner:11614
TEST=Repeatedly remove some file and parallel make. This originally
gave an error once every two time. It doesn't now.
Change-Id: Iaaf48e7d19b11dad30bc70cd50e73c195caf17b4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28105
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
