On 22.07.2010 13:05, Carl-Daniel Hailfinger wrote:
On 22.07.2010 09:33, Michael Karcher wrote:
[...] I suspect that something goes wrong with the communication between the chipset and the flash chip (maybe some other flash accesses, for example from System Management Mode?).
The board has an IPMI controller which may cause all sorts of screwups.
Greg, Colin, can you get a sharp high-res photo of the region of the board where the flash chip is located and upload that to imageshack or some other service? I want to be 100% sure that we're not dealing with a situation where two flash chips are present, and the IPMI controller switches between chips to confuse flashrom to no end.
Ummm... the photo you sent showed the IPMI controller, but I wanted a photo of the SST25VF016B flash chip and the region around it. Please upload your photo to imageshack.us (my mailbox is overflowing already and further huge mails may be discarded silently) and paste only the link to that photo in your mail.
On 22.07.2010 09:33, Michael Karcher wrote
Am Mittwoch, den 21.07.2010, 22:19 -0400 schrieb Colin Williams
and it now reports the chip as a "SST unknown SST SPI chip", with all four operations not working. Attached are the output of the failed flash attempt, and a probe from after that attempt.
can you please send the output of "flashrom -VV" and "lspci -vvvnnxxx" to the list, and send me privately the old backup image, the image you tried to write and the file "contentsnow.bin" created by 'flashrom -r contentsnow.bin -f -c SST49LF160C', and also check whether different runs of flashrom create the same contentsnow.bin? It looks like flashrom managed to mess up your chipset configuration that much that most flash accesses do not do what they really should do anymore.
Yes, the flash chip seems to be totally confused. Once we have the output of the commands above, we have a good chance to find a way to whack the chip on the head so that it will respond normally again.
From the readbacks you sent I got the following information:
carldani@p35:~> hexdump -C contentsnow.bin 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 001f0a70 ff fb ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 001f0a80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00200000 carldani@p35:~> hexdump -C contentsnow2.bin 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 001f0a70 ff fb ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 001f0a80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00200000 carldani@p35:~> hexdump -C contentsnow3.bin 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00200000
contentsnow.bin and contentsnow2.bin are SST49LF160C readbacks (i.e. memory dumps) and contentsnow3.bin is a SST25VF016B readback (SPI dump).
Your "flashrom -VV" output was truncated, but I think a few essential pieces of information were usable. It seems that the FIFO for reading is dysfunctional right now and returns a repeat of the first response byte, but apparently it worked well for the original read. The IPMI controller and/or the 8051 core in the southbridge may be interfering as well.
Can you reply-to-all with the output from "flashrom -V" to allow us to cross-check my assumptions?
Regards, Carl-Daniel