aboutsummaryrefslogtreecommitdiffstats
path: root/sfdp.c
Commit message (Collapse)AuthorAgeFilesLines
* Make struct flashchip a field in struct flashctx instead of a complete copyCarl-Daniel Hailfinger2012-08-251-16/+16
| | | | | | | | | | | | All the driver conversion work and cleanup has been done by Stefan. flashrom.c and cli_classic.c are a joint work of Stefan and Carl-Daniel. Corresponding to flashrom svn r1579. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Tag all EWSR chips correctlySteven Zakulec2012-05-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All SPI chips without a WRSR feature bit set were evaluated except the Sanyo LF25FW203A for which no datasheet is available. The following list includes all SPI-capable chips that still have no WRSR feature bit set: - AT26DF041 - AT45CS1282 - AT45DB011D - AT45DB021D - AT45DB041D - AT45DB081D - AT45DB161D - AT45DB321C - AT45DB321D - AT45DB642D All of them have no write function set and can be therefore ignored for now. Apart from those the generic chips are also not tagged. The opaque flash interface should not be affected. The SFDP dummy chip is changed to explicitly set EWSR if it can't deduce it dynamically. The vendor detecting generic chips can't write anyway. Corresponding to flashrom svn r1527. Signed-off-by: Steven Zakulec <spzakulec@gmail.com> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
* SFDP: Fetch parameter table in a more portable wayCarl-Daniel Hailfinger2012-02-241-7/+16
| | | | | | | | | | | | | SFDP parameter table reads expect a dummy byte between written data (opcode+address) and read data on the SPI bus. Read that dummy byte instead of writing it to be compatible with all programmer drivers. Reduce SFDP parameter table read chunk size from 8 to 2 to handle programmers with small readcount limits. Corresponding to flashrom svn r1506. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
* Fix SFDP probingStefan Tauner2012-02-221-26/+39
| | | | | | | | | | | | | | | | | | | | | | Sfdp_add_uniform_eraser checks for existing erasers. Due to a bug it looked for eraser slots that have no erase functions set instead of those that have one set. Postpone adding an erase function for the special 4k block erase opcode until we know the flash chip size and add an additional check to sfdp_add_uniform_eraser. Fix the output of the parameter table contents. This patch fixes the index used to retrieve the eraser types, which was off one double word. Refine some messages and add a few further debugging prints. Corresponding to flashrom svn r1505. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
* Add support for SFDP (JESD216)Stefan Tauner2012-02-171-0/+370
Similar to modules using the opaque programmer framework (e.g. ICH Hardware Sequencing) this uses a template struct flashchip element in flashchips.c with a special probe function that fills the obtained values into that struct. This allows yet unknown SPI chips to be supported (read, erase, write) almost as if it was already added to flashchips.c. Documentation used: http://www.jedec.org/standards-documents/docs/jesd216 (2011-04) W25Q32BV data sheet Revision F (2011-04-01) EN25QH16 data sheet Revision F (2011-06-01) MX25L6436E data sheet Revision 1.8 (2011-12-26) Tested-by: David Hendricks <dhendrix@google.com> on W25Q64CV + dediprog Tested-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> on a 2010 MX25L6436E with preliminary (i.e. incorrect) SFDP implementation + serprog Thanks also to Michael Karcher for his comments and preliminary review! Corresponding to flashrom svn r1500. Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>