| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Various whitespace- and cosmetic fixes. Also, Use %04x:%04x for printing
the USB IDs (which are 4 hex digits long), not %02x:%02x.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1123 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://www.amontec.com/jtagkey2.shtml
http://www.amontec.com/jtagkey.shtml
This FTDI 2232H variant has an additional output enable, which will be
set to its "on" (L) when CS is pulled low.
But it lacks a power supply and you need an external 3.3V source.
The attached patch adds "jtagkey" as "type" parameter for ft2232_spi.
It should work with all JTAGkeys (JTAGkey, JTAGkey-tiny and JTAGkey2)
but I only have a JTAGkey2 here for testing.
Add all FT2232H/FT4232H based programmers to the list printed with
flashrom -L
Signed-off-by: Jörg Fischer <turboj@gmx.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1119 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Programmer specific functions are of absolutely no interest to any file
except those dealing with programmer specific actions (special SPI
commands and the generic core).
The new header structure is as follows (and yes, improvements are
possible):
flashchips.h flash chip IDs
chipdrivers.h chip-specific read/write/... functions
flash.h common header for all stuff that doesn't fit elsewhere
hwaccess.h hardware access functions
programmer.h programmer specific functions
coreboot_tables.h header from coreboot, internal programmer only
spi.h SPI command definitions
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1112 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
| |
Actually check if the unlock worked instead of just assuming it worked.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1082 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compat layer to allow converting the rest of flashrom later.
I actually have patches for most of the remaining conversion, but I
wanted to get this out and reviewed first.
Tested on Intel NM10 by David Hendricks.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1080 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
| |
extract_programmer_param.
Programmer parameters can no longer be separated with a
colon, they have to be separated with a comma.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1072 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extraction from programmer_param. This led to wildly differing syntax
for programmer parameters, and it also voids pretty much every
assumption you could make about programmer_param. The latter is a
problem for libflashrom.
Use extract_param everywhere, clean up related code and make it more
foolproof.
Add two instances of exit(1) where we have no option to return an error.
Remove six instances of exit(1) where returning an error was possible.
WARNING: This changes programmer parameter syntax for a few programmers!
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1070 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Constify variables where possible.
Initialize programmer-related variables explicitly in programmer_init to
allow running programmer_init from a clean state after
programmer_shutdown.
Prohibit registering programmer shutdown functions before init or after
shutdown.
Kill some dead code.
Rename global variables with namespace-polluting names.
Use a previously unused locking helper function in sst49lfxxxc.c.
This is needed for libflashrom.
Effects on the binary size of flashrom are minimal (300 bytes
shrinkage), but the data section shrinks by 4384 bytes, and that's a
good thing if flashrom is operating in constrained envionments.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1068 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
capitalization):
CONFIG_FT2232SPI (makefile config option)
FT2232_SPI_SUPPORT (#define)
ft2232spi (programmer name)
ft2232_spi.c (programmer file)
Use CONFIG_* with underscores for makefile config options and #defines
and kill the useless _SUPPORT idiom.
Use lowercase names with underscores for programmer names and programmer
files.
With this, you can run "grep -i ft2232_spi" and find everything related
to the ft2232_spi driver. Same applies to all other programmers.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1023 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation, and all of them were insufficiently commented.
Create spi_write_chunked as a copy of spi_read_chunked and convert all
SPI programmers to use it.
No functional changes except:
- Bus Pirate uses 12 Byte writes instead of 8 Byte writes
- SB600 uses 5 Byte writes instead of 1 Byte writes
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: David Hendricks <dhendrix@google.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@1005 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove chipdriver.h include from 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
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@914 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
| |
Fix one pinfo message to be pdbg.
Signed-off-by: Sean Nelson <audiohacked@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@854 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because 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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audioahcked@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@834 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@780 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Paul Fox <pgf@laptop.org>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@769 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
| |
Also, introduce BITMODE_BITBANG_SPI to eliminate a magic value.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@742 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
| |
without warnings.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@723 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
erase 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];
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@719 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@711 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@691 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
| |
reduce #ifdef clauses a lot if we compile out some programmers
completely.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@679 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
| |
didn't 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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carlos Arnau Perez <cemede@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@673 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
length.
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@653 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested it on Epia-m700 worked okay.
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@651 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@645 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
| |
interface A vs. B.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Jakob Bornecrantz <wallbraker@gmail.com>
Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@638 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Properly escape '-' chars in manpage.
- Fix typo in chipset_enable.c.
- Drop useless 'return' in chip_readn().
- Random other whitespace or cosmetic fixes.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@636 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
FT2232H/4232H 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.
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>
git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@598 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|