Simon Glass 21c1bf9628 flash: Only erase flash block that contain data
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>
2012-08-23 14:40:01 -07:00
2012-08-19 09:56:32 -07:00
2012-02-14 11:46:16 -08:00
2012-05-11 09:11:52 -07:00
2012-08-10 09:28:34 -07:00
2012-08-10 09:28:34 -07:00
2011-12-08 19:18:06 +00:00
2012-06-22 10:13:36 -07:00

- EC Lib

This wraps Blizzard driverlib and implements the EC chip interface defined
by Google. See below diagram for architecture.


  +--------------------+
  |   Host BIOS/OS     |
  +--------------------+

 ---- host interface ----

  +--------------------+
  | Google EC features |
  +--------------------+

 ---- chip interface ----  The interface is defined in
                           src/platform/ec/chip_interface/*.
  +--------------------+   But the real implementation is in EC Lib.
  |       EC Lib       |
  +--------------------+
  | Blizzard low level |
  |   driver, the      |
  |   driverlib.       |
  +--------------------+


Build Options
=============

- CONFIG_WATCHDOG_HELP

	Try to detect a watchdog that is about to fire, and print a trace.
	This is needed on STM32, where the independent watchdog has no early
	warning feature and the windowed watchdog has a very short period.

- CONFIG_PANIC_NEW_STACK

	When reporting a panic, change to a completely new stack. This might
	help get a useful trace out a situation where the stack or stack
	pointer has been corrupted.

- CONFIG_PANIC_HELP

	Report extra information about a panic, such as the fault address,
	here shown as bfar. This shows the reason for the fault and may help
	to determine the cause.

	=== EXCEPTION: 03 ====== xPSR: 01000000 ===========
	r0 :0000000b r1 :00000047 r2 :60000000 r3 :200013dd
	r4 :00000000 r5 :080053f4 r6 :200013d0 r7 :00000002
	r8 :00000000 r9 :200013de r10:00000000 r11:00000000
	r12:00000000 sp :200009a0 lr :08002b85 pc :08003a8a
	Precise data bus error, Forced hard fault, Vector catch, bfar = 60000000
	mmfs = 00008200, shcsr = 00000000, hfsr = 40000000, dfsr = 00000008

- CONFIG_ASSERT_HELP

	Report assertion failures in a vebose manner to aid debugging. When
	enabled an ASSERT() which fails will produce message in the form:

		ASSERTION FAILURE '<expr>' in function() at file:line
Description
No description provided
Readme 1.4 GiB
Languages
C 64.7%
Lasso 20.7%
ASL 3.6%
JavaScript 3.2%
C# 2.9%
Other 4.6%