Re: [coreboot] [RFC] [flashrom] "accelerated" high-level external programmer functions and serial external programmer protocol
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.
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.
I sent this accidentally only to carl-daniel first, sorry.
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
-
Carl-Daniel Hailfinger -
Urja Rannikko