GitLab

The Direct I/O library for Mac OS X is now called DirectHW to make sure
people can find it via an internet search.

DirectIO was a generic name for a concept and thus not a good
distinguisher for a library.

Corresponding to flashrom svn r1198.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Idwer Vollering <vidwer@gmail.com>

Update programmer parameter documentation.

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

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

Add a clarifying comment about why low memory is never unmapped.

Corresponding to flashrom svn r1195.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Rudolf Marek <r.marek@assembler.cz>

Use AAI write for SST SST25VF032B.
Speedup from 228 to 113 seconds.

Use page (256 byte) write for SST SST25VF064C.
Speedup from 3091 to 123 seconds.

Corresponding to flashrom svn r1194.
Signed-off-by: Helge Wagner <helge.wagner@ge.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Corresponding to flashrom svn r1193.
Signed-off-by: Helge Wagner <helge.wagner@ge.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

This also adds (and marks as tested) a chipset-enable for the SiS 741.

All operations successfully tested on hardware.

lspci/superiotool:
  http://www.flashrom.org/pipermail/flashrom/2010-September/004710.html



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

Match on ethernet and north bridge.

This is tested on an OptiPlex GX1 400L+ but will probably work for
the whole GX1 series as they all share the same vendor BIOS.

lspci/flashrom output
http://www.flashrom.org/pipermail/flashrom/2010-July/004042.html

lspci output (OptiPlex GX1 unknown model)
http://www.coreboot.org/pipermail/coreboot/2010-May/058040.html

superiotool output (OptiPlex GX1 266L+)
http://www.flashrom.org/pipermail/flashrom/2009-July/000207.html

lspci/dmidecode output (OptiPlex GX1 266L+)
http://www.coreboot.org/pipermail/coreboot/2009-July/050958.html



Corresponding to flashrom svn r1191.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Not sure if this is the final/correct fix, but for now it definately
fixes writes on FT2232H hardware. I have tested this on both, the
DLP Design DLP-USB1232H, and the openbiosprog-spi hardware.

Thanks to Joshua Roys <roysjosh@gmail.com> for the hint on IRC.

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

Strip package prefix in constant names (everything before "28F").

Prefix every constant name with INTEL_

Sort intel chip constants by ID.

Rename the following constants to their "canonical" name:

