[flashrom] [PATCH] Dediprog SF100 support

[Carl-Daniel Hailfinger]

On 19.01.2010 13:14, Stefan Reinauer wrote:
> On 1/19/10 1:08 PM, Carl-Daniel Hailfinger wrote:
>   
>> On 19.01.2010 12:43, Stefan Reinauer wrote:  
>>     
>>> On 1/19/10 12:36 PM, Carl-Daniel Hailfinger wrote:
>>>       
>>>> Hm. To be honest, reading is something I could not find in the logs.
>>>>
>>>>         
>>> I can provide a reading only log if that helps?
>>>
>>>       
>> Unfortunately that won't help. Reading uses USB bulk transfers without
>> opcodes. This may sound strange, but the SF100 firmware seems to have a
>> builtin mode where it issues the SPI READ opcode (or the FAST_READ
>> opcode, no idea without a SPI sniffer log) if you send a special request
>> without any opcode. As long as I have no idea about how to use this for
>> partial reads, we can't use that mode.
>>
>>     
> Well, then you need a log for a partial read?
>   

A log of a partial read of the last few sectors would be a good start,
but the big problem is that I don't know which opcode is sent to the
chip. So if you have a Bus Pirate or any other Sniffer, reducing the SPI
frequency to a point where the sniffer can keep up (at least for the
first sector or so) would at least reveal the opcode used by the
Dediprog. Then I could create an opcode filter which diverts reads to a
separate bulk read function.


> Frankly, it would still be around 60-100 times faster to always read the
> whole chip and just through away what you don't need ;-)
>   

Hm yes. Right now not knowing the opcode sent to the chip is the biggest
problem.


>> Good news: My patch works as designed. Read seems to work as well. Ack
>> please?
>> Bad news: The dediprog is dog slow. 
>>     
> Not with the windows software. It looks like only your driver is slow,
> not the dediprog ;-) But hey, it's a start.
>   

The windows driver uses one control URB, then does bulk reads until the
chip is completely read. With 512 bytes per bulk read, this means we
have 8192 bulk transactions. That's fast.
The flashrom driver uses control URBs for everything: One for sending
the opcode, one for reading the result in 4 byte chunks. That means we
send 2 million URBs down the wire and receive 2 million URBs. We
probably spend 250 µs per transaction on USB 2.0, maybe more.


>> sloooooooow. Reading works, but for a 4 MByte chip it may take up to 35
>> minutes AFAICS, maybe more. The file specified by -r will only be filled
>> with contents after the read is complete.
>>   
>>     
> Maybe it shouldn't be created before that, either, then?
>   

Not sure. Reading a chip for 35 minutes and then noticing that the file
can't be created isn't exactly nice either.


>> I see a speedup by a factor of 4 on the horizon, but I will implement
>> that only after I get confirmation that read works correctly (would be
>> pointless otherwise).
>>   
>>     
> Requiring 10 minutes to read the chip is still kind of pointless, so I
> don't know if it's worth the effort if the driver can't be generally fixed.
>   

Get me a log of the SPI side (the first 1024 bytes or so are sufficient)
with a matching log on the USB side and I can reach the same speeds as
the windows driver.

As interim measure, I can increase read chunk size to 16 (speedup factor
4) once we know if read works. Once we know read chunk size 16 works, I
can test bigger chunk sizes up to 64 (USB protocol limit). That would be
a factor of 16 faster than the current implementation. Maybe not
perfect, but it would definitely be usable.
I need those chunk size tests anyway to implement write support.


Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."