summaryrefslogtreecommitdiffstats
path: root/ft2232_spi.c
Commit message (Collapse)AuthorAgeFilesLines
* Add support for the Amontec JTAGkey2Jörg Fischer2010-07-291-17/+82
| | | | | | | | | | | | | | | | | | | | | | Add support for the Amontec JTAGkey2, see 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 Corresponding to flashrom svn r1119. Signed-off-by: Jörg Fischer <turboj@gmx.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Split off programmer.h from flash.hCarl-Daniel Hailfinger2010-07-271-0/+1
| | | | | | | | | | | | | | | | | | | | | 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 Corresponding to flashrom svn r1112. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Use generic unlocking infrastructure for SPI chipsCarl-Daniel Hailfinger2010-07-141-1/+0
| | | | | | | | | Actually check if the unlock worked instead of just assuming it worked. Corresponding to flashrom svn r1082. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* Convert SPI chips to partial writeCarl-Daniel Hailfinger2010-07-141-12/+2
| | | | | | | | | | However, wrap the write functions in a compat layer to allow converting the rest of flashrom later. Tested on Intel NM10 by David Hendricks. Corresponding to flashrom svn r1080. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* Unify programmer parameter extractionCarl-Daniel Hailfinger2010-07-081-2/+2
| | | | | | | | | | | Make programmer_param static by converting all users to extract_programmer_param. Programmer parameters can no longer be separated with a colon, they have to be separated with a comma. Corresponding to flashrom svn r1072. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* Various places in the flashrom source feature custom parameter extraction ↵Carl-Daniel Hailfinger2010-07-061-28/+31
| | | | | | | | | | | | | | | | | | | | 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! Corresponding to flashrom svn r1070. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* Kill global variables, constants and functions if local scope sufficesCarl-Daniel Hailfinger2010-07-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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. Corresponding to flashrom svn r1068. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* So far, we have up to 4 different names for the same thing (ignoring ↵Carl-Daniel Hailfinger2010-05-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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. Corresponding to flashrom svn r1023. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Introduce a generic SPI read function: spi_write_chunked()Carl-Daniel Hailfinger2010-05-211-19/+2
| | | | | | | | | | | | | | | Every SPI programmer driver had its own completely different chip write 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 Corresponding to flashrom svn r1005. 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>
* Split spi.c into programmer and chip code Remove chipdriver.h include from ↵Sean Nelson2010-02-261-0/+1
| | | | | | | | | | | | | | | | | | | 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>
* Convert all messages in ft2232_spi.c to the new message infrastructure. Sean Nelson2010-01-101-40/+29
| | | | | | | | | 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>
* Allow one to disable programmer debug messages at compile timeCarl-Daniel Hailfinger2010-01-071-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Programmer debug messages during programmer init/shutdown are useful 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. 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>
* Reduce realloc syscall overhead for FT2232 and bitbangCarl-Daniel Hailfinger2009-11-251-4/+12
| | | | | | | | | | | | 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>
* ft2232_spi: add some error handlingCarl-Daniel Hailfinger2009-11-221-4/+16
| | | | | | | | | | | | | | | | | | | | Pretty much everybody who used the FT2232 SPI driver had 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>
* Cosmetics and small coding style fixesUwe Hermann2009-10-011-35/+39
| | | | | | | | | 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>
* Fix all remaining issues reported by LLVM/clang's scan-buildStefan Reinauer2009-09-161-15/+12
| | | | | | | Corresponding to flashrom svn r723. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com>
* Store block sizes and corresponding erase functions in struct flashchipCarl-Daniel Hailfinger2009-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Standardize on using __func__ instead of __FUNCTION__Uwe Hermann2009-09-021-1/+1
| | | | | | | | | | | | | | | 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>
* If FT2232H SPI is not enabled, it should be compiled out completelyCarl-Daniel Hailfinger2009-08-191-28/+2
| | | | | | | | | | | 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>
* Use a common parameter variable for all programmersCarl-Daniel Hailfinger2009-08-121-10/+8
| | | | | | | | | | 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>
* Replace remaining explicit erases in SPI programmer drivers with auto-erasesCarl-Daniel Hailfinger2009-08-101-2/+8
| | | | | | | | | | | | | Some SPI chip drivers and the generic 1-byte SPI chip write functions 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. 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>
* Use a distinct return code for SPI commands with unsupported/invalid lengthCarl-Daniel Hailfinger2009-07-141-0/+3
| | | | | | | | | | | 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>
* Convert SPI byte program to use the multicommand infrastructureCarl-Daniel Hailfinger2009-07-121-1/+0
| | | | | | | | | | 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> Tested it on Epia-m700 worked okay. Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
* Add SPI multicommand infrastructureCarl-Daniel Hailfinger2009-07-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ft2232_spi: Allow runtime selection of FT2232H vs. FT4232H and interface A vsCarl-Daniel Hailfinger2009-07-011-5/+40
| | | | | | | | | | B. Corresponding to flashrom svn r638. 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>
* Random minor flashrom fixesUwe Hermann2009-06-281-1/+1
| | | | | | | | | | | | | | | - 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>
* This patch adds support for a new SPI programmer, based on the FT2232H/4232H ↵Paul Fox2009-06-161-0/+284
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>
OpenPOWER on IntegriCloud