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 _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
