Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
On HASH_START command, we should also fill in hash status in response so
that the caller sees BUSY status in response.
BUG=chrome-os-partner:23067
TEST=Along with u-boot change, corrupting EC RW followed by a warm reset
doesn't result in shutdown.
BRANCH=All
Change-Id: Ie0c1b35d71bc0420b011f0413f92feb88138db4d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172380
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This copies the parts of sha256.c that we need from vboot_reference,
and removes the explicit dependency on vboot_reference. That
dependency was a good idea when we were doing full verified boot in
the EC, but is now overkill and makes it harder for others to reuse
the EC code. This also lets us call EC functions directly instead of
needing vboot_stub.cc; that reduces code size by ~100 bytes.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=vboot_hash ro, then compare with result of sha256sum build/link/ec.RO.flat
Change-Id: I0f236174291df3e7f3c75e960fe9ab32af305a61
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36589
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This solves the problem where the AP updates EC-RW as part of software
sync, then tells the EC to jump to EC-RW. On the next boot the EC
still returned the saved old RW hash, causing a needless cold boot.
This change is backwards/forwards compatible; existing RO code will
simply save a hash new RW code won't look at, and existing RW code
already knows to recompute the hash if the RO code didn't save it.
Hash computation is done in the background and takes ~350ms, so this
should have no noticeable effect on performance.
BUG=chrome-os-partner:13511
BRANCH=all (not needed for FSI, since RW code with this change will do
the right thing with existing RO code)
TEST=at the EC console, "sysjump RW" and look at the EC debug log for
"hash done".
Change-Id: Ie5255727b9d896b7c4e4f537e91d831682afc7f6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33634
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Otherwise the host needs to tell the EC how big this image is (which
it knows, but it's inconvenient for it to provide).
BUG=chrome-os-partner:13511
BRANCH=all
TEST=manual
1. ectool echash recalc ro -> prints hash of RO code (offset 0)
2. ectool echash recalc rw -> prints hash of RW code (offset non-zero)
In each case, size should be an exact number and not the size of the
whole RO or RW section. So for link, output should be something similar to:
localhost ~ # ectool echash recalc ro
Hashing EC-RO...
status: done
type: SHA-256
offset: 0x00000000
size: 0x00012a64
hash: 03a66c076d6dd4b4aa9ed6386713f45291f5143f9af2093003e632485899daf1
localhost ~ # ectool echash recalc rw
Hashing EC-RW...
status: done
type: SHA-256
offset: 0x00014000
size: 0x000123d1
hash: 0d6225e70f0b1e0419e987370371e00783f945827ef25915a8fb8549159dd2a4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
3. At ec console, 'hash ro' or 'hash rw' should regenerate the same
hash values printed above.
Change-Id: I3f6085d29927b8cdf9dabc6930f0fdc7222bd8b5
Reviewed-on: https://gerrit.chromium.org/gerrit/33123
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
This allows recomputing hash after EC boots.
BUG=chrome-os-partner:13988
BRANCH=all
TEST=manual
1. hash 2048 2048
2. hash 0 2048
3. hash -> hash value should be different than in step 1
Change-Id: Id66d0655a143b5190b5d8949b0fa9a18dbbc05f4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33118
Reviewed-by: Simon Glass <sjg@chromium.org>
CONFIG_FW_RW_OFF is already relative to the base address of the flash,
we don't need to substract it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=None
TEST=on Snow, run with CONFIG_VBOOT and CONFIG_VBOOT_HASH activated and
see the hash is correctly computed and display.
Change-Id: I1643b07a59459baa973bfd7ee80cbf98963a85d4
Reviewed-on: https://gerrit.chromium.org/gerrit/29276
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@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
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>
Changed the parameters from int to uint32_t (which is how it was called
anyway).
BUG=chrome-os-partner:11045
TEST=manual
No visible change. Nothing should break.
Change-Id: I4fbe34f67df7d37f5039987a7a89e626916d6eb6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27382
Reviewed-by: Randall Spangler <rspangler@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>
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
