GitLab

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>

AT25DF021
AT25DF041A
AT25DF081
AT25DF161
AT25DF321A
AT25DF641
AT25F512B
AT25FS010
AT25FS040
AT26DF041
AT26DF081A
AT26DF161
AT26DF161A
AT26DF321
AT26F004

I double-checked the data sheets and am confident this will work.

Corresponding to flashrom svn r344 and coreboot v2 svn r3756.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

Tested fully on a ThinCan DBE61A

Corresponding to flashrom svn r343 and coreboot v2 svn r3755.
Signed-off-by: Mart Raudsepp <mart.raudsepp@artecdesign.ee>
Acked-by: Mart Raudsepp <mart.raudsepp@artecdesign.ee>

The AT45 series SPI chips are DataFlash EEPROMs which means they have
odd (non-power-of-two) sector sizes, but some of the DataFlash chips can
be configured or ordered with power-of-two sector sizes.

Add probe support for the following Atmel SPI chips:
AT25DF021
AT25DF041A
AT25DF081
AT25DF161
AT25DF321A
AT25DF641
AT25F512B
AT25FS010
AT25FS040
AT26DF041
AT26DF081A
AT26DF161
AT26DF161A
AT26DF321
AT26F004
AT45CS1282
AT45DB011D
AT45DB021D
AT45DB041D
AT45DB081D
AT45DB161D
AT45DB321C
AT45DB321D
AT45DB642D

Add an explanation why the following chips can't be probed:
AT45BR3214B
AT45D011
AT45D021A
AT45D041A
AT45D081A
AT45D161
AT45DB011
AT45DB011B
AT45DB021A
AT45DB021B
AT45DB041A
AT45DB081A
AT45DB161
AT45DB161B
AT45DB321
AT45DB321B
AT45DB642

Add the ID, but no probing function for this chip:
AT25F512A

Corresponding to flashrom svn r342 and coreboot v2 svn r3754.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andriy Gapon <avg@icyb.net.ua>
Acked-by: Myles Watson <mylesgw@gmail.com>

Per report from Mario Rogen. Thanks!

Corresponding to flashrom svn r341 and coreboot v2 svn r3736.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

This has been confirmed by Stéphan Guilloux.

Corresponding to flashrom svn r340 and coreboot v2 svn r3731.
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>

Replace age-old TODO comments with real explanations.

Fixed chips:
Fujitsu MBM29F400TC (ID definition)
Macronix MX29F002T (chip name)

New chips:
Fujitsu MBM29F004BC
Fujitsu MBM29F004TC
Fujitsu MBM29F400BC
Macronix MX25L512
Macronix MX25L1005
Macronix MX25L2005
Macronix MX25L6405
Macronix MX29F002B

Straight from the data sheets, compile tested only.

Corresponding to flashrom svn r339 and coreboot v2 svn r3730.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

This helps a lot if we have to track down configuration weirdnesses.

Corresponding to flashrom svn r338 and coreboot v2 svn r3723.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

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.

Corresponding to flashrom svn r337 and coreboot v2 svn r3722.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

This is slightly slower (ha, ha), but works on boards with a locked
opmenu. Tested on ICH7 and works.

Corresponding to flashrom svn r336 and coreboot v2 svn r3721.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Identification only, erase/write are not implemented.

Corresponding to flashrom svn r335 and coreboot v2 svn r3717.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

tested and
Acked-by: Elia Yehuda <z4ziggy@gmail.com>

 - SST SST39SF010A
 - Winbond W29C011

Tested by me on actual hardware, all operations.

Corresponding to flashrom svn r334 and coreboot v2 svn r3708.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Using block erase d8 as discussed with Peter Stuge

Corresponding to flashrom svn r333 and coreboot v2 svn r3707.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

Corresponding to flashrom svn r332 and coreboot v2 svn r3706.
Signed-off-by: Ed Swierk <eswierk@aristanetworks.com>
Acked-by: Ed Swierk <eswierk@aristanetworks.com>

Tested by Martin Stecklum <stecky@gmx.net> (both write and erase).
The tests were done on an MSI MS-7065 board, so that's supported now too.

Corresponding to flashrom svn r331 and coreboot v2 svn r3697.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Untested, but should work just as well as the other *PIIX* southbridges
according to the datasheets.

Corresponding to flashrom svn r330 and coreboot v2 svn r3696.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Tested on PIIX3 hardware.

