This makes build_info fixed-length so that it can be properly
transmitted via I2C. The host buffer size will be used, which may
in fact be quite a bit longer than necessary. Build info will be
truncated if it's longer than the max response size.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:11608
TEST=Tested on Snow, logic analyzer confirmed NAK and STOP condition
set properly after final byte transmitted via I2C (see BUG)
Change-Id: Iccae0f3c2905d442c8eebff42aa19bf940e5f71f
Reviewed-on: https://gerrit.chromium.org/gerrit/32290
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This would improve boot speed when compared to storing in eMMC because
initialing eMMC is slow.
So far other platforms do not have this need because CMOS is quite
efficient; thus it is left unimplemented in lm4.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:10660,13094
TEST=On Snow, see VbNvContext is preserved across power cycles (you have
to patch U-Boot to test this)
Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36
Reviewed-on: https://gerrit.chromium.org/gerrit/31832
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Jump data now precedes the panic data, if any, in memory.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. boot system
2. sysjump rw --> display should stay on and keyboard should still work
(this verifies jump data is properly read across sysjump still)
3. crash unaligned --> system should reboot
4. panicinfo --> should print the same crash dump as before, with (NEW)
5. panicinfo --> ditto, without (NEW)
6. sysjump rw
7. panicinfo --> ditto, without (NEW)
Change-Id: I88285724e82a15553ab25877e3d8ec4c74a4dd5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32051
BUG=chrome-os-partner:13439
BRANCH=snow
TEST=manual
1. Ctrl+Refresh+Esc; should go to INSERT screen
2. Ctrl+D; should show TODEV (this confirms it's still possible to get into
dev mode the right way)
3. From EC console, 'sysjump rw'
4. Ctrl+D; should NOT show TODEV (this confirms the bug is fixed)
Change-Id: Ic4879cb0a7fc47527eac1a5a727f3225744ff880
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31932
Rather than have the send_response() handler called willy nilly from
around the EC code, provide an official function for doing this step.
BUG=chrome-os-partner:12685
BRANCH=snow,link
TEST=manual
build and boot to kernel on snow
Tried 'mkbp reset' command on snow but it did not seem to work properly
Unable to test on link at present
Change-Id: I8d9146639efb2af482d80563b403771cee961942
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30468
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is better than having the 0xea byte only appended in ec.bin,
since now the byte is present in ec.RW.flat and ec.RO.flat. Needed
for EC software sync.
BUG=chrome-os-partner:12412
BRANCH=link,snow
CQ-DEPEND=30305
TEST=manual
1. xxd ec.RW.bin | tail; should end with 0xea
2. xxd -g4 build/link/ec.bin | grep -C3 454e44ea
That word should be the last one before a bunch of 0xfffffff bytes.
There should be 2 matches (since there's RO and RW firmware)
Change-Id: I0de5cc78083f1a9b49202fbe2305a3101f401db3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30303
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
system_hibernate(0, 0) now hibernates until a wake pin assert, with no
RTC wake.
BUG=none
TEST=manual
command -> expected reset flags from 'sysinfo'
1. reboot -> soft
2. reboot hard -> power-on hard
3. hibernate (and press power button) -> power-on wake-pin
4. hibernate 3 (and wait for timeout) -> power-on rtc-alarm
5. hibernate 10 (and press power button before 10 sec) -> power-on wake-pin
hibdelay 10
then shut system down and run on battery
10 sec later, system should hibernate.
Change-Id: I399413d265f6fcf808adf9ed1db7b812a1b12fc2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/29923
Reviewed-by: Vic Yang <victoryang@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
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
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>
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
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
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>
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
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
