| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|