[flashrom] Help, please. :-)

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Jul 23 03:46:12 CEST 2010


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 at 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 at 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 at 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

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list