[flashrom] SPI Flashing via Bus-Pirate to DFI T3H6

[Carl-Daniel Hailfinger]

Hi Daniel,

On 17.06.2010 12:54, Daniel Flinkmann wrote:
> Am 17.06.2010 um 12:32 schrieb Carl-Daniel Hailfinger:
>   
>>> At the moment I am still waiting for the end of the write flash command, 
>>> which is running since 23:22 CET yesterday (So that are 8 hour running).
>>>       
>> If I take into account the too long timing you were experiencing during
>> read, the expected write time (with my 3x speedup patch) is roughly 9 hours.
>>     
>
> As Homer says: Doh! 
>
> I had to stop the writing again (probably after 8,5 hours, because I wasn't expecting 
> to wait so long and I needed my computer which ran the ssh session elsewhere. 
> So I had to restart the process in a gnu screen session today morning and left 
> it running. Excuse me for that dumb idea to not running the flashrom in a HUPable
> situation.
>   

Heh. I should have warned you. Sorry about that.


>>> Erasing was complete at aprox 23:38:30 , so roughly after 13 minutes, which is much better. Up to now, I am waiting 8 hours to see any additional reporting, but flashrom is still running.
>>>
>>>       
>> It might make sense to abort if it is still running after 12 hours total
>> (4 hours after your mail). If you abort, please read the chip afterwards
>> and upload the read file here: http://wedgewww.dyndns.org/uploader/
>>     
>
> Yes, I will do so. 
>
> By the way. The first reading tests I have done ( svn1048, 1048+3xBP-patch and 
> 1048+3xBP-patch+no_delay-patch) resulted in three identical binary files. I just 
> double checked that with an md5sum. 
>   

Good. Did those images contain only 0xff bytes or was there real content
inside (you can use hexdump or xxd to check).


>>> I will try the test with a first spi command later and report again.
>>>
>>>       
>> Thanks.
>>     
>
> As you expected, the first spi command fails all the time. I added my normally detected spi flash 
> device and retried it, which causes the same error: 
>
> root at zwerg:~# flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -c SST25VF080B -VV
> flashrom v0.9.2-r1048-with-3xspeed-bp-patch on Linux 2.6.32-22-server (x86_64), built with libpci 3.0.0, GCC 4.4.3, little endian
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OS timer resolution is 1 usecs, 298M loops per second, 10 myus = 11 us, 100 myus = 101 us, 1000 myus = 1050 us, 10000 myus = 9990 us, 4 myus = 5 us, OK.
> Initializing buspirate_spi programmer
> SPI speed is 8MHz
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
> buspirate_sendrecv: write 1, read 5 Sending 0x00, receiving 0x42 0x42 0x49 0x4f 0x31
> Raw bitbang mode version 1
> buspirate_sendrecv: write 1, read 4 Sending 0x01, receiving 0x53 0x50 0x49 0x31
> Raw SPI mode version 1
> buspirate_sendrecv: write 1, read 1 Sending 0x4b, receiving 0x01
> buspirate_sendrecv: write 1, read 1 Sending 0x67, receiving 0x01
> buspirate_sendrecv: write 1, read 1 Sending 0x8a, receiving 0x01
> buspirate_sendrecv: write 1, read 1 Sending 0x03, receiving 0x01
> Probing for SST SST25VF080B, 1024 KB: buspirate_sendrecv: write 7, read 7 Sending 0x02 0x13 0x9f 0x00 0x00 0x00 0x03, receiving 0x01 0x01 0x00 0x00 0x00 0x00 0x01
>   

Mh. I expect that an unpatched Bus Pirate driver will have the same
problems.
Which Bus Pirate is this, and which firmware are you running on it?
AFAIK some firmware versions have known bugs which might affect us. If
your firmware is indeed one of the broken versions, I hope we can add a
blacklist to flashrom and refuse to communicate unless the Bus Pirate is
upgraded.


> RDID returned 0x00 0x00 0x00. RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x00, id2 0x00
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> buspirate_sendrecv: write 1, read 5 Sending 0x00, receiving 0x42 0x42 0x49 0x4f 0x31
> Raw bitbang mode version 1
> buspirate_sendrecv: write 1, read 0 Sending 0x0f, receiving
> Bus Pirate shutdown completed.
>
>   
>> I just sent a progress bar printing patch (OK, it is a really nasty
>> hack) to the list.
>> If you decide to abort, please use the progress printing patch together
>> with the 3x speedup patch. Read/erase time shouldn't suffer that much
>> from progress printing, and write probably won't be slowed down that
>> much either.
>>     
>
>
> Lets see how far it will be tonight and then I will restart it. I received my backup
> BIOS flash today, so I will first install the new flash and see if that PC runs fine 
> again. If so, I will make a short setup to flash the bricked BIOS externally, so that 
> we still get forward in with the Bit-Pirate issue.
>   

Cool, thanks!

Regards,
Carl-Daniel

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