summaryrefslogtreecommitdiff
path: root/spi.c
Commit message (Collapse)AuthorAgeFilesLines
...
* If a chip is not on the RDID generic vendor list nor on the REMShailfinger2009-11-201-0/+10
| | | | | | | | | | | | | | | 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]. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Marc Jones <marcj303@gmail.com> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@767 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* If a SPI command taking an address does fail, we want to know thehailfinger2009-11-161-13/+14
| | | | | | | | | | | | | address for easier debugging. Vincent wrote: This patch provided help to debug the partial write on ICH in descriptor mode. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Vincent S. Cojot <openlook@cojot.name> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@764 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Introduce proper error checking for SPI programming.hailfinger2009-10-011-2/+4
| | | | | | | | 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@739 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* The current ICH SPI preop handling is a hack which spews lots ofhailfinger2009-09-181-23/+22
| | | | | | | | | | | | | | | | | | warnings, 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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: FENG Yu Ning <fengyuning1984@gmail.com> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@727 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Allow to exclude each of the external programmer drivers from beinghailfinger2009-09-161-0/+4
| | | | | | | | | | | | | | | | | | compiled in. 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. 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@724 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* This is a patch which stores eraseblock sizes and corresponding blockhailfinger2009-09-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Standardize on using __func__ instead of __FUNCTION__.uwe2009-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. 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
* If FT2232H SPI is not enabled, it should be compiled out completely. Wehailfinger2009-08-191-0/+7
| | | | | | | | | | | | 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
* Some SPI chip drivers and the generic 1-byte SPI chip write functionshailfinger2009-08-101-0/+7
| | | | | | | | | | | | 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
* Fix SPI multicommand endless loop in default_spi_send_multicommand.hailfinger2009-08-031-0/+1
| | | | | | | | 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@670 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* This is a workaround for a bug in SB600 and SB700. If we only send anhailfinger2009-07-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. 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@661 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Verbose probe output is split across multiple lines for some probehailfinger2009-07-231-24/+32
| | | | | | | | | | | | | | | | functions. 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. 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@660 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Convert SPI write status register to multicommand infrastructure.hailfinger2009-07-221-26/+24
| | | | | | | | 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@658 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Replace most of the switch cases in the spi code with lookup on a structhailfinger2009-07-221-86/+124
| | | | | | | | | | | | | | | | instead. This brings the SPI code in line with the generic programmer infrastructure. This patch is a reworked version of a patch by Jakob Bornecrantz. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@657 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Convert SPI byte program to use the multicommand infrastructure.hailfinger2009-07-121-30/+56
| | | | | | | | | | 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
* Convert SPI block erase to use the multicommand infrastructure.hailfinger2009-07-111-25/+63
| | | | | | | | | | | | | 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> Tested-by: Jakob Bornecrantz <wallbraker@gmail.com> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@650 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Convert SPI chip erase to use the multicommand infrastructure.hailfinger2009-07-111-18/+62
| | | | | | | | | | | | Once the ICH/VIA SPI driver is converted to multicommand, a lot of hacks can disappear. 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@647 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add SPI multicommand infrastructure.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. 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
* Check result of all SPI erase functions.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. 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@630 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* This patch adds support for a new SPI programmer, based on thehailfinger2009-06-161-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* This patch gives us arbitrary range reads at byte boundaries for everyhailfinger2009-06-161-13/+25
| | | | | | | | | | | | | | single chip supported by flashrom. 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. 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@596 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* flash.h not only contains function prototypes and general settings, ithailfinger2009-06-151-0/+1
| | | | | | | | | | | | | | 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. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@594 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Every SPI host controller implemented its own way to read flash chips.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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@589 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add spi_nbyte_program as generic function to the SPI layer.hailfinger2009-06-121-0/+21
| | | | | | | | Signed-off-by: Paul Fox <pgf@laptop.org> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@583 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add external programmer delay functions so external programmers canhailfinger2009-06-051-8/+8
| | | | | | | | | | | handle the delay on their own if needed. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@578 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add bus type annotation to struct flashchips. Right now, the annotationhailfinger2009-05-311-40/+43
| | | | | | | | | | | | | | | | | | | | 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. 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@556 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Use consistent naming for local chip ID variables. Every chip besideshailfinger2009-05-271-23/+21
| | | | | | | | | | | | | 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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@551 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Drop unused/duplicated #includes and some dead code (trivial).uwe2009-05-161-3/+0
| | | | | | | | | | | Build-tested on 32bit x86. 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@521 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Until the ICH SPI driver can handle preopcodes as standalone opcodes, wehailfinger2009-05-151-4/+29
| | | | | | | | | | | | | | | | | | | | | 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. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@514 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Add a dummy SPI controller driver, similar to the dummy LPC/FWH/Parallelhailfinger2009-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. 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@507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Generic status register prettyprinting for SST25*. Even if we don't tellhailfinger2009-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@505 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* There are various reasons why a SPI command can fail. Among others, Ihailfinger2009-05-131-11/+44
| | | | | | | | | | | | | | | | | | | | | | | 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. 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@500 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Convert all flashchips.c entries with SPI programing to the 256-bytehailfinger2009-05-091-1/+1
| | | | | | | | | | | | | | version by default. Change the flashchips entry for SST SST25VF080B to 1-byte writing. Tested-by: Ali Nadalizadeh. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@486 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Chips like the SST SST25VF080B can only handle single byte writeshailfinger2009-05-091-5/+31
| | | | | | | | | | | | | | | | | | | outside 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. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@485 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Until the ICH SPI driver can handle preopcodes as standalone opcodes, wehailfinger2009-05-091-11/+36
| | | | | | | | | | | | | | | 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! 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@484 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Improve SST25 status register routines: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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@468 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 4117uwe2009-04-151-12/+13
| | | | | | | | | | | Some coding style and consistency fixes (trivial). 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@429 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3913stuge2009-01-261-0/+26
| | | | | | | | | | | | | | | | flashrom: SST25VF040B using 0x90 identification and AAI write. 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. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@407 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3912stuge2009-01-261-1/+26
| | | | | | | | | | flashrom: Decode SST25VF040B status register, also from July 2008. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@406 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3910stuge2009-01-261-1/+8
| | | | | | | | | | | | | flashrom: Winbond SuperIO SPI driver. 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! Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Ward Vandewege <ward@gnu.org> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@404 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3895stuge2009-01-251-1/+1
| | | | | | | | | | flashrom: Beautify flash chip ID verbose printout a little, always use %02x. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@390 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3779uwe2008-11-281-3/+24
| | | | | | | | | | | | | | Add support for the AMD/ATI SB600 southbridge SPI functionality. This has been tested by Uwe Hermann on an RS690/SB600 board. 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> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3775hailfinger2008-11-281-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | Flashrom already has the following probe functions: - 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 Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@349 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3774hailfinger2008-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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: FENG yu ning <fengyuning1984@gmail.com> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@348 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3757hailfinger2008-11-181-17/+66
| | | | | | | | | | | | | | | | | | | | | | | | | Check for failed SPI command execution in flashrom. 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. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Otherwise: Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@345 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3722hailfinger2008-11-031-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | Add additional SPI sector erase and chip erase command functions to flashrom. Not all chips support all commands, so allow the implementer to select the matching function. Fix a layering violation in ICH SPI code to be less bad. Still not perfect, but the new code is shorter, more generic and architecturally more sound. TODO (in a separate patch): - move the generic sector erase code to spi.c - decide which erase command to use based on info about the chip - create a generic spi_erase_all_sectors function which calls the generic sector erase function Thanks to Stefan for reviewing and commenting. 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@337 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3707stepan2008-10-291-0/+23
| | | | | | | | | | | | | Flashrom support for some Numonyx parts (M25PE) using block erase d8 as discussed with Peter Stuge Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@333 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3669uwe2008-10-181-43/+53
| | | | | | | | | | | Coding-style fixes for flashrom, partly indent-aided (trivial). 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@326 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3418stuge2008-07-071-27/+12
| | | | | | | | | | | | | | | | | | | | flashrom: Trivial SPI cleanups While writing a new SPI driver I fixed some things in the SPI code: All calls to spi_command() had unneccessary #define duplications, and in some cases the read count define could theoretically become harmful because NULL was passed for the read buffer. Avoid a crash, should someone change the #defines. I also noticed that the only caller of spi_page_program() was the it87 driver, and spi_page_program() could only call back into the it87 driver. Removed the function for easier-to-follow code and made it8716f_spi_page_program() static. The ichspi driver's static page functions are already static. Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@302 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* Original v2 revision: 3401stepan2008-06-301-22/+47
| | | | | | | | | | | | | | | | | | | | | First attempt to clean up SPI probing and create a common construct: the flash bus. At some point the flash bus will be part of struct flashchip. Pardon me for pushing this in, but I think it is important to beware of further decay and it will improve things for other developers in the short run. Carl-Daniel, I will consider your suggestions in another patch. I want to keep things from getting too much for now. The patch includes Rudolf's VIA SPI changes though. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: https://code.coreboot.org/svn/flashrom/trunk@285 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
View Lorry Controller Status