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?
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 ;-)
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.
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?
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.
Stefan