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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed Jun 16 17:00:26 CEST 2010


Hi Daniel,

On 16.06.2010 16:34, Daniel Flinkmann wrote:
> Thanks for the quick reply. See my answers below: 
>   
>>> After that I can't see 
>>> any progress, as -V is pretty silent when writing the flash and -VV dumps far too much 
>>> to have an overview. 
>>>
>>>       
>> Yes. Progress bar printing is on our list of useful things to do, but
>> some parts of the current flashrom architecture don't really fit, and
>> thus this will require quite some refactoring. I can hack up a progress
>> printing patch which outputs a dot every time 1024 bytes are
>> read/written. That would give you some progress indicator for now, and
>> we can continue fixing flashrom to eventually support something like
>> that natively.
>>     
>
> Understood. The dots every 1kb would help to have a minimal monitoring.
>   

Will tackle that soon.


>>> Probing for Atmel AT25DF021, 256 KB: RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x00, id2 0x00
>>>
>>>       
>> WTF?!? This looks like data corruption. Such a response is absolutely
>> unacceptable. Can you run
>>
>> flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -V
>>
>> a few times (should be a matter of a few seconds) and check if any
>> probe_spi_rdid_generic complains about a parity violation? If yes, there
>> is a bug somewhere which needs to be fixed.
>>     
>
> Yes, I will do so, when I am back at home and report them to the mailing list. 
>   

Thanks.


>>> Chip status register is 1c
>>> Chip status register: Block Protect Write Disable (BPL) is not set
>>> Chip status register: Auto Address Increment Programming (AAI) is not set
>>> Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
>>> Chip status register: Bit 4 / Block Protect 2 (BP2) is set
>>> Chip status register: Bit 3 / Block Protect 1 (BP1) is set
>>> Chip status register: Bit 2 / Block Protect 0 (BP0) is set
>>> Chip status register: Write Enable Latch (WEL) is not set
>>> Chip status register: Write In Progress (WIP/BUSY) is not set
>>> Found chip "SST SST25VF080B" (1024 KB, SPI) at physical address 0xfff00000.
>>>
>>>       
>> Ouch! That chip can only write one byte at a time. This will be painful
>> and slow. We might be able to use a few tricks (e.g. AAI write), but
>> even with the tricks, your flash chip is one of the worst cases for the
>> Bus Pirate.
>>     
>
> Better awfully slow, than having a brand new, but bricked mainboard ( I have ordered 
> a new preflashed flash chip, but it is still in the delivery). So I am open for some more pain ;-)
>   

True. By the way, flashrom can do cross-flashing, so if the flash chip
is removable, you could hotplug it into another board with SPI flash and
run flashrom there. Would be much faster (maybe a minute to write), and
reads would probably take a second or two.


