aboutsummaryrefslogtreecommitdiffstats
path: root/sb600spi.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Automatically unmap physmap()sStefan Tauner2013-08-141-2/+4
| | | | | | | | | | | | Similarly to the previous PCI self-clean up patch this one allows to get rid of a huge number of programmer shutdown functions and makes introducing bugs harder. It adds a new function rphysmap() that takes care of unmapping at shutdown. Callers are changed where it makes sense. Corresponding to flashrom svn r1714. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Detect AMD Yangtze (found in Kabini and Tamesh)Stefan Tauner2013-08-081-5/+64
| | | | | | | | | | | | | | | | | | | | | | | The PCI ID of the LPC bridge doesn't change between Hudson-2/3/4 and Yangtze (Kabini/Temash) but the SPI interface does. Bail out in case we detect Yangtze and add infrastructure to distinguish other families too for further refactorings. Also, add ASRock IMB-A180 to the laptop whitelist and refine the IMC warning a bit. Tested on ASRock IMB-A180 with and w/o USE_YANGTZE_HEURISTICS, and by Chris Goodrich from Sage on - SB600 - SB700 - SB800 - Hudson 3 (A70M) - Kabini Corresponding to flashrom svn r1706. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
* sbxxx: Handle active IMCs in AMD chipsetsRudolf Marek2013-07-251-20/+55
| | | | | | | | | | | | Detect and temporarily disable the IMC while accessing the flash. Disable writes on default, but allow the user to enforce it. Corresponding to flashrom svn r1704. Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: David Hendricks <dhendrix@google.com>
* sbxxx: spibar[0] debug print refinementsStefan Tauner2013-06-161-2/+3
| | | | | | | | | | | | Newer models support a 66 MHz clock and fast reads. We should probably distinguish the models better (as we do in ichspi) and add support for frequency selection etc. For now this has to suffice. Corresponding to flashrom svn r1678. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
* Hide hwaccess.h from public APIPatrick Georgi2012-07-201-0/+1
| | | | | | | | | | | | | Move hwaccess.h #include from flash.h to individual drivers. libflashrom users need flash.h, but they do not care about hwaccess.h and should not see its definitions because they may conflict with other hardware access functions and #defines used by the libflashrom user. Corresponding to flashrom svn r1549. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Let the programmer driver decide how to do AAI transfersNico Huber2012-06-151-0/+1
| | | | | | | | | | | | | | | | Currently spi_aai_write() is implemented without an abstraction mechanism for the programmer driver. This adds another function pointer 'write_aai' to struct spi_programmer, which is set to default_spi_write_aai (renamed spi_aai_write) for all programmers for now. A patch which utilises this abstraction in the dediprog driver will follow. Corresponding to flashrom svn r1543. Signed-off-by: Nico Huber <nico.huber@secunet.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Add struct flashctx * parameter to all functions accessing flash chipsCarl-Daniel Hailfinger2011-12-181-2/+4
| | | | | | | | | | | | | | | | All programmer access function prototypes except init have been made static and moved to the respective file. A few internal functions in flash chip drivers had chipaddr parameters which are no longer needed. The lines touched by flashctx changes have been adjusted to 80 columns except in header files. Corresponding to flashrom svn r1474. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
* Add AMD Hudson chipset-enableWang Qing Pei2011-08-261-2/+5
| | | | | | | | | | AMD Hudson has different vendor/device IDs than AMD SBx00, handle that properly. Corresponding to flashrom svn r1422. Signed-off-by: Wang Qing Pei <wangqingpei@gmail.com> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Remove unneeded inclusions of chipdrivers.hStefan Tauner2011-08-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | This is related to the spi split patch as discussed in: http://www.flashrom.org/pipermail/flashrom/2010-February/thread.html#2364 the old commit (r914) log notes: "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" there still remain a few cases where chipdrivers.h is needed: dediprog.c (spi_read_chunked and spi_write_chunked) it87spi.c (due to spi_write_enable and spi_read_status_register) wbsio_spi.c (spi_programmer registration only) besides that, there are also non-spi files that do not need it. also, add flash.h to chipdrivers.h because it uses some types of it and remove flashchips.h from print.c Corresponding to flashrom svn r1414. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
* Kill central list of SPI programmersMichael Karcher2011-05-111-3/+12
| | | | | | | | | | | | | | | | | | Remove the array spi_programmer, replace it by dynamic registration instead. Also initially start with no busses supported, and switch to the default non-SPI only for the internal programmer. Also this patch changes the initialization for the buses_supported variable from "everything-except-SPI" to "nothing". All programmers have to set the bus type on their own, and this enables register_spi_programmer to just add the SPI both for on-board SPI interfaces (where the internal programmer already detected the other bus types), as well as for external programmers (where we have the default "none"). Corresponding to flashrom svn r1299. Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Factor out SPI write/read chunking wrappersMichael Karcher2011-05-111-11/+0
| | | | | | | Corresponding to flashrom svn r1298. Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Convince compilers to put constant data into the .rodata sectionMathias Krause2011-01-171-1/+1
| | | | | | | | | | | | | | | | This patch reduces the stack usage by declaring 'const' stack variables as 'static const' so they end up in the .rodata section instead of being copied from there to the stack for every invocation of the corresponding function. As a plus we end up in having a smaller binary as the "copy from .rodata to stack" code isn't emitted by the compiler any more (roughly -100 bytes). Corresponding to flashrom svn r1252. Signed-off-by: Mathias Krause <mathias.krause@secunet.com> Acked-by: Stefan Reinauer <stepan@coreboot.org>
* Detect embedded EC (IMC) in AMD's SBsCarl-Daniel Hailfinger2010-09-151-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | AMD SB700 and later have an integrated microcontroller (IMC) which runs from shared flash. The IMC will happily issue reads while we write, issue writes while we read, and generally cause lots of havoc due to the concurrent accesses it performs while flashrom is running. A failing or corrupted read can be detected since r1145, and the worst case is that the read aborts and the user has to retry. A failing write is much more serious. It can be detected since r1145, but if the SPI interface locks up, we can't continue writing nor can we read the current chip contents. If the IMC is inactive, there is no reason to worry. If the IMC is active, flashrom will refuse to erase/write the chip with this patch. The correct fix would be to stop the IMC during flashing, but apparently the relevant registers are undocumented, so we take the safe route for now until someone from AMD can give us more info. Corresponding to flashrom svn r1173. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Tested-by: Matthias Kretz <kretz@kde.org> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Add paranoid checks to sb600spi driverCarl-Daniel Hailfinger2010-08-181-7/+74
| | | | | | | | | | | | | | | | | | | | | Add paranoid checks for correct values in essential registers in the SB600/SB700/... SPI driver. If something else changes the values we wrote, we will see severe read/write corruption. sb600spi will now abort the access and return an error if it detects this sort of corruption. Note: This corruption can be caused by a few different events: - IPMI/BMC/IMC accesses flash - Other software accesses flash The nature of flash access (read/write/ID/...) is irrelevant. Each such access will cause corruption for all other accesses happening at the same time. Thanks to Matthias Kretz for testing this patch. Corresponding to flashrom svn r1145. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Matthias Kretz <kretz@kde.org>
* 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>
* Move SB600 SPI initialization to sb600spi.cMichael Karcher2010-07-221-1/+83
| | | | | | | Corresponding to flashrom svn r1099. Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* 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-17/+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>
* Remove unneeded #include statements completelyCarl-Daniel Hailfinger2010-05-301-1/+0
| | | | | | | | | | | | | | | Unistd.h was only used to get a definition of NULL in all files. Add our own NULL #define and remove unistd.h from flash.h stdio.h has no place in flash.h, it should be included only in files which really need it. Add #include statements in individual .c files where needed. Replace a few printf with msg_* to eliminate the need for stdio.h. Corresponding to flashrom svn r1021. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Handle the following architectures in generic flashrom codeCarl-Daniel Hailfinger2010-05-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - x86/x86_64 (little endian) - PowerPC (big endian) - MIPS (big+little endian) No changes to programmer specific code. This means any drivers with MMIO access will _not_ suddenly start working on big endian systems, but with this patch everything is in place to fix them. Compilation should work on all architectures listed above for all drivers except nic3com and nicrealtek which require PCI Port IO which is x86-only for now. To compile without nic3com and nicrealtek, run make distclean make CONFIG_NIC3COM=no CONFIG_NICREALTEK=no Thanks to Misha Manulis for testing early versions of this patch on PowerPC (big endian) with the satasii programmer. Thanks to Segher Boessenkool for design review and for helping out with compiler tricks and pointing out that we need eieio on PowerPC. Thanks to Vladimir Serbinenko for compile testing on MIPS (little endian) and PowerPC (big endian) and for runtime testing on MIPS (little endian). Thanks to David Daney for compile testing on MIPS (big endian). Thanks to Uwe Hermann for compile and runtime testing on x86_64. DO NOT RUN flashrom ON NON-X86 AFTER APPLYING THIS PATCH! This patch only provides the infrastructure, but does not convert any drivers, so flashrom will compile, but it won't do the right thing on non-x86 platforms. Corresponding to flashrom svn r1013. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Misha Manulis <misha@manulis.com> Acked-by: Vladimir 'phcoder/φ-coder' Serbinenko <phcoder@gmail.com> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
* Introduce a generic SPI read function: spi_write_chunked()Carl-Daniel Hailfinger2010-05-211-14/+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 sb600spi.c to the new message infrastructureCarl-Daniel Hailfinger2010-01-101-30/+19
| | | | | | | Corresponding to flashrom svn r857. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Sean Nelson <audiohacked@gmail.com>
* Allow one to disable programmer debug messages at compile timeCarl-Daniel Hailfinger2010-01-071-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Introduce proper error checking for SPI programmingCarl-Daniel Hailfinger2009-10-011-6/+6
| | | | | | | 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>
* Fix all remaining issues reported by LLVM/clang's scan-buildStefan Reinauer2009-09-161-0/+5
| | | | | | | 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>
* Replace remaining explicit erases in SPI programmer drivers with auto-erasesCarl-Daniel Hailfinger2009-08-101-1/+2
| | | | | | | | | | | | | 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>
* Remove unnecessary #include filesCarl-Daniel Hailfinger2009-08-091-1/+0
| | | | | | | | | | Serprog compilation is now controlled by a Makefile variable. Replace munmap with physunmap where appropriate. Corresponding to flashrom svn r671. 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-16/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Use a distinct return code for SPI commands with unsupported/invalid lengthCarl-Daniel Hailfinger2009-07-141-5/+5
| | | | | | | | | | | 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-4/+1
| | | | | | | | | | 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>
* SB600 SPI: Kill unused variableCarl-Daniel Hailfinger2009-06-231-16/+15
| | | | | | | | | Make a few local functions in sb600spi.c static. Corresponding to flashrom svn r623. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Luc Verhaegen <libv@skynet.be>
* Support reads of arbitrary rangeCarl-Daniel Hailfinger2009-06-161-2/+2
| | | | | | | | | | | | 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>
* Flashrom only checks for very few chips if the erase workedCarl-Daniel Hailfinger2009-06-151-1/+4
| | | | | | | | | | | | | | | | | | | And even when it checks if the erase worked, the result of that check is often ignored. Convert all erase functions and actually check return codes almost everywhere. Check inside all erase_* routines if erase worked, not outside. erase_sector_jedec and erase_block_jedec have changed prototypes to enable erase checking. Uwe successfully tested LPC on an CK804 box and SPI on some SB600 box. Corresponding to flashrom svn r595. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Urja Rannikko <urjaman@gmail.com> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Every SPI host controller implemented its own way to read flash chipsCarl-Daniel Hailfinger2009-06-131-8/+2
| | | | | | | | | | | | | | | | | | | | | | 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 bus type annotation to struct flashchipsCarl-Daniel Hailfinger2009-05-311-4/+4
| | | | | | | | | | | | | | | | | | | 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 accessor functions for MMIOCarl-Daniel Hailfinger2009-05-171-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some MMIO accesses used volatile, others didn't (and risked non-execution of side effects) and even with volatile, some accesses looked dubious. Since the MMIO accessor functions and the onboard flash accessor functions are functionally identical (but have different signatures), make the flash accessors wrappers for the MMIO accessors. For some of the conversions, I used Coccinelle. Semantic patch follows: @@ typedef uint8_t; expression a; volatile uint8_t *b; @@ - b[a] + *(b + a) @@ expression a; volatile uint8_t *b; @@ - *(b) |= (a); + *(b) = *(b) | (a); @@ expression a; volatile uint8_t *b; @@ - *(b) = (a); + mmio_writeb(a, b); @@ volatile uint8_t *b; @@ - *(b) + mmio_readb(b) @@ type T; T b; @@ ( mmio_readb | mmio_writeb ) (..., - (T) - (b) + b ) Corresponding to flashrom svn r524. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Uwe tested read, write, erase with this patch on a random board to make sure nothing breaks. Acked-by: Uwe Hermann <uwe@hermann-uwe.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>
* Chips like the SST SST25VF080B can only handle single byte writes outside ↵Carl-Daniel Hailfinger2009-05-091-1/+1
| | | | | | | | | | | | | | | | | | 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-1/+4
| | | | | | | | | | | | | | | 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>
* Fix typoUwe Hermann2009-04-131-1/+1
| | | | | | | | | Add missing copyright year. Corresponding to flashrom svn r428 and coreboot v2 svn r4107. Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
* Copyright update by Jason Wang for freshly written sb600 codeJason Wang2008-11-291-3/+3
| | | | | | | | Corresponding to flashrom svn r354 and coreboot v2 svn r3782. Signed-off-by: Jason Wang <Qingpei.wang@amd.com> Reviewed-by: Joe, Bao <Zheng.Bao@amd.com> Acked-by: Stefan Reinauer <stepan@coresystems.de>
* Add support for the AMD/ATI SB600 southbridge SPI functionalityJason Wang2008-11-281-0/+175
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 23:46:02 +0000