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
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>
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>
Currently host_command_reboot() casts the supplied buffer and access
it directly. This works until about half-way thru the function when
the same buffer potentially gets overwritten when sending the response
code to the host.
This CL gets around that by copying the reboot parameters into a
separate buffer.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
TEST=Tested using 'ectool reboot_ec' on Snow (see below)
Before, EC console displayed "[Executing host reboot command]" and
ectool showed no actual change (reboot command was being overwritten
with EC_REBOOT_CANCEL):
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
localhost ~ # ectool reboot_ec A
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
With the patch applied, the EC console shows the EC boot-up messages
and ectool confirms that the jump took place:
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
localhost ~ # ectool reboot_ec A
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: A
Change-Id: I8aca8d468d1125c3fb8d320ec0fb79d2822b0b20
Reviewed-on: https://gerrit.chromium.org/gerrit/26998
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Allows 'reboot cold' as an alias for 'reboot hard', since I keep
mis-typing that anyway. Returns error for any other option.
('reboot' by itself still does a warm reboot).
BUG=none
TEST=manual
reboot -> does warm reboot
reboot hard -> does hard reboot (reason = rtc alarm)
reboot cold -> ditto
reboot foo -> prints error
Change-Id: I183714d4ba09abee3bd9a6f0d5df82389becf410
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26924
This allows the console or AP to keep the EC in its RO code.
Previously, the EC could jump from RO to RW even if the system was
locked in pre-init.
Also, sysjump console command doesn't need to check if system is
disabled before calling system_run_image_copy(), because that function
also checks. This now matches how the host command works.
BUG=chrome-os-partner:11147
TEST=manual
syslock
sysjump A -> works
reboot
syslock
sysjump disable
sysjump A -> fails
Repeat, using 'ectool reboot_ec disable-jump' at root shell instead of
'sysjump disable' at EC console.
Change-Id: I0b168a93e97802ba30e7c225b01d70ea66e8db58
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26898
This makes it easier to test functionality which should be disabled
when the system is locked.
BUG=chrome-os-partner:11154
TEST=manual
sysjump a
sysjump ro
sysjump a
syslock
sysjump ro -> should fail
Change-Id: I637d5a9a795948dd45817c5e110433d12bb6618e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26897
This seems to be a hangover from the LPC protocol. We can send a result
just by sending a response with no data.
Drop this function and remove all uses of it.
Also use 'enum ec_status' instead of int, since this is the correct
response type.
BUG=chrome-os-partner:10533
TEST=manual:
build for all boards
build and boot on daisy
Change-Id: I93a029bd6ba8cec567b61af3b410bcead015b5c0
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25980
And if RW B isn't enabled, it's not even linked.
BUG=chrome-os-partner:10881
TEST=on link, should be no B image, and 'sysjump B' should fail
On BDS, still should be A and B images
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb2af07881cc7e28b9b877f45824486a22fde8d7
Reviewed-on: https://gerrit.chromium.org/gerrit/26116
EC computes a SHA-256 hash of its RW code on boot. Also adds host and
console commands to tell the EC to recompute the hash, or hash a
different section of flash memory.
BUG=chrome-os-partner:10777
TEST=manual
1) ectool echash -> should match what the EC precomputed
2a) ectool echash recalc 0 0x10000 5
2b) on EC console, 'hash 0 0x10000 5'
2c) results should agree
3a) on ec console, 'hash 0 0x3e000' then quickly 'hash abort'
3b) ectool echash -> status should be unavailable
4) ectool echash start 0 0x3e000 6 && ectool echash && ectool echash abort && sleep 2 && ectool echash
status should be busy, then unavailable
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I6806d7b4d4dca3a74f476092551b4dba875d558e
Reviewed-on: https://gerrit.chromium.org/gerrit/26023
At this point, EC code requires EVT. If you still have a proto1,
here's what'll break:
1) Keyboard recovery mode checks refresh key, and may read unreliably due
to proto1 silego reset circuit.
2) Lightbar may not start in the correct state.
3) EC 'hibernate' command will not work.
4) Board version may read incorrectly.
BUG=chrome-os-partner:9661
TEST=manual
1) powerbtn -> system powers on, lightbar displays proper sequence
2) version -> board version 1 (EVT)
3) power+refresh+esc -> system boots into recovery mode
4) power+refresh, then power button -> system reboots, then boots normally
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I699946e365d15ae38622b69da1a0241e72d05f61
Reviewed-on: https://gerrit.chromium.org/gerrit/26053
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Also removes unused recovery request, since AP handles that internally now.
BUG=chrome-os-partner:10685
TEST=manual. From root shell,
ectool reboot_ec RO -> EC reboots to RO, AP stays up
ectool reboot_ec A -> EC reboots to A, AP stays up
ectool reboot_ec cold -> EC reboots, AP shuts down
ectool reboot_ec cold at-shutdown -> (EC stores request, but doesn't reboot)
shutdown -P now -> EC reboots when AP shuts down
ectool reboot_ec cold at-shutdown -> (EC stores request, but doesn't reboot)
ectool reboot_ec cancel -> (EC stores cancel-request)
shutdown -P now -> AP shuts down, but EC doesn't reboot
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I51bbf997f6b7f94fe61f06a8a1804c3cc5c319b8
Reviewed-on: https://gerrit.chromium.org/gerrit/25791
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:10662
TEST=manual
1) Boot system with power+esc+refresh. gpioget ENTERING_RW --> 0
2) reboot, then gpioget ENTERING_RW --> 1
3) Check EC_IN_RW signal on AP, if possible
Change-Id: I9de43eecf71654bf337d7a0e8b21f0cbcf386cc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25624
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This causes the reboot command to respond to the host via I2C with
EC_RES_SUCCESS.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
TEST=tested on Snow and Link using ectool and flashrom
Both machines were able to reboot the EC and go thru an EC update via
Flashrom successfully:
localhost ~ # ectool reboot_ec RO ; echo $?
done.
0
Flashrom is also able to do a fully automatic update, without the
user specifying a layout:
Reading old contents from flash chip... done.
Found 'RO_SECTION' in image.
Found 'RW_SECTION_A' in image.
GEC is jumping to [RO_SECTION]
GEC has jumped to [RO_SECTION]
Erasing and writing flash chip...
...
GEC is jumping to [RW_SECTION_A]
GEC has jumped to [RW_SECTION_A]
GEC needs 2nd pass.
...
Change-Id: Id723c26caa8f352a7ddc6ebfae664448c38300f0
Reviewed-on: https://gerrit.chromium.org/gerrit/24290
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
This returns true when both HW and SW write protect are enabled.
Once WP is enabled, sysjump will be locked out.
system_is_locked() can be used to gate other dangerous-ish commands too.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7468
TEST=manual
sysinfo -> unlocked, copy A
sysjump B -> works
flashwp lock
reboot
(make sure flashinfo shows WP asserted and flash locked; note there is a
HW bug on proto1 which makes this flaky)
sysinfo -> locked, copy A
sysjump B -> fails
(remove WP screw)
reboot hard
flashwp unlock
Change-Id: I849b573675c2c1cb4c44b9a05d6973e38247ca23
Additional help messages and usage are gated by
CONFIG_CONSOLE_CMDHELP, so we can turn it on if there's space (adds
about 3KB to image size) and turn it off when there isn't.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=manual
1) help
2) help list
3) help gpioset
4) gpioset -> wrong number of params
5) gpioset fred 0 -> param1 bad
6) gpioset cpu_prochot fred -> param2 bad
Change-Id: Ibe99f37212020f763ebe65a068e6aa83a809a370
The main CPU might need to know the particular hardware version the
system is running on. This information is available to the EC, this
change adds a mechanism for the main CPU to request this information.
The board version is defined as a flat 16 bit number.
BUG=chrome-os-partner:8722
TEST=manual
. this change was tested in concert with the appropriate coreboot
modification, the proto1 board returns board version of 0. The
code was modified manually to return a one off version - and the
coreboot indeed observed board version of 1
Change-Id: If434d33f43783b18cb202ea15819bd5804694b8e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
On platform where the flash base address is non null (e.g. stm32), we need to
take it into account.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=On Daisy, type "sysjump A" and "version" into the EC console
and observe that the commands succeed.
Change-Id: I95596d45f6970259d19d7063f6794fae0c400ab7
The VMA of the .data segment is in RAM, but we actually put it into FLASH.
The linker doesn't notice if it runs out of flash, so it creates an invalid
image.
This adds an explicit check to be sure it all fits. It also refactors the
region declarations to be more explicit. For vboot-enabled configurations,
CONFIG_SECTION_* - describes the extent of flash for one entire image
CONFIG_FW_* - the region within the SECTION for the firmware only
CONFIG_VBLOCK_* - the region within the RW SECTIONs for the vblocks
CONFIG_VBOOT_ROOTKEY - the region within the RO SECTION for the root key
Look at chip/lm4/config.h for the best example.
BUG=chrome-os-partner:9839
TEST=manual
Build it, run it.
Change-Id: I3c652e82d58a5328115cc750c80ecba6a3fd99a3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
On chips where CONFIG_FLASH_BASE is not 0 (e.g. stm32), the reset vector
address check in system_run_image_copy would fail because we are
comparing an absolute address against a flash offset.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:8865
TEST=on Daisy, type "sysjump B" in EC console.
Change-Id: Ib79677fb926a37fcf32f4aac013dc36b086f4464
Preparatory work to use common host command code between ARM and x86.
Just rename constants, do not change the binary API.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I534d427c9b50103273835a6f32a0ddb622c762b3
Preparatory work to use common host command code between ARM and x86.
Every command sends back explicitly the size of the response payload.
The size of the response defaults to 0 ond can be updated.
Add a protocol version number returned as command 0x00 to help with
backward compatibility.
move a couple of function from lpc specific header to host commands to
be able to implement them for the I2C link.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I6a28edf02996ddf6b7f32a3831d07d5f0271848f
This helps us keep track of how long vboot is taking on the EC.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9651
TEST=reboot system and look at debug log. time shouldn't start over after it jumps to image A.
Change-Id: Iad86e90d42dabf1c67b2c2be80dda1151cf9a288
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9117
TEST=version; board version should be 0 on proto1 and 1 on EVT
Change-Id: Ic64ad0d009151fbda09f5c1605ef50ae708cb6ae
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9447
TEST=update from old EC 517 to this one
Change-Id: I275b5bf6c4ae1ab6e0c0a05cf9260314d644c79b
The position of jump_tags was shifted every time a new field was added
to struct jump_data. This broke the sysjump hook badly.
To make this more scalable, add a header_size field in struct jump_data.
Then the new code can always prepend (or reduce if jump_data becomes smaller)
some spaces between jump_data and jump_tags.
BUG=chrome-os-partner:9447
TEST=EC upgrade from EC 517 (2231) to this version, and keyboard keeps working.
Note that EC 526 (2235) to this version is not working because we have no way
to identify that header version change.
Change-Id: If1b506c6f7d22e5affaaf8ada15990f60d2f957a
When the host reboots the EC it should be able to request the EC to
force recovery mode after reset. This is achieved by extending the
REBOOT EC command with a bitmask byte, with bit 0 dedicated to
recovery request.
So, when BIOS on the way up determines that recovery is requested, but
the EC is not running from the RO space, the BIOS would reset the EC
forcing it to run from RO and to request recovery mode through the LPC
bitmask. Then BIOS will restart itself ensuring that the system comes
up in consistent state.
Some refactoring was also done to make the code a bit more compact.
BUG=chrome-os-partner:9040
TEST=manual
. tested along with coreboot changes (test described in the coerboot CL).
Change-Id: I29801b6aec80da0901ba0e8db8e92e615cc778bd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
This adds a 'ch' command which prints/sets which channels are active
This handles all the async output; the remaining debug commands will
be refactored to use ccprintf() / ccputs() in a followup CL.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7464
TEST=manual
ch --> all channels active
ch 0x100 -> just port80 active
powerbtn -> system boots; only port 80 codes shown on console
Change-Id: I9efc43acec919b62b78c2c82c61946d32380adfe
This also changes shared_mem to use all the remaining RAM, instead of
reserving a fixed-size buffer.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9161
TEST=manual
hostevent --> all masks should be 0
hostevent smi 0x12300000
hostevent --> should confirm SMI mask was set
sysjump b
hostevent --> should confirm SMI mask is still set
reboot
hostevent --> should confirm SMI mask is back to 0
Change-Id: Iccb6da6ccc93ee5036a3f478d24b717a462d9150
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9049
TEST=manual
sysjump ro
version
sysjump a
version
sysjump b
version
All should return versions for RO, RW-A, RW-B.
Change-Id: Ie189d2d777a4743460e2edec65750e563bc69354
Add a host command returning chip information. The interface is in common/
while the implementations are in chip-specific code (note: added simple
value for stm).
BUG=chrome-os-partner:8567
TEST=on board
% ectool chipinfo
Chip info:
vendor: xx
name: yyyy
revision: zzzzz
Change-Id: I5030a03a6fcfbfc080d5acd8efb763fde7eefde5
BUG=chrome-os-partner:8718
TEST=manual
1) Use 'reboot' command from console to boot image. Should end up in
image A, with last reset reason soft cold. 'sysinfo' should show we
jumped to this image.
2) sysjump RO. Should end up in RO; otherwise same as 1)
3) reboot using Power+Esc+Reload. Should end up in image RO, with last
reset reason reset pin. 'sysinfo' should show we did not jump to this
image.
4) sysjump A. Should end up in A with reset reason reset pin.
'sysinfo' should show we jumped here.
Change-Id: I2dd5595eab4ba2c91bfe8b2b2e9677d7732aca63
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Comapre the range to be write (erase) with the range of active image.
If overlap, return error to indicate the access denied.
Note that we actually protect only runtime code and ro data.
FMAP is intentional unprotected so that flashrom can update to new map
before jumping. Since the vector table and init code are in the same
erase page, they are unprotected as well.
BUG=chrome-os-partner:7478
TEST=
Change-Id: Icb5cc89836432a11cef80e18eb66bb39a6c9b1d9
Now that we can jump directly to other images, we don't need this.
We jump to image A by default, unless the recovery button or signal is asserted.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8562
TEST=manual
Reboot -> runs image A
Reboot with reload (F3) held down -> runs RO
Reboot with 'dut-control goog_rec_mode:on' -> runs RO
Change-Id: I8259fe0d738ce0ca897d2f4427d8cf61858b8901
This is necessary at init-time for verified boot to jump from RO to
one of the RW images.
It's also used by factory EC update to update one image and then jump
to the updated image to finish the update. In this case, the x86 does
NOT reboot.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8449
TEST=manual
1) power on x86 and log in
2) sysjump a --> system is in a; x86 has not rebooted
3) sysjump ro --> system is back in RO; x86 has not rebooted
4) reboot -> system is in RO; x86 HAS rebooted
Change-Id: I9dbadcf9775e146a0718abfd4ee0758b65350a87
More modules can be disabled individually through CONFIG_ defines.
Reordered early module pre-init and init, and added comments to
explain why things are ordered in main() the way they are.
Fixed a few assorted init-related bugs along the way, like st32m
keyboard scan double-initializing.
BUG=none
TEST=build link, bds, daisy
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I04a7fa51d743adfab4be4bdddaeef68943b96dec
