On 05.06.2009 14:02, Urja Rannikko wrote: >> What about introducing a per-programmer delay function pointer instead? >> Your programmer could buffer everything (delays, writes) until the first >> read, then send them as a batch. >>
Stefan pointed out that my text above is ambiguous. Let me retry: We have delays(mostly udelay) in the flashrom code, but almost always we don't want to delay flashrom operation, but make sure we honor the timing for flash chip accesses. For on-board programming, this is basically udelay. For external programmers, it is a bit more difficult. Some have builtin delay functions (like the TotalPhase Cheetah), some require the host to take care of delays. Having a per-programmer delay function would solve this nicely. > The only problem i see here that in order for this to work properly, i > would need to create the buffer on the programmer side (otherwise > there could be too big delays between the packets (even if streaming a > buffered store from the computer), eg. network packet loss) and i'm > not sure whether the AVR's 1k SRAM would be enough to hold even the > low level description of a single page load, given address + data = 4 > bytes + 1 byte operation = 5*256 = 1280 bytes. ofcourse the addresses > could be "compressed" (sequential), but it still doesnt sound right - > even simple op+byte would be 512+ bytes. We could compress down to op > + n + n bytes ... that could work. Not sure. > The buffer management would be performed by the programmer driver. So if your programmer can execute (or buffer) 1024 bytes of commands/address/data, make sure flashrom accumulates no more than 1024 bytes in its internal buffer before flushing its buffer to the device. >> The only remaining issue would be fast read, but for that it's easy to >> replace chip_readl (32bits) with chip_readn (n bytes). Your programmer driver could hook chip_readn (and possibly chip_writen) and implement optimized batch writes there. > I sent this accidentally only to carl-daniel first, sorry. > No problem. Thanks for resending. I hope my explanation was easier to understand this time. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
