[coreboot] [RFC] [flashrom] "accelerated" high-level external programmer functions and serial external programmer protocol
c-d.hailfinger.devel.2006 at gmx.net
Fri Jun 5 17:41:26 CEST 2009
On 05.06.2009 16:43, Urja Rannikko wrote:
> On Fri, Jun 5, 2009 at 17:18, Carl-Daniel
> Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>> - appending to a previous write command with a byte
>> Special case, should not end up in the interface. Either the programmer
>> driver performs auto-erge of write commands or it simply enters a new
>> write command.
> The point is here that the buffer management isnt visible outside of
> the programmer driver. Eg. when the programmers chip_writeb is called,
> it will check if the address is previous_address+1 and then send the
Looks nice. Where's the problem? Sorry if I am being dense.
>>> - entering a delay command to the buffer (how long could it be? eg. is
>>> 16-bit udelay enough?)
>> Some chips have delays of more than 60 seconds (yes, not ms or us).
>> 32bit udelay is the way to go forward. If your programmer can't handle a
>> given delay length, the driver should either split it into multiple
>> delays upon downloading it to the device or reject enqueuing such a delay.
> You mean delays or timeouts? I (@work) only had access to a bit old
> flashrom source (a webview or "LXR" would be nice, is there?), but
Needs to be done for the new flashrom tree. I'll ping Stefan or Patrick.
> there were no calls to myusec_delay bigger than the 10ms used for
> AT29C020 detect.
We have sleep(1) in some places.
>>> - execute buffer
>> - read byte
>> is missing from your design.
> I was listing only commands related to the buffer handling (at the
> serial protocol level, between the device and the flashrom external
> programmer driver)
The Cheetah wants read commands to be added to the device buffer...
Anyway, I just sent a patch which adds multi-byte read and write to the
external programmer interface. Can you take a look at it?
More information about the coreboot