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>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
All the current data buffers *are* aligned, but we should check anyway
just to avoid unpleasant surprises in the future. This matches what
we do on STM32L. On STM32F, we copy a byte at a time so alignment of
the source data doesn't matter.
BUG=chrome-os-partner:9526
BRANCH=none
TEST=manual
flasherase 0x20000 0x1000
flashwrite 0x20000 0x200 -> succeeds
flashwrite 0x20201 0x200 -> fails
Change-Id: Id1a0fd8f6871e1fcdc3f55ec25eea40f33b5214c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175532
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Currently, we need to have #ifdefs everywhere watchdog_reload() is
called. With this fix we don't.
Also don't bother including unused hardware timer watchdog code if the
watchdog isn't defined.
No change when CONFIG_WATCHDOG is defined (which it is for all normal builds).
BUG=chrome-os-partner:20056
BRANCH=none
TEST=build all platforms with CONFIG_WATCHDOG commented out in config.h
Change-Id: Id3ce33af1a497eda127a4892e13651d9d2534d92
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58094
Reviewed-by: Simon Glass <sjg@chromium.org>
These were tested to make sure they are not responsible for
bricking boards.
The flash code is necessary for software sync, and it is
essential to be able to update boards without servo.
The hibernate setup code was breaking jumping between images
and the passing of data between the images -- needed for
SW SYNC but also needed for things like "reboot ap-off".
BUG=chrome-os-partner:19366
BRANCH=none
TEST=manual: emerge-slippy chromeos-ec, flash+boot, update again via SW Sync
Change-Id: Ib1363b353f18b21e0cad3209783e1e0b4ff24e86
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56820
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 change just copies slippy and tweaks a few things that were
slippy-specific instead of not-link-specific (there are still bugs
open for those things).
BUG=chrome-os-partner:18788
BRANCH=none
TEST=manual
Since there are no Falco-specific changes yet (just slippy with another
name), I can try it on Slippy:
cros_workon --board falco start chromeos-ec
emerge-falco chromeos-ec
~/trunk/src/platform/ec/util/flash_ec --board falco
I also built and tested Link EC, to make sure nothing broke there either.
Change-Id: I9b3682032bd51adab4450520dfe52e3036750ef9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55820
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the last bank of flash in a region was protected and the rest of
the region was unprotected, flash_get_protect() shoud return the
INCONSISTENT flag, but this wasn't being properly detected.
Port the existing fix from STM32F.
BUG=chrome-os-partner:19529
BRANCH=none (not likely worth porting to link)
TEST=protect just the last bank of RW firmware, then flashinfo
> flashinfo
Physical: 128 KB
Usable: 128 KB
Write: 64 B
Erase: 256 B
Protect: 4096 B
Flags: all_now INCONSISTENT
Protected now:
........ ........ ........ .......Y
Should have the inconsistent flag set.
Change-Id: I407737cef42748da6b3ec40d84968c76ee07972c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51498
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This commits the hacks made during board bringup. Bugs can be filed and
fixed based on this starting point.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Try it and see.
Change-Id: Ia663eaf9a357633873b1b5d5cc6dbdda63513082
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50875
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
CONFIG_ macros should be set directly. Expanding the task names in the same
way made it difficult to tell what was a configuration choice and what was
due to changes in ec.tasklist
BUG=chrome-os-partner:18343
TEST=build all, run link
BRANCH=none
Change-Id: Ib82e34f974238ee2dd216f33b701b6f4c6a4f1f1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49098
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the entire flash is protected (as it normally is after software
sync), fail all flash write/erase operations.
Add a shadow copy of the all_now flag.
BUG=chrome-os-partner:16727
BRANCH=link
TEST=manual
Verify that flash operations work properly before all_now. Then enable HW WP
and
flashwp enable
flashwp now
and try
flasherase 0x38000 0x1000
flashwrite 0x38000 0x100
Those commands should fail with error 7
From the host side
ectool flasherase 0x38000 0x1000
echo 'Khaaaaaaaaaaan' > /tmp/b16727
ectool flashwrite 0x38000 /tmp/b16727
should also fail.
Change-Id: I99a4d2bb86080bd12c900582a8fbdfc79c99916c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39517
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Since it handles not just power button, but also lid switch, AC
detect, and other switches.
No functional changes; just renaming.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=boot system, power on/off with power button
Change-Id: I51628a52293f7207715f5f6bf368a08fe6c3dbce
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36821
We'd defined them in a number of different files. This moves
definitions to timer.h, and uses them everywhere we have large delays
(since 10*SECOND is less typo-prone than 10000000).
Also add msleep() and sleep() inline functions. No need for mdelay()
or delay(), since any delays that long should use sleep funcs instead
of spin-waiting.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=boot system; taskinfo displays similar numbers to before
Change-Id: I2a92a9f10f46b6b7b6571759b1f8ab4ecfbf8259
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36726
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>
Current *_RW_NOW/RW_AT_BOOT is used to lock the entire flash. This could
lead confusion in the future. So, rename them.
Since the bit definition is unchanged, thus the callers (u-boot, flashrom)
is fine if they don't change the name.
BUG=chrome-os-partner:12951
BRANCH=snow,link
TEST=build in chroot only:daisy,snow,link,bds
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: I2395e93793f590e6fb8aae7006eb8e5c836002bc
Reviewed-on: https://gerrit.chromium.org/gerrit/31199
Commit-Ready: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
Otherwise, EC software sync protects the entire firmware except in recovery mode, regardless of the WP pin.
BUG=chrome-os-partner:11847
TEST=boot with WP enabled but RO-at-boot disabled; flashinfo should show
entire flash still writable
CQ-DEPEND=28444
Change-Id: I58d60adfaa952b127e8695213f95f6da0e34821d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28445
Reviewed-by: Bill Richardson <wfrichar@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
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
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8967
TEST=manual
While ssh'd into the device:
1) Create a test image:
Extracting to: /tmp/ecup
132+1 records in
132+1 records out
136132 bytes (136 kB) copied, 0.000550122 s, 247 MB/s
2) Force the EC into its RO image:
done.
3) Erase the A and B images, then reprogram them:
Erasing 163840 bytes at offset 81920...
done.
Reading 136132 bytes from /home/chronos/user/ecb.bin...
Writing to offset 81920...
done.
4) Repeat step 3 about 10 times while monitoring the EC debug console.
Commands should complete successfully all the time. (Note that during
the flashwrite, there's a ton of debug output; what you should NOT see
is something like this:
WATCHDOG PC=00002104 / LR=0000597f / pSP=200013a0
Change-Id: I2f1f05eb19abcd6e19c6364f6d4ac785cca6a4c6
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
This CL add host command to enable, get/set flash write protect range.
BUG=None
TEST=Use flashrom utility to set write protect range, enable write
protect and get status.
Change-Id: I345f1eb65944d8cf8028e6fdb7e43c40cc742a6d
Signed-off-by: Rong Chang <rongchang@chromium.org>
