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
