I broke unlocking them correctly in r1635 while refactoring (NB: the
commit log including the overly selfconfident statement about the
"bug in spi_disable_blockprotect_at25df()").
Affected chips have per sector protection bits and the write protection bits
in the status register do indicate if none, some or all sectors are protected.
It is possible to globally (un)lock all sectors at once but in a way that was
not anticipated when refactoring the spi25 unlocking functions into
spi_disable_blockprotect_generic(). To globally unprotect not only the
protection bits (2 and 3) have 0 to be written to them but also bits 4 and 5
which normally would not be touched by spi_disable_blockprotect_generic().
Some of the chips also support a permanent lockdown with fuses which we
do not handle yet.
To fix this without copying the whole method I introduce another mask
parameter to spi_disable_blockprotect_generic() namely unprotect_mask.
See verbose comments inline for details.
Also, prettyprint the status register after trying to disable the block
protection fails.
Corresponding to flashrom svn r1679.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Tested-by: Chi Zhang <zhangchi866@gmail.com>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
- Use ".V" (and "_V" in macros) for 3.3V Winbond 25Q chips.
Rename the existing chips and add a .voltage entry where it was missing.
- Use ".W" (and "_W" in macros) for 1.8V Winbond 25Q chips.
- Add W25Q20.W, W25Q40.W, W25Q80.W, W25Q16.W, W25Q32.W, W25Q64.W.
Based on chromiumos' 469707f0d9b7d81b6c6bb2cace13f09db70f4382
http://git.chromium.org/gitweb/?p=chromiumos/third_party/flashrom.git;a=commitdiff;h=469707f0d9b7d81b6c6bb2cace13f09db70f4382
Corresponding to flashrom svn r1677.
Signed-off-by: Yung-Chieh Lo <yjlou%chromium.org@gtempaccount.com>
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This patch adds support for
- Pm25LD256C
- Pm25LD512(C)
- Pm25LD010(C)
- Pm25LD020(C)
- Pm25LD040(C)
These seem to be the successors of the Pm25LV series.
The main difference seems to be the dual I/O and additional erase opcodes.
Some support an additional, complex locking register (maybe all of the
above, but available datahsheets do not indicate it for all).
The Pm25LD512C was tested by Chi Zhang:
http://paste.flashrom.org/view.php?id=1579
Corresponding to flashrom svn r1671.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
- Add missing bits and resort chips
- Refine Pm25LV512(A) and Pm25LV010
Due to manufacturer ID continuation this one needs a new probing
function: probe_spi_res3() which should be refactored in the future.
The datasheet describes a very weird order of ID bytes:
Vendor byte, model byte, vendor continuation byte. Let's pretend we did
not read that or the datasheet is bogus (although the datasheet of the
successor series describes the same but luckily additionally to RDID).
- Add Pm25LV010A
This was tested by Chi Zhang:
http://paste.flashrom.org/view.php?id=1573
Corresponding to flashrom svn r1670.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Similarly to the patch in r1647 this one updates the chips identified as above
with references to and data about their respective twins. Unlike previously this
one deals with the more evil details.
Helge Wagner from GE discovered some problems with chips sharing IDs
and proposed a patch to tackle (some of) them, see:
http://patchwork.coreboot.org/patch/3709/
That patch was bitrotting in our mailboxes for a long time and it is still not
ready for merge, but we increasingly get reports about problems (e.g.
http://paste.flashrom.org/view.php?id=1525) regarding these chips and
hence must act to ensure users' safety.
This patch splits the chip definitions of evil twins into separate ones which
correctly declare the respective attributes (the main problems are the erase
block sizes for the 0x20 opcode and hence my changes combine different
chips with partly different attributes apart from their names as long as the
erasers layout it the same). This forces the user to select the (right) chip
definition with the -c/--chip parameter and hence will break a number of
previously perfectly working environments.
0x2015 is used by and split to
- MX25L1605 (64kB sectors in 0x20 erases)
- MX25L1605A/MX25L1606E (4kB in 0x20 erases and an additional 0x52 opcode with 64kB blocks)
- MX25L1605D/MX25L1608D (4k sectors in 0x20 erases)
0x2016 is used by and split to
- MX25L3205/MX25L3205A (64kB 0x20)
- MX25L3205D/MX25L3208D (4kB 0x20)
- MX25L3206E (4k 0x20, 64k 0x52)
0x2017 is used by and split to
- MX25L6405/MX25L6405D (64k 0x20)
- MX25L6406E/MX25L6436E (4k 0x20)
- MX25L6445E (4k 0x20, 64k 0x52)
Bonus: add some minor details to MX25L1635D, MX25L1635E, MX25L3235D,
MX25L12805D.
Tested with MX25L3206E, MX25L64036E.
Corresponding to flashrom svn r1657.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This older (ST-branded) revision of M25P20 chip does not support RDID and
hence was not detected correctly. This patch adds a workaround similar
to M25P40-old.
Corresponding to flashrom svn r1652.
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Update MX25L512 with references to and data about
MX25L512E, MX25V512, MX25V512C.
Update MX25L1005 with references to and data about
MX25L1005C, MX25L1006E.
Update MX25L2005 with references to and data about
MX25L2005C.
Update MX25L4005 with references to and data about
MX25L4005A, MX25L4005C.
Update MX25L8005 with references to and data about
MX25V8005.
Bonus: add chip IDs of MX25U1635E, MX25U3235E/F, MX25U6435E/F.
Corresponding to flashrom svn r1647.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This adds support for the following chips:
- AT25F512, AT25F512A, AT25F512B
- AT25F1024, AT25F1024A
- AT25F2048
- AT25F4096
Besides the definitions of the the chips in flashchips.c this includes
- a dedicated probing method (probe_spi_at25f)
- pretty printing methods (spi_prettyprint_status_register_at25f*), and
- unlocking methods (spi_disable_blockprotect_at25f*)
Corresponding to flashrom svn r1637.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This includes:
Bottom boot block:
* 16Mb/2MB:
QB25F160S33B8, QB25F016S33B8, QH25F160S33B8, QH25F016S33B8
* 32Mb/4MB:
QB25F320S33B8, QH25F320S33B8
* 64Mb/8MB:
QB25F640S33B8, QH25F640S33B8
Top boot block:
* 16Mb/2MB:
QB25F160S33T8, QB25F016S33T8, QH25F160S33T8, QH25F016S33T8
* 32Mb/4MB:
QB25F320S33T8, QH25F320S33T8
* 64Mb/8MB:
QB25F640S33T8, QH25F640S33T8
At least some seem to be marketed by other vendors (too?) but also with
Intel's vendor ID.
Besides a 0xC7 chip erase and a 0xD8 uniform 64kB block erase they
support also erasing the top/bottom 8 8kB blocks with opcode 0x40.
But since this command fails for all addresses outside those ranges,
it is not easily implemented with flashrom's current code base and
hence left out.
Corresponding to flashrom svn r1636.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
W39F010 is a 128kB parallel 5V flash chip, 16k bootblocks.
W39L010 is a 128kB parallel 3.3V flash chip, 8k bootblocks.
W39L020 is a 256kB parallel 3.3V flash chip, 64k/16k bootblocks.
The W39F010 code was tested with a satasii programmer. The first write
attempt after an erase returned with verify failure, but the second
write attempt was succesful:
http://paste.flashrom.org/view.php?id=1418
Corresponding to flashrom svn r1620.
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
The 32Mb version has 1.8V and 3.0V versions, the smaller one 1.8V only
(or Numonyx/Micron forgot to publish it). Another difference is that the
16Mb chip has 32 kB subsectors (erase opcode 0x52). As long as there
are no funky configurations like for the 128Mb chips, we got the smaller
parts covered with this change.
Corresponding to flashrom svn r1615.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This patch differentiates between the N25Q064 1.8V version and 3.0V
version which have different JEDEC IDs.
It extends the chip name to include more characters of the part
number. The first two of those characters indicate the process
technology (65nm) and feature set (hold pin etc.), neither of which
matter for flashrom at the moment. The third and fourth characters
specify voltage and block/sector size and uniformity, which are
important and hence included.
To abstract the irrelevant portions of the part number leading up to
the characters we care about, dots are used. This helps prevent
unwanted changes in chip name that can break fragile scripts and
confuse people. More about this schema here:
http://www.flashrom.org/pipermail/flashrom/2012-July/009595.html
Corresponding to flashrom svn r1612.
Signed-off-by: David Hendricks <dhendrix@google.com>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This is the low power version (vendor,device = 0xc8,0x6016) of
GD25Q32 (0xc8,0x4016) which matches that of W25Q32 (0xef,0x4016) and
W25Q32DW (0xef,0x6016). All their datasheets look pretty much the
same with respect to commands, erase blocks, etc.
Stolen from chromiumos:
http://git.chromium.org/gitweb/?p=chromiumos/third_party/flashrom.git;a=commitdiff;h=9a0051f0ba0b67af6f08e052c31cba3e9dbbbdbf
Corresponding to flashrom svn r1598.
Signed-off-by: Bryan Freed <bfreed@chromium.org>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Its ID was spotted in an ICH descriptor region update by Jetway:
http://paste.flashrom.org/view.php?id=1217 and is used on ASUS P8B75-V
boards according to some forum posts (2 chips per board actually).
No datasheet was found, so most values are just guessed from the EN25F32.
Corresponding to flashrom svn r1594.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Also, alter the page size of the other family members to indicate that it is
unused. Maybe this accelerates the deletion of this field... haha.
Corresponding to flashrom svn r1572.
Signed-off-by: Andrew Morgan <ziltro@ziltro.com>
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Its ID was spotted in an descriptor region update by Jetway:
http://paste.flashrom.org/view.php?id=1217
Corresponding to flashrom svn r1535.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Chip features an optional permanent boot block write protection.
Corresponding to flashrom svn r1522.
Signed-off-by: David Borg <borg.db@gmail.com>
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
This chip needs special command sequences in 8 bit mode. Also, 8 bit
programming needs actually 16bit double byte program.
The chip is found on the Bifferos Bifferboard, for example.
Corresponding to flashrom svn r1521.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
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>
An opaque programmer does not allow direct flash access and only offers
abstract probe/read/erase/write methods.
Due to that, opaque programmers need their own infrastructure and
registration framework.
Corresponding to flashrom svn r1459.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Write and erase are NOT yet supported!
Probe and read are tested by Andrew Morgan and Uwe Hermann on Intel NICs.
Corresponding to flashrom svn r1439.
Signed-off-by: Andrew Morgan <ziltro@ziltro.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
The chip code is untested, only one erase function out of two is currently
implemented, and unlocking/printlocking is not yet supported.
Thanks Mattias Mattsson <vitplister@gmail.com> for the initial patch!
Corresponding to flashrom svn r1434.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
This patch combines three previously posted patches in a revised form.
one is even stolen from Stefan Reinauer (remove umlauts from man page).
Corresponding to flashrom svn r1317.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Tests were performed with write and verify operations to 4 different
M25PX16 chips with a Dediprog SF100.
Corresponding to flashrom svn r1270.
Signed-off-by: Carl Worth <carl.d.worth@intel.com>
Acked-by: Idwer Vollering <vidwer@gmail.com>
Add support for AMD Am29LV001BB, Am29LV001BT, Am29LV002BB, Am29LV002BT,
Am29LV004BB, Am29LV004BT, Am29LV008BB, Am29LV008BT.
Thanks to Mark Pustjens for testing the Am29LV001BB.
Corresponding to flashrom svn r1260.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested S25FL064A using a Bus Pirate.
Corresponding to flashrom svn r1237.
Signed-off-by: Rudy Host <segfault@committeeofdoom.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Rename constants W_nnnn -> WINBOND_Wnnnn W_25nnn -> WINBOND_NEX_W25nnn.
Kill incorrect ASD chip and vendor id.
Group Winbond SPI and parallel chips separately (they have different
vendor IDs).
Change constant names to the "canonical" chip name for the following
ids:
W_29C020C (0x45)
-> WINBOND_W29C020 (Same as W29C020C, W29C022 and ASD AE29F2008)
W_29C040P (0x46)
-> WINBOND_W29C040 ("P" is for package type [32-pin PLCC], irrelevant)
W_29C011 + W_29EE011 (0xC1)
-> WINBOND_W29C010 (Same as W29C010M, W29C011A, W29EE011, W29EE012,
and ASD AE29F1008)
List all chip variants in the .name strings in flashchips.c
Have two identical entries for Winbond
W29C010(M)/W29C011A/W29EE011/W29EE012 but with different probe functions
in flashchips.c as sometimes (for newer revisions of these chips?) the
standard jedec probe seems to work. E.g. see test report here:
http://patchwork.coreboot.org/patch/1476/
Also add ids for the following Winbond chips:
W25Q40
W25Q128
W19B160BB
W19B160BT
W19B320SB/W19L320SB
W19B320ST/W19L320ST
W19B322MB
W19B322MT
W19B323MB
W19B323MT
W19B324MB
W19B324MT
W29C512A/W29EE512
W39L010
W39L040A
W39L512
W49F002/W49F002B
Corresponding to flashrom svn r1168.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Probe, read, erase and write have been tested and all are functional.
Corresponding to flashrom svn r1165.
Signed-off-by: Jason Shriver <j.shriver@f5.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
Add support for Atmel AT25DF081A and AT25DQ161.
Some chips require EWSR before WRSR, others require WREN before WRSR,
and some support both variants. Add feature_bits to select the correct
SPI command, and default to EWSR.
Corresponding to flashrom svn r1115.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Steven Rosario
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
http://www.amictechnology.com/pdf/A25L20P.pdf covers:
AMIC A25L05PT
AMIC A25L05PU
AMIC A25L10PT
AMIC A25L10PU
AMIC A25L20PT
AMIC A25L20PU
http://www.amictechnology.com/pdf/A25L16P.pdf covers:
AMIC A25L16PT
AMIC A25L16PU
Clarify the situation surrounding the A25L40PT and A25L40PU chips which
share the same RDID values, despite the fact that their erase block
layouts are different. Rudolf Marek tested and confirmed the distinct
erase block layouts of these chips.
Add a pretty-printer for the AMIC SPI chip status register
Add a generic AMIC chip type.
Corresponding to flashrom svn r1096.
Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
This is a 1 MB SPI chip that seems to be straightforwardly related
to the AMIC A25L40PU, which has half the capacity but is otherwise
identical.
Datasheet is at http://www.amictechnology.com/pdf/A25L80P.pdf
flashrom -VE, -Vr, and -Vw has been tested using the AMD SB7x0
interface. Everything works fine... at least, I used it to upgrade my
BIOS and I've been able to reboot.
Corresponding to flashrom svn r1075.
Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