Corresponding to flashrom svn r329 and coreboot v2 svn r3694.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Corey Osgood <corey.osgood@gmail.com>

Corresponding to flashrom svn r328 and coreboot v2 svn r3693.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

This has been tested on hardware by me.

Corresponding to flashrom svn r327 and coreboot v2 svn r3682.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Corresponding to flashrom svn r326 and coreboot v2 svn r3669.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Based on the 5595 datasheet and uniflash 1.40 sources, only looking for info
about SiS620.

Corresponding to flashrom svn r325 and coreboot v2 svn r3668.
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>

It is not possible to write enable that area once the register is set so
print a warning.

Corresponding to flashrom svn r324 and coreboot v2 svn r3659.
Signed-off-by: Marc Jones <marcj.jones@amd.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

The ICH9 and ICH10 data sheets are identical regarding FWH/SPI flash
interfaces, so this just adds the required PCI IDs.

Corresponding to flashrom svn r323 and coreboot v2 svn r3648.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Peter Stuge <peter@stuge.se>

Corresponding to flashrom svn r322 and coreboot v2 svn r3647.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Fully tested on AM29F002NBT.

Probing, reading, and erasing use the Jedec-routines, whereas writing
resort to the recent write_en29f002a(), since also these chips use a
byte wise algorithm.

Corresponding to flashrom svn r321 and coreboot v2 svn r3639.
Signed-off-by: Mats Erik Andersson <mats.andersson@gisladisker.se>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

It replaces the write function to one based on write_byte_program_jedec()
instead of write_page_write_jedec(), as this part does not support page
programming.
I have verified the NT variant to fully work now, and adjusted the test
status accordingly. The N variant *should* also work with this patch, but
remains untested.

Corresponding to flashrom svn r320 and coreboot v2 svn r3619.
Signed-off-by: Tim ter Laak <timl@scintilla.utwente.nl>
Acked-by: Peter Stuge <peter@stuge.se>

Per report from Daniel Lindenaar. Thanks!

Corresponding to flashrom svn r319 and coreboot v2 svn r3618.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Corresponding to flashrom svn r318 and coreboot v2 svn r3616.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

All operations tested by me on hardware.

Corresponding to flashrom svn r317 and coreboot v2 svn r3615.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Fully tested for Probe/Read/Erase/Write on EN29F002NT.
Jedec subroutines 'probe_jedec()' and 'erase_chip_jedec()'
are still in use, but a tailored 'write_en29f002a()' is
needed due to a byte wise writing mechanism for this chip.

Corresponding to flashrom svn r316 and coreboot v2 svn r3602.
Signed-off-by: Mats Erik Andersson <mats.andersson@gisladisker.se>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Per report from Kevin O'Connor. Thanks Kevin!

Corresponding to flashrom svn r315 and coreboot v2 svn r3570.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Corresponding to flashrom svn r314 and coreboot v2 svn r3569.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

This removes the false positive matches we've been seeing, and also removes
the true positive match in case there is more than one flash chip and the 2nd
or 3rd are unknown - but I think that case is uncommon enough to warrant the
improvement in the common case. Use flashrom -frc forced read if you have the
uncommon case, and/or please add the flash chip to the flashchips array.

Corresponding to flashrom svn r313 and coreboot v2 svn r3562.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

Per test report from Bari Ari. Thanks!

Corresponding to flashrom svn r312 and coreboot v2 svn r3557.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Per test report from Ward.

Corresponding to flashrom svn r311 and coreboot v2 svn r3541.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Corresponding to flashrom svn r310 and coreboot v2 svn r3532.
Signed-off-by: Ed Swierk <eswierk@arastra.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

The KT4V is autodetected and supports the KT3 Ultra 2 with "-m msi:kt4v"
(but is not autodetected, yet).

Corresponding to flashrom svn r309 and coreboot v2 svn r3528.
Signed-off-by: Sean Nelson <snelson@nmt.edu>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Don't calculate "flash_baseaddr" until the final value of "size"
is known, otherwise we end up trying to map a page right after
the end of memory.

Fixes #112.

Corresponding to flashrom svn r308 and coreboot v2 svn r3502.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>

Per test report from Marcel Konrad. Thanks!

Corresponding to flashrom svn r307 and coreboot v2 svn r3485.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>

Corresponding to flashrom svn r306 and coreboot v2 svn r3464.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>