| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
flash.h
Some of the spi programmer drivers required chipdrivers.h, needs fixing later:
it87spi.c ichspi.c sb600spi.c wbsio_spi.c buspirate_spi.c ft2232spi.c
bitbang_spi.c dediprog.c
Corresponding to flashrom svn r914.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
| |
Fix one pinfo message to be pdbg.
Corresponding to flashrom svn r854.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
FT2232 ran realloc() for every executed command. Start with a big enough
buffer and don't touch buffer size unless it needs to grow.
Bitbang was slightly better: It only ran realloc() if buffer size
changed. Still, the solution above improves performance and reliability.
Corresponding to flashrom svn r780.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
problems with incorrect reads from time to time
One reason was that the hardware is pretty timing sensitive even for reads.
The other reason was that the code silently ignored errors. This patch doesn't
add any error recovery, but it will emit error messages if FT2232 communication
goes wrong. That allows us to track down errors without investing hours in
driver debugging. Thanks to Jeremy Buseman <naviathan@gmail.com> for testing.
He found out that certain libftdi/libusb/kernel/hardware combinations drop
some bytes without returning any error codes.
Corresponding to flashrom svn r769.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Paul Fox <pgf@laptop.org>
|
|
|
|
|
|
|
|
|
| |
Also, introduce BITMODE_BITBANG_SPI to eliminate a magic value.
Corresponding to flashrom svn r742.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The __func__ variant is standardized in C99 and recommended to be
used instead of __FUNCTION__ in the gcc info page.
Only _very_ old versions of gcc did not know about __func__, but we've
been using both __func__ and __FUNCTION__ for a long while now, and
nobody complained about this, so all our users seem to use recent
enough compilers.
Corresponding to flashrom svn r711.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
|
| |
We can't remove ft2232_spi.o from unconditional OBJS yet due to our makefile
structure (make features), but this patch adds #ifdefs around all FT2232H code,
so the net effect is the same.
Corresponding to flashrom svn r691.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
|
|
|
|
|
|
|
|
|
|
| |
This allows us to reduce #ifdef clauses a lot if we compile out some
programmers completely.
Corresponding to flashrom svn r679.
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
B. Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Corresponding to flashrom svn r638.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Properly escape '-' chars in manpage.
- Fix typo in chipset_enable.c.
- Drop useless 'return' in chip_readn().
- Random other whitespace or cosmetic fixes.
Corresponding to flashrom svn r636.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|
|
chip from FTDI
FTDI support is autodetected during compilation. Paul writes: There are
certainly possible improvements: The code has hard-coded values for which
interface of the ftdi chip to use (interface B was chosen because libftdi seems
to have trouble with A right now), what clock rate use for the SPI interface
(I've been running at 30Mhz, but the patch sets it to 10Mhz), and possibly
others. I think this means that per-programmer options might be a good idea
at some point. Carl-Daniel writes: There is one additional FIXME comment in
the code, but AFAICS that problem is not solvable with current libftdi.
Corresponding to flashrom svn r598.
Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
|