[coreboot] [RFC] [flashrom] "accelerated" high-level external programmer functions and serial external programmer protocol

[Carl-Daniel Hailfinger]

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/