>>> Flash image seems to be a legacy BIOS. Disabling checks.
>>> Writing flash chip... Some block protection in effect, disabling
>>> Erasing flash before programming... Erasing flash chip... Looking at blockwise erase function 0... trying... 0x000000-0x000fff, 0x001000-0x001fff, 0x002000-0x002fff, 0x003000-0x003fff, 0x004000-0x004fff, 0x005000-0x005fff, 0x006000-0x006fff, 0x007000-0x007fff, 0x008000-0x008fff, 0x009000-0x009fff, 0x00a000-0x00afff, 0x00b000-0x00bfff, 0x00c000-0x00cfff, 0x00d000-0x00dfff, 0x00e000-0x00efff, 0x00f000-0x00ffff, 0x010000-0x010fff, 0x011000-0x011fff, 0x012000-0x012fff, 0x013000-0x013fff, 0x014000-0x014fff, 0x015000-0x015fff, 0x016000-0x016fff, 0x017000-0x017fff, 0x018000-0x018fff, 0x019000-0x019fff, 0x01a000-0x01afff, 0x01b000-0x01bfff, 0x01c000-0x01cfff, 0x01d000-0x01dfff, 0x01e000-0x01efff, 0x01f000-0x01ffff, 0x020000-0x020fff, 0x021000-0x021fff, 0x022000-0x022fff, 0x023000-0x023fff, 0x024000-0x024fff, 0x025000-0x025fff, 0x026000-0x026fff, 0x027000-0x027fff, 0x028000-0x028fff, 0x029000-0x029fff, 0x02a000-0x02afff, 0x02b000-0x02bfff, 0x02c000-0x02cfff, 0x02d000-0x02dfff, 0x02e000-0x02efff, 0x02f000-0x02ffff, 
>>> SUCCESS.
>>> done.
>>>
>>>       
>> Timing with the Bus Pirate can be calculated as follows:
>>
>> If we assume the usbserial driver of your OS pushes all bytes of a
>> read/write at once, we have one USB transaction per read and one
>> transaction per write. Each transaction takes 1 ms (USB standard).
>> To send a SPI command to the chip, we need:
>> - one write/read to activate CS#
>> - one write/read to send/receive SPI command and response
>> - one write/read to deactivate CS#
>> This means a total of 6 transactions and 6 ms per SPI command if we have
>> optimal conditions.
>> To read a whole chip, we slice it up in pages of 256 bytes each (some
>> chips need that) and then we slice each page up in chunks of 12 bytes
>> each (Bus Pirate read length limit). This means we have 22 chunks per page.
>> Your chip has 1 MByte (1048576 bytes), 4096 pages and thus 4096*22=90112
>> read chunks. Each chunk has to be read with a separate command, so the
>> absolute minimum read timing for your chip with the current code is
>> 90112*6=540672 ms or roughly 9 minutes.
>>
>> Your chip supports two write modes:
>> - standard one-byte-at-a-time (write_1) write (default)
>> - auto address increment (AAI) write
>> and flashrom uses write_1 mode right now (can be changed).
>>
>> write_1 mode means you have to send at least three SPI commands to the
>> chip per written byte: write enable, write byte, read status.
>> Your chip has 1 MByte (1048576 bytes), needs 1048576 byte writes, thus
>> 1048576*3=3145728 SPI commands, and 3145728*6=18874368 ms or roughly 315
>> minutes to write in the optimal case, plus the time to verify (full chip
>> read).
>>
>> AAI write mode means you have to send at least two SPI commands (or one
>> SPI command and continuous listening on the SO pin) per two written bytes.
>> Your chip has 1 MByte (1048576 bytes), needs 1048576/2=524288 AAI
>> writes, thus 524288*2=1048576 SPI commands, and 1048576*6=6291456 ms or
>> roughly 105 minutes to write in the optimal case, plus the time to
>> verify (full chip read).
>>
>> The current flashrom SPI code has some additional delays which shouldn't
>> have an effect during erase/read, but I sent a patch to remove them a
>> few minutes ago. Those delays slow down write a lot, though.
>>
>> Once the delay removal patch is in, the following options remain:
>> - Use AAI to speed up write by a factor of 3 compared to the default.
>> - Violate the Bus Pirate communication protocol and batch each
>> CS/command/CS combination into one write/read. Should result in a
>> speedup for read/write/erase by a factor of 3. Not sure if it is doable.
>> - Violate the Bus Pirate communication protocol some more and batch each
>> flashrom multicommand into one write/read. Speedup by a factor of 2 for
>> write.
>>
>> With enough protocol violations and AAI write, the minimum write time
>> for your chip is roughly 18 minutes plus the time to read the chip. This
>> write time can only be achieved if your OS has good usbserial drivers
>> and if the Bus Pirate is fast enough.
>>
>> The biggest mystery right now is the 60 minutes required to erase.
>> Unless I'm mistaken, this means all of the time is spent reading for the
>> verify operation. Given that my calculations result in 9 minutes read
>> time, I'd like to know what's going wrong here before you attempt to
>> write. If this is a problem affecting all operations, you would have to
>> deal with write taking a day or more. That is totally unacceptable.
>>
>> Can you measure exactly how long a read of the chip takes, preferably
>> while no other processes are running in the background on the machine
>> running flashrom?
>>     
>
>
> I don't like the idea to violate the Bus Pirate communication protocol, but using 
> AAI and utilizing your new sleep removals should be a nice step forward.
>   

OK. I just sent a patch which violates the protocol, but according to
the data sheets I have available my hack should work due to existing
buffer sizes even if it violates the protocol.


> The used computer which is running flashrom and using the Bus Pirate is
> an Atom D330 running 64bit Ubuntu Lucid Lynx and is normally just a 
> TimeMachine/Fileserver, but was idling all the time.
>   

Hm. Are you running the machine with HZ=100 or HZ=100? HZ=1000 could in
theory improve flash access speed (due to scheduler side effects).


> I will try to make an exact measurement of the flash erasing and rom reading again.
>   

No need to get erase timing, read timing is sufficient.


> Shall I give your speed-up patch a try before I start doing the measurement above?
>   

It would be nice if you could measure read timing with unmodified
flashrom and with my protocol violation hack.


Regards,
Carl-Daniel

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






More information about the flashrom mailing list