aboutsummaryrefslogtreecommitdiffstats
path: root/spi.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't use "byte" as identifierMichael Karcher2010-01-121-2/+2
| | | | | | | | | | Some mingw declares a global identifier "byte", causing -Werror -Wshadow to break compilation. This patch renames all identifiers called "byte". Corresponding to flashrom svn r861. Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Add a few FIXME comments to the generic SPI codeCarl-Daniel Hailfinger2009-12-221-0/+2
| | | | | | | Corresponding to flashrom svn r814. 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>
* Internal (onboard) programming was the only feature which could not be disabledCarl-Daniel Hailfinger2009-12-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Make various pieces of code conditional on support for internal programming. Code shared between PCI device programmers and onboard programming is now conditional as well. It is now possible to build only with dummy support: make CONFIG_INTERNAL=no CONFIG_NIC3COM=no CONFIG_SATASII=no CONFIG_DRKAISER=no CONFIG_SERPROG=no CONFIG_FT2232SPI=no This allows building for a specific use case only, and it also facilitates porting to a new architecture because it is possible to focus on highlevel code only. Note: Either internal or dummy programmer needs to be compiled in due to the current behaviour of always picking a default programmer if -p is not specified. Picking an arbitrary external programmer as default wouldn't make sense. Build and runtime tested in all 1024 possible build combinations. The only failures are by design as mentioned above. Corresponding to flashrom svn r797. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Sean Nelson <audiohacked@gmail.com>
* Add the ability to set Bus Pirate SPI speed via the command lineCarl-Daniel Hailfinger2009-11-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Example usage: flashrom -p buspiratespi:spispeed=2.6MHz,dev=/dev/foo flashrom -p buspiratespi:dev=/dev/foo,spispeed=2.6M Refactor programmer option parsing (this allows cleanups in other programmers as well). Increase SPI read size from 8 to 12 bytes (current single-transaction limit of the Bus Pirate raw SPI protocol). Add Bus Pirate to the list of programmers supporting 4 byte RDID. Add Bus Pirate syntax to the man page. Tested-by: Sean Nelson <audiohacked@gmail.com> Corresponding to flashrom svn r776. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Sean Nelson <audiohacked@gmail.com>
* Cleanly validate ICH SPI preopcodesCarl-Daniel Hailfinger2009-11-241-0/+9
| | | | | | | | | | | | | | | | | | | The code should work on Linux/*BSD/MacOSX and relies on the serial code implementation in serial.c. Support for additional platforms (Windows) will have to be added to serial.c for this to work. For tests without a Bus Pirate (or with non-functional serial code) it is possible to #define FAKE_COMMUNICATION in buspirate_spi.c. Thanks to Sean Nelson for the SPI mode settings code. I tweaked it a bit to make configuration from a commandline easier should anybody want that feature. Tested-by: Sean Nelson <audiohacked@gmail.com> Corresponding to flashrom svn r772. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Sean Nelson <audiohacked@gmail.com>
* Add support for generic RDID and REMS matching of unknown chipsCarl-Daniel Hailfinger2009-11-201-0/+10
| | | | | | | | | | | | | | | | If a chip is not on the RDID generic vendor list nor on the REMS specific ID list, flashrom will claim that no chip is there. Handle these cases gracefully. flashrom will ignore generic matches if a specific chip was found, so this will have no impact on supported chips, but help a lot for a first quick analysis by the user or developer. The only drawback is that unknown chips may be recognized multiple times until they are added to flashchips.[ch]. Corresponding to flashrom svn r767. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Marc Jones <marcj303@gmail.com>
* If a SPI command taking an address does fail, we want to know the address ↵Carl-Daniel Hailfinger2009-11-161-13/+14
| | | | | | | | | | | | for easier debugging Vincent wrote: This patch provided help to debug the partial write on ICH in descriptor mode. Corresponding to flashrom svn r764. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Vincent S. Cojot <openlook@cojot.name>
* Introduce proper error checking for SPI programmingCarl-Daniel Hailfinger2009-10-011-2/+4
| | | | | | | 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>
* The current ICH SPI preop handling is a hack which spews lots of warnings, ↵Carl-Daniel Hailfinger2009-09-181-23/+22
| | | | | | | | | | | | | | | | | | but still yields correct results With the multicommand infrastructure I introduced in r645, it became possible to integrate ICH SPI preopcodes cleanly into the flashrom design. The new code checks for every opcode in a multicommand array if it is a preopcode. If yes, it checks if the next opcode is associated with that preopcode and in that case it simply runs the opcode because the correct preopcode will be run automatically before the opcode. Corresponding to flashrom svn r727. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: FENG Yu Ning <fengyuning1984@gmail.com>
* Allow to exclude each of the external programmer drivers from being compiled inCarl-Daniel Hailfinger2009-09-161-0/+4
| | | | | | | | | | | | | | | Example make commandline if you want only internal programmers: make CONFIG_FT2232SPI=no CONFIG_SERPROG=no CONFIG_NIC3COM=no CONFIG_SATASII=no CONFIG_DRKAISER=no CONFIG_DUMMY=no Of course, all of the CONFIG_* symbols can be mixed and matched as needed. CONFIG_FT2232SPI is special because even if it is enabled, make will check if the headers are available and skip it otherwise. Corresponding to flashrom svn r724. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* Store block sizes and corresponding erase functions in struct flashchipCarl-Daniel Hailfinger2009-09-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | | 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-0/+7
| | | | | | | | | | | 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>
* Replace remaining explicit erases in SPI programmer drivers with auto-erasesCarl-Daniel Hailfinger2009-08-101-0/+7
| | | | | | | | | | | | | 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>
* Fix SPI multicommand endless loop in default_spi_send_multicommandCarl-Daniel Hailfinger2009-08-031-0/+1
| | | | | | | Corresponding to flashrom svn r670. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* This is a workaround for a bug in SB600 and SB700Carl-Daniel Hailfinger2009-07-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Verbose probe output is split across multiple lines for some probe functionsCarl-Daniel Hailfinger2009-07-231-24/+32
| | | | | | | | | | | | | This makes visual inspection and grepping a lot harder than necessary. Remove line breaks where appropriate. Some error messages should end up on stderr instead of just being displayed in verbose mode. Thanks to Maciej Pijanka for testing. Corresponding to flashrom svn r660. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* Convert SPI write status register to multicommand infrastructureCarl-Daniel Hailfinger2009-07-221-26/+24
| | | | | | | Corresponding to flashrom svn r658. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* Replace most of the switch cases in the spi code with lookup on a struct insteadCarl-Daniel Hailfinger2009-07-221-86/+124
| | | | | | | | | | | | | | | This brings the SPI code in line with the generic programmer infrastructure. This patch is a reworked version of a patch by Jakob Bornecrantz. Corresponding to flashrom svn r657. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Jakob Bornecrantz <wallbraker@gmail.com> Acked-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Jakob Bornecrantz <wallbraker@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Convert SPI byte program to use the multicommand infrastructureCarl-Daniel Hailfinger2009-07-121-30/+56
| | | | | | | | | | 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>
* Convert SPI block erase to use the multicommand infrastructureCarl-Daniel Hailfinger2009-07-111-25/+63
| | | | | | | | | | | | | Tested-by: Jakob Bornecrantz <wallbraker@gmail.com> Corresponding to flashrom svn r650. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Jakob writes: Tested it on my EPIA-m700 and it worked nice. Also double checked that one of the changed functions actually ran. Acked-by: Jakob Bornecrantz <wallbraker@gmail.com>
* Convert SPI chip erase to use the multicommand infrastructureCarl-Daniel Hailfinger2009-07-111-18/+62
| | | | | | | | | | | Once the ICH/VIA SPI driver is converted to multicommand, a lot of hacks can disappear. Corresponding to flashrom svn r647. 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>
* Add SPI multicommand infrastructureCarl-Daniel Hailfinger2009-07-101-27/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Check result of all SPI erase functionsCarl-Daniel Hailfinger2009-06-241-9/+50
| | | | | | | | | | | | | | Since block erase functions do not know the block length (it's not specified in any standard), block erase functions now get an additional parameter blocklen. This enables flashrom to verify the erase result for block erase functions at correct boundaries. Tested by Uwe on SB600. Corresponding to flashrom svn r630. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Support reads of arbitrary rangeCarl-Daniel Hailfinger2009-06-161-13/+25
| | | | | | | | | | | | 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>
* Split flashchips.h from flash.hCarl-Daniel Hailfinger2009-06-151-0/+1
| | | | | | | | | | | | | | Flash.h not only contains function prototypes and general settings, it also has a huge chunk of chip and vendor IDs in the middle. Split them out into a separate flashchips.h and adjust #include wherever needed. Corresponding to flashrom svn r594. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Urja Rannikko <urjaman@gmail.com> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* Every SPI host controller implemented its own way to read flash chipsCarl-Daniel Hailfinger2009-06-131-0/+27
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add spi_nbyte_program as generic function to the SPI layerPaul Fox2009-06-121-0/+21
| | | | | | | Corresponding to flashrom svn r583. Signed-off-by: Paul Fox <pgf@laptop.org> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Add programmer-specific delay functionsCarl-Daniel Hailfinger2009-06-051-8/+8
| | | | | | | | | | | Add external programmer delay functions so external programmers can handle the delay on their own if needed. Corresponding to flashrom svn r578. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Urja Rannikko <urjaman@gmail.com>
* Add bus type annotation to struct flashchipsCarl-Daniel Hailfinger2009-05-311-40/+43
| | | | | | | | | | | | | | | | | | | 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>
* Use consistent naming for local chip ID variablesCarl-Daniel Hailfinger2009-05-271-23/+21
| | | | | | | | | | | Every chip besides SPI and w39v080fa uses id1/id2 as local variable names to store ID responses from the flash chip. This eases grepping a lot. As a bonus, it also frees up some names to be used as parameters. Corresponding to flashrom svn r551. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
* Drop unused/duplicated #includes and some dead codeUwe Hermann2009-05-161-3/+0
| | | | | | | | | 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>
* Additionally to WREN also handle WRSR failures gracefully for ICHSPICarl-Daniel Hailfinger2009-05-151-4/+29
| | | | | | | | | | | | | | | | | | | | | Until the ICH SPI driver can handle preopcodes as standalone opcodes, we should handle such special opcode failure gracefully on ICH and compatible chipsets. This fixes status register writes on almost all ICH+VIA SPI masters. The fix is almost identical to r484, but this time it affects the EWSR (Enable Write Status Register) opcode instead of the WREN (Write Enable) opcode. With the differentiated return codes introduced in r500, the workaround is more precise this time. The old WREN workaround was updated as well. Corresponding to flashrom svn r514. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: FENG Yu Ning <fengyuning1984@gmail.com> Acked-by: Cristi Magherusan <cristi.magherusan@net.utcluj.ro>
* Add a dummy SPI controller driver, similar to the dummy LPC/FWH/Parallel ↵Carl-Daniel Hailfinger2009-05-141-2/+8
| | | | | | | | | | | | | | | | | flasher driver Does not support reading or writing the fake chip yet. flashrom --programmer dummy also enables the dummy SPI controller driver. Testing the dummy SPI driver revealed a RDID debug printing bug in the SPI core. Fix that as well. Corresponding to flashrom svn r507. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Generic status register prettyprinting for SST25*Carl-Daniel Hailfinger2009-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Even if we don't tell the user about the areas the block locking bits correspond to, printing a detailed list of which lock bits are set is a definite improvement. Corresponding to flashrom svn r505. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Sample output: [...] Probing for SST SST25VF032B, 4096 KB: RDID returned bf 25 4a. probe_spi_rdid_generic: id1 0xbf, id2 0x254a Chip status register is 1c Chip status register: Block Protect Write Disable (BPL) is not set Chip status register: Auto Address Increment Programming (AAI) is not set Chip status register: Bit 5 / Block Protect 3 (BP3) is not set Chip status register: Bit 4 / Block Protect 2 (BP2) is set Chip status register: Bit 3 / Block Protect 1 (BP1) is set Chip status register: Bit 2 / Block Protect 0 (BP0) is set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set Found chip "SST SST25VF032B" (4096 KB) at physical address 0xffc00000. Acked-by: Cristi Magherusan <cristi.magherusan@net.utcluj.ro>
* There are various reasons why a SPI command can failCarl-Daniel Hailfinger2009-05-131-11/+44
| | | | | | | | | | | | | | | | | | | | | Among others, I have seen the following problems: - The SPI opcode is not supported by the controller. ICH-style controllers exhibit this if SPI config is locked down. - The address in in a prohibited area. This can happen on ICH for any access (BBAR) and for writes in chipset write protected areas. - There is no SPI controller. Introduce separate error codes for unsupported opcode and prohibited address. Add the ability to adjust REMS and RES addresses to the minium supported read address with the help of spi_get_valid_read_addr(). That function needs to call SPI controller specific functions like reading BBAR on ICH. Corresponding to flashrom svn r500. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Convert all flashchips.c entries with SPI programing to the 256-byte version ↵Carl-Daniel Hailfinger2009-05-091-1/+1
| | | | | | | | | | | | | by default Change the flashchips entry for SST SST25VF080B to 1-byte writing. Tested-by: Ali Nadalizadeh. Corresponding to flashrom svn r486. 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>
* Chips like the SST SST25VF080B can only handle single byte writes outside ↵Carl-Daniel Hailfinger2009-05-091-5/+31
| | | | | | | | | | | | | | | | | | 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>
* Refine handling of spi_write_enable() failures to fix chip erases on ichspiCarl-Daniel Hailfinger2009-05-091-11/+36
| | | | | | | | | | | | | | | Until the ICH SPI driver can handle preopcodes as standalone opcodes, we 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>
* Improve SST25 status register routinesCarl-Daniel Hailfinger2009-05-061-11/+15
| | | | | | | | | | | | - Using a 4-bit index into an array with 8 elements leads to out-of-bounds accesses. Use proper bit masking to fix this. - Factor out common SST25 status register printing. - Use the common SST25 status register printing for SST25VF080B. Corresponding to flashrom svn r468. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Peter Stuge <peter@stuge.se>
* Some coding style and consistency fixesUwe Hermann2009-04-151-12/+13
| | | | | | | Corresponding to flashrom svn r429 and coreboot v2 svn r4117. Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* SST25VF040B using 0x90 identification and AAI writePeter Stuge2009-01-261-0/+26
| | | | | | | | | | | | | SST AAI is Auto Address Increment writing, a streamed write to the flash chip where the first write command sets a starting address and following commands simply append data. Unfortunately not supported by Winbond SPI masters. From July 2008. Corresponding to flashrom svn r407 and coreboot v2 svn r3913. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se>
* Decode SST25VF040B status register, also from July 2008Peter Stuge2009-01-261-1/+26
| | | | | | | Corresponding to flashrom svn r406 and coreboot v2 svn r3912. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se>
* Winbond SuperIO SPI driverPeter Stuge2009-01-261-1/+8
| | | | | | | | | | Developed and tested to work on Intel D201GLY in July 2008. Tested by a helpful person on IRC whose name I've since forgotten. Sorry! Corresponding to flashrom svn r404 and coreboot v2 svn r3910. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Ward Vandewege <ward@gnu.org>
* Beautify flash chip ID verbose printout a little, always use %02xPeter Stuge2009-01-251-1/+1
| | | | | | | Corresponding to flashrom svn r390 and coreboot v2 svn r3895. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se>
* Add support for the AMD/ATI SB600 southbridge SPI functionalityJason Wang2008-11-281-3/+24
| | | | | | | | | | This has been tested by Uwe Hermann on an RS690/SB600 board. Corresponding to flashrom svn r351 and coreboot v2 svn r3779. Signed-off-by: Jason Wang <Qingpei.Wang@amd.com> Reviewed-by: Joe Bao <zheng.bao@amd.com> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Flashrom already has the following probe functionsCarl-Daniel Hailfinger2008-11-281-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | - probe_spi_rdid with opcode 0x9f, usually 3 bytes ID - probe_spi_res with opcode 0xab, usually 1 byte ID We are missing the following probe function: - probe_spi_rems with opcode 0x90, usually 2 bytes ID RDID provides best specifity (manufacturer, device class and device) and RES is supported by quite a few old chips. However, RES only returns one byte and there are multiple flash chips with different sizes on the market and all of them have the same RES ID. REMS is from the same age as RES, but it provides a manufacturer and a device ID. It is therefore on par with the probing for parallel flash chips and specific enough. The order in which chips should be detected is as follows: 1. RDID 2. REMS 3. RES Corresponding to flashrom svn r349 and coreboot v2 svn r3775. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Peter Stuge <peter@stuge.se>
* Try RES even if RDID failsCarl-Daniel Hailfinger2008-11-271-7/+5
| | | | | | | | | | | | | | | | | | | The existing check in probe_spi_res() was right for SPI controllers which support all commands, but may not exist. For controllers which support only a subset of commands, it will fail in unexpected ways. Even if a command is supported by the controller, it may be unavailable if the controller is locked down. The new logic checks if RDID could be issued and its return values made sense (not 0xff 0xff 0xff). In that case, RES probing is not performed. Otherwise, we try RES. There is one drawback: If RDID returned unexpected values, we don't issue a RES probe. However, in that case we should try to match RDID anyway. Corresponding to flashrom svn r348 and coreboot v2 svn r3774. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: FENG yu ning <fengyuning1984@gmail.com>
* Check for failed SPI command executionCarl-Daniel Hailfinger2008-11-181-17/+66
| | | | | | | | | | | | | | | | | | | | | | | Although SPI itself does not have a mechanism to signal command failure, the SPI host may be unable to send a given command over the wire due to security or hardware limitations. The current code ignores these mechanisms completely and simply assumes almost every command succeeds. Complain if SPI command execution fails. Since locked down Intel chipsets (like the one we had problems with earlier) only allow a small subset of commands, find the common subset of commands between the chipset and the ROM in the chip erase case. That is accomplished by the new spi_chip_erase_60_c7() which can be used for chips supporting both 0x60 and 0xc7 chip erase commands. Both parts of the patch address problems seen in the real world. The increased verbosity for the error case will help us diagnose and address problems better. Corresponding to flashrom svn r345 and coreboot v2 svn r3757. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Otherwise: Acked-by: Stefan Reinauer <stepan@coresystems.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 20:41:38 +0000