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