The EC was not re-enabling keyboard scanning on boot if the power button
was released. This works fine if the power button is released before
the shutdown is complete, but if the user holds it down until the device
is completed powered down the lock will never be released, and the next
time they turn on the computer, the keyboard won't work.
To fix this, all that is needed is to make the power event task keep
unlocking it whenever the power button isn't pressed down. There's
no problem with unlocking multiple times, so it's not dangerous to do
this.
BUG=chrome-os-partner:12070
TEST=Boot the machine normally, then press and hold the power button
until the machine is entirely powered down before releasing it. Press
the power button a second time to turn on the machine. You should be
able to type as normal.
Change-Id: I88852ed228bd8f6a9446406bab642812ef1327db
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28871
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If it's pressed, need to track that or we'll ignore the release. And
then we'll leave the power button signal asserted to the PCH, and
it'll shut down 4 seconds after the power button was pressed.
BUG=chrome-os-partner:11971
TEST=hibernate 10, then press power button for ~0.5 sec, then release
system should boot normally
Change-Id: Ibb9b8a8827cca6c81bac06dc9543de1a76fa5aad
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28863
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Make sure we don't roll over when rounding up to align the requested size.
BUG=chrome-os-partner:11642
TEST=none
No test; if security guys approve code change, it's fixed.
Change-Id: I2e915a6e6b37fc315ab7adb435e2fce4eed670ba
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28729
Reviewed-by: Sumit Gwalani <sumitg@google.com>
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Previously, if you used Esc + Reload + Power to reboot into recovery
mode, you would be stuck in it until you manually rebooted the EC with
"Reload + Power." This was because the button combo set a switch that
was never un-set. To fix it, the keyboard_scan function now sets a host
event, that is serviced once, and then cleared. As a result, the next
time you reboot after triggering recovery mode, it should boot as before
you triggered recovery mode.
BUG=chrome-os-partner:10889
TEST=Boot device in normal mode. Press Esc + Reload + Power, and boot
from usb. Power off the device and remove the usb media. Power on the
device again, and there should be no recovery screens during the boot
process. Next, repeat these same steps, but from starting in developer
mode. After recovery, when you reboot, the device should return to
developer mode.
Change-Id: Idcb8dde6f8ba5f680f4d34e61ae0d12992281cbb
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28710
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a temporary hack to implement a userland thermal loop. This
code really belongs in the BIOS and will move there once we have
gathered enough data to prove the efficacy (or otherwise) of doing such
throttling. So, please pardon the ugliness of the code -- it's meant to
be short-lived and therefore we wouldn't want to spend too much time on
optimizing it or making it pretty.
BUG=none
TEST="initctl start temp_metrics" and then monitor various parameters
such as CPU min/max frequency, GPU frequency, duty cycle and package
power limits to ensure they are doing the right thing.
Change-Id: I407e4826b4db801298f08fa72c4f2330e127322b
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28634
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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
