| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Corresponding to flashrom svn r857.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
they print hardware settings and desired configuration
They help in getting a quick overview of hardware and software state on
startup and shutdown. Programmer debug messages during flash chip access are
mostly a distraction in logs and should only be enabled if someone is having
problems which are suspected to stem from a programmer hardware or programmer
software bug. Disable those messages by default, they can be reenabled by
#define COMM_DEBUG in the affected programmer file. An added benefit is a
tremendous size reduction in verbose probe/read/write/erase logs because only
flash chip driver messages remain. In some cases, logs will shrink from 65
MB to 10 kB or less. The right(tm) fix would be two different debug levels
(DEBUG and SPEW) and the ability to differentiate between programmer debug
messages and flash chip debug messages. Until the design for the message
printing infrastructure is finished, this is the best stop-gap measure
we can get.
Corresponding to flashrom svn r834.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audioahcked@gmail.com>
|
|
|
|
|
|
|
| |
Corresponding to flashrom svn r739.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
| |
without warnings
Corresponding to flashrom svn r723.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions in struct flashchip
I decided to fill in the info for a few chips to illustrate how this works
both for uniform and non-uniform sector sizes. struct eraseblock{ int size;
/* Eraseblock size */ int count; /* Number of contiguous blocks with that
size */ }; struct eraseblock doesn't correspond with a single erase block,
but with a group of contiguous erase blocks having the same size. Given a
(top boot block) flash chip with the following weird, but real-life structure:
top 16384 8192 8192 32768 65536 65536 65536 65536 65536 65536 65536 bottom we
get the following encoding: {65536,7},{32768,1},{8192,2},{16384,1} Although
the number of blocks is bigger than 4, the number of block groups is only 4.
If you ever add some flash chips with more than 4 contiguous block groups,
the definition will not fit into the 4-member array anymore and gcc will
recognize that and error out. No undetected overflow possible. In that case,
you simply increase array size a bit. For modern flash chips with uniform
erase block size, you only need one array member anyway. Of course data types
will need to be changed if you ever get flash chips with more than 2^30
erase blocks, but even with the lowest known erase granularity of 256 bytes,
these flash chips will have to have a size of a quarter Terabyte. I'm pretty
confident we won't see such big EEPROMs in the near future (or at least not
attached in a way that makes flashrom usable). For SPI chips, we even have
a guaranteed safety factor of 4096 over the maximum SPI chip size (which is
2^24). And if such a big flash chip has uniform erase block size, you could
even split it among the 4 array members. If you change int count to unsigned
int count, the storable size doubles. So with a split and a slight change
of data type, the maximum ROM chip size is 2 Terabytes. Since many chips
have multiple block erase functions where the eraseblock layout depends on
the block erase function, this patch couples the block erase functions with
their eraseblock layouts. struct block_eraser { struct eraseblock{ unsigned
int size; /* Eraseblock size */ unsigned int count; /* Number of contiguous
blocks with that size */ } eraseblocks[NUM_ERASEREGIONS]; int (*block_erase)
(struct flashchip *flash, unsigned int blockaddr, unsigned int blocklen);
} block_erasers[NUM_ERASEFUNCTIONS];
Corresponding to flashrom svn r719.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
include the automatic erase present in other chip drivers
Since the majority is definitely auto-erase, change the remaining
explicit-erase cases to be auto-erase as well.
Corresponding to flashrom svn r673.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carlos Arnau Perez <cemede@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Serprog compilation is now controlled by a Makefile variable.
Replace munmap with physunmap where appropriate.
Corresponding to flashrom svn r671.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we only send an opcode and no additional data/address, the SPI controller
will read one byte too few from the chip. Basically, the last byte of the chip
response is discarded and will not end up in the FIFO. It is unclear if the
CS# line is set high too early as well. That hardware bug is undocumented as
of now, but I'm working with AMD to add a detailed description of it to the
errata. Add loads of additional debugging to SB600/SB700 init. Add explanatory
comments for unintuitive code flow. Thanks go to Uwe for testing quite a few
iterations of the patch. Kill the SB600 flash chip status register special
case, which was a somewhat misguided workaround for that hardware erratum.
Note for future added features in the SB600 SPI driver: It may be possible to
read up to 15 bytes of command response with overlapping reads due to the ring
buffer design of the FIFO if the command can be repeated without ill effects.
Same for skipping up to 7 bytes between command and response.
Corresponding to flashrom svn r661.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Some drivers support only a few combinations of read/write length and return
error otherwise. Having a distinct return code for this error means we can
handle it in upper layers.
Corresponding to flashrom svn r653.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
| |
Tested it on Epia-m700 worked okay.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r651.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some SPI opcodes need to be sent in direct succession after each other
without any chip deselect happening in between. A prominent example is
WREN (Write Enable) directly before PP (Page Program). Intel calls the
first opcode in such a row "preopcode".
Right now, we ignore the direct succession requirement completely and it
works pretty well because most onboard SPI masters have a timing or
heuristics which make the problem disappear.
The FT2232 SPI flasher is different. Since it is an external flasher,
timing is very different to what we can expect from onboard flashers and
this leads to failure at slow speeds.
This patch allows any function to submit multiple SPI commands in a
stream to any flasher. Support in the individual flashers isn't
implemented yet, so there is one generic function which passes the each
command in the stream one-by-one to the command functions of the
selected SPI flash driver.
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r645.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Make a few local functions in sb600spi.c static.
Corresponding to flashrom svn r623.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Luc Verhaegen <libv@skynet.be>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
single chip supported by flashrom
That means you can tell flashrom to read exactly bytes 12345-56789 (start
12345, length 44445) and it will not fetch a single byte more. Uwe tested
this on one LPC, one SPI, and one parallel flash board.
Corresponding to flashrom svn r596.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And even when it checks if the erase worked, the result of that check is
often ignored.
Convert all erase functions and actually check return codes
almost everywhere.
Check inside all erase_* routines if erase worked, not outside.
erase_sector_jedec and erase_block_jedec have changed prototypes to
enable erase checking.
Uwe successfully tested LPC on an CK804 box and SPI on some SB600 box.
Corresponding to flashrom svn r595.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was partly due to a design problem in the abstraction layer.
There should be exactly two different functions for reading SPI chips:
- memory mapped reads
- SPI command reads.
Each of them should be contained in a separate function, optionally
taking parameters where needed.
This patch solves the problems mentioned above, shortens the code and
makes the code logic a lot more obvious.
Since open-coding the min() function leads to errors, include it in this
patch as well.
Corresponding to flashrom svn r589.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, the annotation only differentiates between SPI and non-SPI. Anyone
who knows more about a specific flash chip should feel free to update it.
The existing flashbus variable was abused to denote the SPI controller type.
Use an aptly named variable for that purpose. Once this patch is merged,
the chipset/programmer init functions can set supported flash chip types
and flashrom can automatically select only matching probe/read/erase/write
functions. A side benefit of that will be the elimination of the Winbond
W29EE011 vs. AMIC A49LF040A conflict.
Corresponding to flashrom svn r556.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some MMIO accesses used volatile, others didn't (and risked non-execution
of side effects) and even with volatile, some accesses looked dubious.
Since the MMIO accessor functions and the onboard flash accessor functions
are functionally identical (but have different signatures), make the flash
accessors wrappers for the MMIO accessors. For some of the conversions,
I used Coccinelle. Semantic patch follows: @@ typedef uint8_t; expression a;
volatile uint8_t *b; @@ - b[a] + *(b + a) @@ expression a; volatile uint8_t *b;
@@ - *(b) |= (a); + *(b) = *(b) | (a); @@ expression a; volatile uint8_t *b;
@@ - *(b) = (a); + mmio_writeb(a, b); @@ volatile uint8_t *b; @@ - *(b)
+ mmio_readb(b) @@ type T; T b; @@ ( mmio_readb | mmio_writeb ) (..., - (T)
- (b) + b ) Uwe tested read, write, erase with this patch on a random board
to make sure nothing breaks.
Corresponding to flashrom svn r524.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
| |
Build-tested on 32bit x86.
Corresponding to flashrom svn r521.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AAI mode
Change SPI architecture to handle 1-byte chunk chip writing differently from
256-byte chunk chip writing. Annotate SPI chip write functions with _256
or _1 suffix denoting the number of bytes they write at maximum. The 1-byte
chunk writing is cut-n-pasted to different SPI drivers right now. A later
patch can move them to the generic spi_chip_write_1.
Corresponding to flashrom svn r485.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
should handle such special opcode failure gracefully on ICH and
Compatible chipsets. This fixes chip erase on almost all ICH+VIA SPI masters.
Thanks to Ali Nadalizadeh for helping track down this bug!
Corresponding to flashrom svn r484.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
| |
Add missing copyright year.
Corresponding to flashrom svn r428 and coreboot v2 svn r4107.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
|
|
|
|
|
|
|
| |
Reviewed-by: Joe, Bao <Zheng.Bao@amd.com>
Corresponding to flashrom svn r354 and coreboot v2 svn r3782.
Signed-off-by: Jason Wang <Qingpei.wang@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
This has been tested by Uwe Hermann on an RS690/SB600 board.
Reviewed-by: Joe Bao <zheng.bao@amd.com>
Corresponding to flashrom svn r351 and coreboot v2 svn r3779.
Signed-off-by: Jason Wang <Qingpei.Wang@amd.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|