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
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>
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>
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
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>
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
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>
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
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
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
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>
This change shorten the timeout period to 10ms.
Experiments showed that most master mode communication status bit
changed within 2000us. Hence 10ms timeout is much reasonable than
the original value.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=none
TEST=manual, with i2c scope
Change-Id: Ib26795bd2e4877b5c33719e96a2c2c7c11333eab
Reviewed-on: https://gerrit.chromium.org/gerrit/27145
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Now that ACPI events are handled directly in the LPC interrupt
handler, we can simplify the host event code.
BUG=chrome-os-partner:11240
TEST=boot system; should boot
close lid; should send SMI and suspend system
Change-Id: I8c73ea31a66e94310e4460a008635a103220413e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27100
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And only support it for port 62/66.
Also remove 'ectool queryec', because it can't touch port 62/66 once
the kernel/ACPI owns it, and query-event isn't supported on the user
command port.
BUG=chrome-os-partner:11240
TEST=boot system and check EC console output; should see event clears between
host commands 0x23, 0x8e, but no hostcmd 0x84.
[0.396780 LPC RESET# deasserted]
[0.486953 Port 80: 0x29]
[0.487415 hostcmd1 0x23]
[0.764407 Port 80: 0x88]
[0.764579 event clear 0x00000008 -> 00002080]
[0.764928 event clear 0x00000080 -> 00002000]
[0.765224 event clear 0x00002000 -> 00000000]
[0.765578 hostcmd1 0x8e]
[0.765868 hostcmd1 0x06]
Change-Id: I8ed161dbccd396d685ddf6829a27dfef87d919fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27095
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:9922
TEST=manual
Press power+refresh+d.
From ec console, 'optget'. No reference to fake dev switch
From host, 'ectool vboot'. Should see either 'fake_dev=0' or no mention of fake dev switch at all.
Change-Id: I66bc5e926d6e639b206563e764bcc730cce9227c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27061
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This fixes a small bug introduced in a previous refactoring CL where
by the data buffer offset wasn't being incremented, thus causing
writes to repeatedly write the first two bytes of the incoming data
to each chunk of memory.
BUG=chrome-os-partner:11097
TEST=successfully wrote and verified data on Snow
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8dae00652f4d74bc6ef449297b6e78b13b21255f
Reviewed-on: https://gerrit.chromium.org/gerrit/26985
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
When debug port is left unconnected, EC get garbage keypress input from
both UART ports due to UART pin floating. By clearing UART receive FIFO
when initializing UART module, this can be prevented.
BUG=chrome-os-partner:10235
TEST=Reset EC with debug port unconnected. Check u-boot doesn't get any
keypress.
Change-Id: I3e84db1f2f95a0173c11180f6afb3edb705d0ae5
Reviewed-on: https://gerrit.chromium.org/gerrit/26908
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
If the 'percent' passed in is lower than 0, then set it to 0. If it is
higher than 100, set to 100.
BUG=chrome-os-partner:11052
TEST=Check with 'kblight', 'fanduty', and 'faninfo'.
Change-Id: If84ab12658bf136eaaf1adecc0522a977c94f98d
Reviewed-on: https://gerrit.chromium.org/gerrit/26904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Also add new 'invalid' host event bit; if the host reads this, it
knows the memory-mapped data for current events is invalid.
BUG=chrome-os-partner:11146
TEST=manual
On host, ectool eventget -> should print events = 0
On EC, hostevent set 0x80000000
On host, ectool eventget -> should print events = invalid
Reboot EC; should see debug output where event mask 0x2000 is set
during the boot process.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I8d3f161eec25db50ac06e3642a1a1fb8edb9590e
Reviewed-on: https://gerrit.chromium.org/gerrit/26876
512 bytes isn't enough to capture all the debug output early in the
init process, and Link EC has lots of unused RAM. stm32 doesn't, so
only do this for LM4 processor.
BUG=none
TEST=build; debug output during init shouldn't be garbled
Change-Id: Ie4fd204fa4e0c6ca99ea7eae94b095ef175836e4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26877
