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

[Carl-Daniel Hailfinger]

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
> combine.
>   

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
>>>
>>>       
>> OK.
>>
>> - 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?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/