P28F400BT (0x70  -> INTEL_28F400T (28F400BV/BX/CE/CV-T)
P28F400BB (0x71) -> INTEL_28F400B (28F400BV/BX/CE/CV-B)
P28F004BT (0x78) -> INTEL_28F004T (28F004B5/BE/BV/BX-T)
P28F004BB (0x79) -> INTEL_28F004B (28F004B5/BE/BV/BX-B)
E_28F008S5 (0xA6) -> INTEL_28F008S3 (28F008S3/S5/SC)
E_28F004S5 (0xA7) -> INTEL_28F004S3 (28F008S3/S5/SC)
P28F001BXT (0x94) -> INTEL_28F001T (28F001BN/BX-T)
P28F001BXB (0x95) -> INTEL_28F001B (28F001BN/BX-B)
E_28F016S5 (0xAA) -> INTEL_28F016S3 (28F016S3/S5/SC)

Add chip IDs for the following chips:

28F320J5
28F640J5
28F320J3
28F640J3
28F128J3
28F256J3
28F200BL/BV/BX/CV-T
28F200BL/BV/BX/CV-B
28F002BL/BV/BX-B
28F008BE/BV-T
28F008BE/BV-B
28F800B5/BV/CE/CV-T
28F800B5/BV/CE/CV-B
28F016SA/SV
28F008SA
28F008S3/S5/SC
28F008S3/S5/SC
28F016XS
28F010
28F512
28F256A
28F020
28F016B3-T
28F016B3-B
28F008B3-T
28F008B3-B
28F004B3-T
28F004B3-B

Corresponding to flashrom svn r1189.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Allow specification of an alternate base address with
flashrom -p rayer_spi:iobase=0x278
Any base address is allowed as long as it is nonzero, below 65536 and a
multiple of four.

Read speed is now on par with original spipgm.exe.

Corresponding to flashrom svn r1188.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Martin Rehak <rayer@seznam.cz>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>

Reported by Konstantin <hc@comp.susu.ac.ru>
lspci (superiotool missing, doesn't matter for this patch)
 http://www.coreboot.org/pipermail/flashrom/2010-September/004609.html


DMI is needed, as there are no usefull PCI IDs.

(no test of that board yet, thus marked as untested)

Corresponding to flashrom svn r1187.
Signed-off-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Update README to list all the needed rpm files for DOS cross-compilation
and update the download location of cwsdpmi.

Corresponding to flashrom svn r1186.
Signed-off-by: Idwer Vollering <vidwer+flashrom@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Corresponding to flashrom svn r1185.
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: Iain Paton <selsinork@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

This doesn't include changes to the frontend which must be
done separately, so this won't work out of the box.
This code was tested on hardware.

Corresponding to flashrom svn r1184.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Corresponding to flashrom svn r1183.
Signed-off-by: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Half a dozen hardcoded strcmp() don't make sense if we need a
chassis-type list anyway once we merge the internal DMI decoder. Provide
and array of the most interesting chassis types and annotate them with
laptop/non-laptop status. Match the dmidecode chassis type against the
strings in the array.

Corresponding to flashrom svn r1182.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Sean Nelson <audiohacked@gmail.com>

Corresponding to flashrom svn r1181.

Change the physmap* behaviour to use (void*)-1 as error code instead
of NULL. That way, 1:1 mapped memory can be supported properly
because (void*)0 is not a magic pointer anymore.
(void*)-1 on the other hand is a rather unlikely memory offset, so that
should be safe.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
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>

The variable 'ret' is unused when compiling on big-endian architecture.

This produces an "unused variable" message, which might be treated as error
if -Werror was passed to compiler.

With this patch I was able to compile flashrom cleanly on ppc and ppc64:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2472482
http://koji.fedoraproject.org/koji/taskinfo?taskID=2472484



Corresponding to flashrom svn r1180.
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Cross-checked with UniFlash 1.40 source, chip datasheets and
EZoFlash's chip database (http://www.ezoflash.com/chip_database.php).

Datasheets:
http://www.ezoflash.com/datasheets/flash/Alliance/AS29F002.pdf
http://www.alsc.com/pdf/flash.pdf/as29f010.pdf
http://www.alsc.com/pdf/flash.pdf/as29f040.pdf
http://www.alsc.com/pdf/flash.pdf/as29f200.pdf
http://www.ezoflash.com/datasheets/flash/Alliance/AS29LV160.pdf
http://www.ezoflash.com/datasheets/flash/Alliance/AS29LV400.pdf
http://www.ezoflash.com/datasheets/flash/Alliance/AS29LV800.pdf



Corresponding to flashrom svn r1179.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Thanks to Johannes Sjölund for reporting that the Bus Pirate init could
not deal with a Bus Pirate which is already in binary Bitbang mode.

This is caused by a combination of the slowness of the Bus Pirate, the
slowness of USB and a fast serial port flush routine which just flushes
the buffer contents and does not wait until data arrival stops.

Make the Bus Pirate init more robust by running the flush command 10
times with 1.5 ms delay in between.

This code development was sponsored by Mattias Mattsson. Thanks! Tested
a few dozen times, should work reliably.

Corresponding to flashrom svn r1178.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Mattias Mattsson <vitplister@gmail.com>

Match on Memory Controller/LPC Bridge.

lspci/superiotool output:
http://www.coreboot.org/pipermail/flashrom/2010-September/004829.html

Test report:
http://www.coreboot.org/pipermail/flashrom/2010-September/004835.html



Corresponding to flashrom svn r1177.
Tested-by: Andrew Cleveland <evil.saltine@gmail.com>
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Bright BM29F040
Hyundai HY29F040A
Macronix MX29F040

Also add chip IDs for
Bright BM29F400T/B

Datasheets:
http://www.ezoflash.com/datasheets/flash/Winbond/BM29F040.pdf
http://www.ezoflash.com/datasheets/flash/Hyundai/HY29F040A.pdf
http://www.ezoflash.com/datasheets/flash/Macronix/MX29F040.pdf
http://www.ezoflash.com/datasheets/flash/Winbond/BM29F400T_B.pdf

Bright BM29F040 probe/read test report:
http://www.flashrom.org/pipermail/flashrom/2010-September/004805.html



Corresponding to flashrom svn r1176.
Signed-off-by: Joshua Roys <roysjosh@gmail.com>
Acked-by: Mattias Mattsson <vitplister@gmail.com>

AM_* -> AMD_AM*
AT_* -> ATMEL_AT*
EN_* -> EON_EN*
HY_* -> HYUNDAI_HY*
MBM* -> FUJITSU_MBM*
MX_ID -> MACRONIX_ID
MX_* -> MACRONIX_MX*
PMC_* -> PMC_PM*
SST_* -> SST_SST*

It leaves the Intel #defines alone because there is another pending
patch for that:
http://patchwork.coreboot.org/patch/1937/

Some background discussion here:
http://www.flashrom.org/pipermail/flashrom/2010-July/004059.html



Corresponding to flashrom svn r1175.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

No docs available.

Corresponding to flashrom svn r1174.
Signed-off-by: Joshua Roys <roysjosh@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

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>

Some flash chips need time to exit ID mode, and while we take care of
correct timing for the matching probe, subsequent probes may have
totally different timing, and that can lead to garbage responses from
the flash chip during the first accesses after the probe sequence is
done.
Delay 100 ms between the last probe and any subsequent operation.
To ensure maximum correctness, we would have to reset the chip first in
case the last probe function left the chip in an undefined (non-read)
state. That will be possible once struct flashchip has a .reset
function.

This fixes unstable erase/read/write for some flahs chips on nic3com and
possible other use cases as well.

Thanks to Maciej Pijanka for reporting the issue and testing patches.

Corresponding to flashrom svn r1172.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>

SPI bitbanging on devices which speak SPI natively has a dual-use
problem: We need to shut down normal SPI operations to do the bitbanging
ourselves. Once we're done, it makes a lot of sense to reenable "normal"
SPI operations again. Add request_bus/release_bus functions to struct
bitbang_spi_master.
Add a bitbang shutdown function (not used yet).
Change MCP SPI and Intel NIC SPI to use the new request/release bus
infrastructure.
Cosmetic changes to a few error messages (80 column limit).

There are multiple possible strategies for bus request/release:
- Request at the start of a SPI command, release immediately afterwards.
- Request at the start of a SPI multicommand, release once all commands
of the multicommand are done.
- Request on programmer init, release on shutdown.
Each strategy has its own advantages. For now, we will stay with the
first strategy which worked fine so far.

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

ICH SPI has the ability to restrict SPI read/write accesses to a given
address range. The low end of the range is configurable by the BIOS (and
by flashrom if the BIOS didn't lock down the flash interface), the high
end of the range is 0xffffff (2^24-1).
This patch checks for an address range restriction and uses the low end
of the allowed range as base for SPI reads. A similar workaround for
REMS/RES opcodes has been committed in r500.

This fixes read on the Intel D945GCLF mainboard where the stock BIOS
enforces a restricted address range.
Please note that writes need the same fix, but for architectural reasons
that fix will be merged once partial write is available.

Corresponding to flashrom svn r1170.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Tested by David Hendricks on the Intel D945GCLF mainboard, results at
http://paste.flashrom.org/view.php?id=79

Acked-by: David Hendricks <dhendrix@google.com>

Corresponding to flashrom svn r1169.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

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>

The board-enable is the same as for the ASUS A7V8X, i.e., it raises
GP51 on the ITE IT8703F. I verified using a multimeter that this
will raise both, WE# and TBL# on the flash chip.

All operations successfully tested on hardware.

Also renamed board_asus_a7v8x() to it8703f_gpio51_raise().

Corresponding to flashrom svn r1167.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Joshua Roys <roysjosh@gmail.com>

Mark the following boards as tested:

 - Intel Foxhollow (reported by Jason Shriver <J.Shriver@F5.com>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004768.html

 - Intel Greencity (reported by Jason Shriver <J.Shriver@F5.com>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004768.html

 - Tyan S2915-E (Thunder n6650W) (reported by Axel Bergerhoff
   <axelbergerhoff@compuserve.com>)
   http://www.flashrom.org/pipermail/flashrom/2010-August/004560.html

 - ASUS Z8NA-D6C (reported by John Wells <jb@sourceillustrated.com>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004737.html

 - GIGABYTE GA-7DXR (reported by Uwe Hermann <uwe@hermann-uwe.de>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004712.html

 - MSI MS-7211 (PM8M3-V) (reported by Shahar Or <mightyiampresence@gmail.com>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004612.html

 - MSI MS-6787 (P4MAM-V/P4MAM-L) (reported by Swift Geek <swiftgeek@gmail.com>)
   Board-enable now marked as tested.
   http://www.flashrom.org/pipermail/flashrom/2010-September/004687.html

Chips:

 - SST SST25VF016B (reported by Warren Turkal <wt@penguintechs.org>)
   http://www.flashrom.org/pipermail/flashrom/2010-September/004716.html



Corresponding to flashrom svn r1166.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
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>

Reduce clock delay to zero.

Tests show more than 2x speedup.

Corresponding to flashrom svn r1164.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Tested-by: Andrew Morgan <ziltro@ziltro.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Corresponding to flashrom svn r1163.
Signed-off-by: Tim ter Laak <timl@scintilla.utwente.nl>
Acked-by: Michael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Corresponding to flashrom svn r1162.
Signed-off-by: Stephan Guilloux <stephan.guilloux@free.fr>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

I does this by setting bits 3..2 of register 0x24 on the ITE IT8707F,
while keeping bit 3 of register 0x23 set while manipulating the first
register.

AFAIK, there is no public datasheet available for this super i/o chip, but
the above is how the vendor BIOS does it. Also, registers 0x23 and 0x24 seem
to have the same meaning as on the ITE IT8710F.

Matching on NB/SB.

Tested on a P4SC-E with SST 39SF020A flash. Probe, read, erase, write
all work.

lspci/superio output:
http://www.flashrom.org/pipermail/flashrom/2010-July/004090.html

flashrom output:
http://www.flashrom.org/pipermail/flashrom/2010-August/004566.html



Many thanks to Reinder de Haan for help with reverse engineering this!

Corresponding to flashrom svn r1161.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Matching on NB/SB. Probe, read, erase and write all work.

lspci/superiotool output:
http://www.flashrom.org/pipermail/flashrom/2010-August/004461.html

I believe that this board enable also works for MSI BX Master (MS-6163
rev:3) and perhaps also for MSI MS-6163FC (MS-6163 rev:1) but these
boards have not been tested.

Test logs for MS-6163 (rev:2):
http://www.flashrom.org/pipermail/flashrom/2010-September/004704.html



Corresponding to flashrom svn r1160.
Signed-off-by: Mattias Mattsson <vitplister@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>

Match on SMBus and Audio.
lspci/superiotool/flashrom output:
http://www.flashrom.org/pipermail/flashrom/2010-September/004689.html



Corresponding to flashrom svn r1159.
Signed-off-by: Joshua Roys <roysjosh@gmail.com>
Tested-by: Alexander Mikhnovets <alexander.mikhnovets@gmail.com>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>