- Use CONFIG_*_MEM when dealing with images in program memory.
- Use CONFIG_*_STORAGE when dealing with images on storage.
- Use CONFIG_WP when dealing with the entire WP RO region.
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Manual on Cyan with subsequent commit. Verify that FMAP matches
actual layout of image. Verify flashrom succeeds flashing + verifying EC
image using host command interface.
BRANCH=None
Change-Id: Iadc02daa89fe3bf07b083ed0f7be2e60702a1867
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270269
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Previously, the flash module assumed it needed to emulate a SPI write
protect register using a bank of flash to hold the persistent flash
write protect state. This is not true for mec and ncpx chips under
development, which use external SPI flash. So, gate that code with
CONFIG_FLASH_PSTATE. For compatibility, leave it on by default (as we
do with CONFIG_FLASH_MAPPED).
There is no change to the behavior of currently supported chips, since
all of them already assume pstate is present. Removing this feature
from npcx will be done in a subsequent change.
BUG=chrome-os-partner:34346
BRANCH=strago
TEST=make buildall -j; verify flash wp and flashinfo work properly on samus
Change-Id: Ie044eb042863e4a7359ea540166ffd8d0089589d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253632
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Some EC chips (mec1322) use external SPI flash which is not mapped
into the EC CPU's address space. These must explicitly read data from
flash when calculating the vboot hash or reading the version string of
the image which isn't currently loaded into code RAM.
To test this bug, I used a board with known working mapped flash, and
temporarily patched it to act like it didn't have mapped flash.
Also add a flashread console command, useful for manually testing.
BUG=chrome-os-partner:35308
BRANCH=glower,strago
TEST=manual
1. Apply this patch to samus
2. Check result for 'vboot hash RW'
3. Check result for 'version'
4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and
#define CONFIG_CMD_FLASH
4b. In chip/lm4/flash.c, add the following:
int flash_physical_read(int offset, int size, char *data)
{
const char *src;
if (offset > CONFIG_FLASH_SIZE ||
offset + size > CONFIG_FLASH_SIZE)
return EC_ERROR_INVAL;
src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset);
memcpy(data, src, size);
return EC_SUCCESS;
}
Steps 4a,4b will make the LM4 chip act like it doesn't have
memory-mapped flash.
5. From the dev system, util/flash_ec --board=samus --ro
6. Check result for 'vboot hash RW'. Should be same as 2.
7. Check result for 'version' for RW version. Should be same as in 3.
8. From the dev system, util/flash_ec --board=samus
9. sysjump rw
10. Check result for 'version' for RO version. Should be same as in 3.
11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results
should be the same (but endian-swapped, since flashread is byte
ordered and md is 32-bit ordered).
12. Revert changes from steps 4a-4b.
Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246200
Reviewed-by: Shawn N <shawnn@chromium.org>
The valid and writable flags the EC sends back to the AP are incorrect.
They are a little bit different on differnt chips, so let's move it to
flash physical layer. This is not any causing problem, but we should fix
this.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222661
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On STM32F0, we cannot work around the hard fault triggered when trying
to protect the whole flash. Therefore, we need to go with the
ALL_AT_BOOT approach. When write protect is enabled, instead of setting
ALL_NOW flag to immediately lock down the entire flash, we need to set
ALL_AT_BOOT and then reboot to have the protection take effect.
BUG=chrome-os-partner:32745
TEST=Along with the next CL. On Ryu:
1. Enable HW WP. Check the output of 'ectool flashprotect' and see
correct flags.
2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set.
3. Reboot EC and check RO_NOW is enabled.
4. Boot the system and check ALL_NOW is set.
5. Update BIOS and reboot. Check software sync updates EC-RW.
6. 'flashrom -p ec --wp-disable' and check it fails.
7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared.
8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared.
TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set
properly.
BRANCH=samus
Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a preparatory work for the following change for write protection
support on STM32F0.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ic4deea06e26c4a6ac024a5388e1a5783b40e9876
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The firmware defines had two almost-identical sets. Coalesce into one
consistent set.
Link had 256 KB flash, but only allowed 2 80KB images. Future
LM4-based platforms (slippy/peppy/falco/etc) will now use the entire
flash, with RO=124KB, pstate=4KB, RW=128KB. This matches what the
STM32 platforms do, where pstate is contiguous with the RO firmware.
No functional change to STM32-based platforms.
BUG=chrome-os-partner:19176
BRANCH=none
TEST=build all platforms and dump_fmap ec.bin.
- stm32-based platforms should report RO=61440@0, RW=65536@0x10000
- link should report RO=81920@0, RW=81920@0x14000
- slippy should report RO=129024@0, RW=131072@0x20000
Change-Id: I20b1d95c16250d9a5d228ead06eef03d96548823
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56655
Write protect signal naming is now consistent across boards.
New CONFIG_WP_ACTIVE_HIGH is present on systems where the write
protect signal is active-high (e.g. Link). This will be used in the
next CL, which moves flash_get_protect() to flash_common.c
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo properly reports WP signal status
Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56087
Reviewed-by: Vic Yang <victoryang@chromium.org>
Persistent state is needed by all platforms to hold the
protect-ro-at-boot flag. STM32F100 and LM4 implementations were
near-identical, and are now common code (with one #ifdef to handle the
single place where they weren't).
STM32L doesn't use pstate yet, but it'll need to. I can't simply
store the protect-ro-at-boot flag inside the WRP registers themselves
because they're still writable in EC-RW. The change to STM32L to use
pstate is coming next.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=build pit, link, spring; on link and spring, do
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now)
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- reboot ap-off
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot
- flashwp disable
- flashinfo -> (no flags)
(Note that on Spring you'll need to 'forceen on' before enabling WP,
or the console will be disabled once you enable ro_at_boot and reboot.)
Change-Id: I415388b98ec8bf1d149803aaaa7fe8c7f3076c36
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56064
This adds support for write protecting the RO code at boot, and the
entire flash on demand.
Implementation if WP# is not asserted is currently a little different
than STM32F and LM4; RO is still protected at boot if ro_at_boot, but
can be unprotected and the change will commit on the next reboot.
This saves the bank of flash which we use for pstate on LM4 and
STM32F. I think I can use one of the unused option bits (WRP2 bit 0)
to hold the RO-at-boot flag, in which case I can more closely match
the behavior of the other chips, but I'd like to do that (or give up
and implement pstate) in a separate CL so it's clearer what I'm doing.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=manual
- flashinfo -> (no flags)
- enable WP (via screw or dut-control)
- flashinfo -> wp_gpio_asserted
- flashwp enable
- flashinfo -> wp_gpio_asserted ro_at_boot
- flashwp now
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flashwp disable -> fails
- flashinfo -> wp_gpio_asserted ro_at_boot all_now
- flasherase 0x1fc00 0x400 -> fails
- reboot
- flashinfo -> wp_gpio_asserted ro_at_boot ro_now
- flasherase 0xfc00 0x400 -> fails
- flasherase 0x1fc00 0x400 -> succeeds
- disable WP (via screw or dut-control)
- reboot
- flashinfo -> ro_at_boot ro_now
- flashwp disable
- flashinfo -> ro_now
- reboot
- flashinfo -> (no flags)
- flasherase 0xfc00 0x400 -> succeeds
- flasherase 0x1fc00 0x400 -> succeeds
Change-Id: Id1b6b099a44a1985a5ab9387feb882a8f26e3aa1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55594
Perviously we use uint32_t for this, but this doesn't compile for 64-bit
environment (and likely doesn't for 16-bit either.) Use uintptr_t so that
we don't get size mismatch errors.
BUG=chrome-os-partner:19257
TEST=Run host emulated tests
BRANCH=None
Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
No functional changes; just clean up comments and remove dead code
BUG=chrome-os-partner:15579
BRANCH=none
TEST=code compiles
Change-Id: Id006ae18f2b26cea1720196f696f937811b6ba5b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36448
Reviewed-by: Simon Glass <sjg@chromium.org>
It wastes time to erase blocks that are already erased and it is faster
on stm32 to check first. Add a check in flash_physical_erase() on all
chips, using a common flash_is_erased() function.
BUG=none
BRANCH=snow,link
TEST=manual
Do software sync in U-Boot and see that it succeeds. This tests that
we can still erase and then boot a written image. It typically saves
a second on a full sync over i2c.
SMDK5250 # cros_test swsync -f
SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
Flashing RW EC image: erasing, writing, done
Flashing RO EC image: erasing, writing, done
Full software sync completed in 22.949s
SMDK5250 #
Also see that second erase is faster:
SMDK5250 # time mkbp erase rw
time: 0.952 seconds, 952 ticks
SMDK5250 # time mkbp erase rw
time: 0.054 seconds, 54 ticks
SMDK5250 #
Change-Id: I3699577217fdbb2f212d20d150d3ca15fdff03eb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30851
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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
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
If flash starts at zero, then flash_dataptr() will return NULL for a valid
region. Change the function around so that it can be used in this case.
BUG=chrome-os-partner:10146
TEST=manual:
Modify code it print out parameters and problems, then:
Writing 256 bytes to 0x0...
0 256 64
ok 131072
Command returned error 1
> flashwrite 0 256
Writing 256 bytes to 0x0...
0 256 64
ok 131072
Command returned error 1
> flashwrite 0 255
Writing 255 bytes to 0x0...
0 255 64
Command usage/param invalid.
Usage: flashwrite offset [size]
Change-Id: I5683fc181ef780310ceff50f120735659e973784
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26749
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Sometimes it is useful to get access to the flash directly, without using
flash_read(). Add a function to do this.
Since the range checking is done in every function in flash_common,
use the new function to do it for us. That way we get a slight (64 byte)
code size reduction.
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow with SPI flash emulation, in U-Boot:
See that the 32KB of flash has been provided correctly.
Change-Id: I6622a24234edaed371dd5b9bf43d1f3974d55e39
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26174
This uses the last bank of flash to hold persistent settings, and
looks at the write protect GPIO to decide whether to protect the chip
at boot (chrome-os-partner:7453).
For ease of debugging, I've temporarily hacked this so flash uses the
RECOVERYn signal (dut-control goog_rec_mode:on) to enable WP instead
of the write protect signal; this works around chrome-os-partner:8580.
Also note that if you write protect any blocks even temporarily,
you'll need to do a power-on reset to clear them before you can
reprogram the flash. See chrome-os-partner:8632. At the EC console,
"hibernate 1" will do that, or you can just yank the power.
This also fixes a bug in the flash write and erase commands, where
they weren't properly detecting failure if you attempted to modify a
protected block (missed an interrupt reason...)
New "flashwp" console commands work. LPC commands need reworking.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8448
TEST=manual
Change-Id: I49c38cc25c793094ae3331a4586fda0761b4bac6
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
