This patch changes the prefix of chip constant #defines in the following way:
AM_nnnnnnn -> AMD_AMnnnnnnn
AT_nnnnnnn -> ATMEL_ATnnnnnnn
EN_nnnnnnn -> EON_ENnnnnnnn
MBMnnnnnnn -> FUJITSU_MBMnnnnnnn
MX_ID -> MACRONIX_ID
MX_nnnnnnn -> MACRONIX_MXnnnnnnn
PMC_nnnnnnn -> PMC_PMnnnnnnn
SST_nnnnnnn -> SST_SSTnnnnnnn
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
Signed-off-by: Mattias Mattsson <vitplister(a)gmail.com>
Am Mittwoch, den 15.09.2010, 20:14 +0200 schrieb STEMMELIN, FREDERIC
(FREDERIC)** CTR **:
> NOT WORKING is writing from original Tyan BIOS image (Error: Image
> size doesn't match, 2895V106.wph,
> ftp://ftp.tyan.com/bios/S2895_v106.zip)
This is normal for phoenix images (flashed by winphlash or phlash16),
because these images have code containing board and chip specific update
functions appended to the flash image. Taking only the first 1048576
bytes of that file using e.g. head or dd is known to generally work on
phoenix BIOSes
Regards,
Michael Karcher
Hello,
i received today my 2 new SST chips for the Tyan S2895 mobo with BIOS version 1.06 alreday flashed by BIOSMAN company.
For a quick summary, what is working and what not:
WORKING is chip read, and write with flashrom dumpped image
NOT WORKING is writing from original Tyan BIOS image (Error: Image size doesn't match, 2895V106.wph, ftp://ftp.tyan.com/bios/S2895_v106.zip)
So, what have a done exactly:
- used flashrom v0.9.2-r1001 on Ubuntu to dump my current original bios SSTFL49080A with official 1.06 bios version flashed with propriarity tool provided by Tyan company.
- md5sum of this dump => 4c3cc932a149e8bf496160814d0a9c74
- powered computer down
- replaced original chip with one from BIOSMAN, same SST reference, with bios 1.06 on it (biosman has flashed the chip for me with lastest available bios version 1.06, not myself)
- power on computer with biosman chip inside
- used flashrom to dump biosman version of 1.06
- md5sum of the biosman 1.06 version => 18ede76905b99e4591122c5a3032bb2b
- used flashrom to write original bios from tyan website (files 2895V105.wph or 2895V106.wph) => FAILED with incorrect size error message
- used flashrom to write dump made with flashrom from original tyan bios chip => SUCCES (see file: flashrom_Vw_SST-49FL080A_TYAN_s2895_K8WE-flashrom_burn_from_original_tyanchip106_dump.txt)
- md5sum after successfull flashing => 4c3cc932a149e8bf496160814d0a9c74
md5sum gives me insurance that dumping flash chip content from first chip and burning to another chip (after computer power down/up to replace chip) is the same, so write function is working pretty
The only thing that it is not working is to flash from tyan bios downloaded version (.wph files), as their siez are bigger.
Bios SIZE: dump with flashrom => 1048576 bytes ; original Tyan bios file 2895V106.wph => 1050070 bytes
I have not tried the erase function so far.
Computer seems to work fine so far (Ubuntu gnome), with all bioses version, before and after flashing, bios menu are ok too.
Have a nice evening.
PS: file flashrom_Vw_SST-49FL080A_TYAN_s2895_K8WE-tyan105origtry1.txt is to show you siez error while trying flashing Tyan original wph bios files (version 105, but same for 106). File names wre truncated by Windows webmail :(
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-sb700_imc_refuse_write/sb600spi.c
===================================================================
--- flashrom-sb700_imc_refuse_write/sb600spi.c (Revision 1171)
+++ flashrom-sb700_imc_refuse_write/sb600spi.c (Arbeitskopie)
@@ -294,6 +294,24 @@
return 0;
}
+ reg = pci_read_byte(dev, 0x40);
+ msg_pdbg("SB700 IMC is %sactive.\n", (tmp & (1 << 7)) ? "" : "not ");
+ if (tmp & (1 << 7)) {
+ /* If we touch any region used by the IMC, the IMC and the SPI
+ * interface will lock up, and the only way to recover is a
+ * hard reset, but that is a bad choice for a half-erased or
+ * half-written flash chip.
+ * There appears to be an undocumented register which can freeze
+ * or disable the IMC, but for now we want to play it safe.
+ */
+ msg_perr("The SB700 IMC is active and may interfere with SPI "
+ "commands. Disabling write.\n");
+ /* FIXME: Should we only disable SPI writes, or will the lockup
+ * affect LPC/FWH chips as well?
+ */
+ programmer_may_write = 0;
+ }
+
/* Bring the FIFO to a clean state. */
reset_internal_fifo_pointer();
--
http://www.hailfinger.org/
Author: hailfinger
Date: Wed Sep 15 14:02:07 2010
New Revision: 1173
URL: http://flashrom.org/trac/flashrom/changeset/1173
Log:
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.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Tested-by: Matthias Kretz <kretz(a)kde.org>
Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de>
Modified:
trunk/sb600spi.c
Modified: trunk/sb600spi.c
==============================================================================
--- trunk/sb600spi.c Wed Sep 15 12:20:16 2010 (r1172)
+++ trunk/sb600spi.c Wed Sep 15 14:02:07 2010 (r1173)
@@ -294,6 +294,24 @@
return 0;
}
+ reg = pci_read_byte(dev, 0x40);
+ msg_pdbg("SB700 IMC is %sactive.\n", (reg & (1 << 7)) ? "" : "not ");
+ if (reg & (1 << 7)) {
+ /* If we touch any region used by the IMC, the IMC and the SPI
+ * interface will lock up, and the only way to recover is a
+ * hard reset, but that is a bad choice for a half-erased or
+ * half-written flash chip.
+ * There appears to be an undocumented register which can freeze
+ * or disable the IMC, but for now we want to play it safe.
+ */
+ msg_perr("The SB700 IMC is active and may interfere with SPI "
+ "commands. Disabling write.\n");
+ /* FIXME: Should we only disable SPI writes, or will the lockup
+ * affect LPC/FWH chips as well?
+ */
+ programmer_may_write = 0;
+ }
+
/* Bring the FIFO to a clean state. */
reset_internal_fifo_pointer();