[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 wrote:
>   
>
> 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.
>
>   
>> 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?

Usually, short delays are indeed timing-critical delays whereas longer
delays are simple timeouts.


>> Please make sure that the flashrom buffer format has no dependencies on
>> the programmer buffer format. Since hardware is more difficult to change
>> than software, we definitely want to keep the flashrom buffer design
>> changeable without breaking hardware. 16-bit vs. 32-bit delays could be
>> one such difference.
>>
>>     
> The point in this was that there would be no buffer on flashrom's side
> - only on the device memory - although that buffer would be handled by
> the in-flashrom external programmer driver. I did consider skipping
> that write-combining so that the device would compress the stream, but
> then i thought that when using real serial, that would slow down
> writing manyfold to pass all the addresses to the device (AVR).
>   

OK, that works as well. My idea was to have a buffer on the flashrom
side which can then be compacted or optimized and translated by the
programmer driver before sending it off to the device. Such a buffer
inside flashrom is optional, though.


>> What you want is an explicit execute_buffer() function. Writes and
>> delays don't return anything by default. The programmer driver decides
>> when to issue execute_buffer()
>
> There will be execute buffer command on the AVR, but if (eg.) the AVR
> (for any reason) cannot process serial data as fast as it can receive
> serial data to it's serial buffer, then sending more bytes of commands
> than it's serial buffer to it could cause it to lose data. Eg. you
> need to be able to ask it that it has processed all the commands
> given.
>   

Yes, for that you need flow control. For example, you you have the
programmer return the amount of bytes free in the buffer after each
command stream you send to the device.

Regards,
Carl-Daniel

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