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

[Urja Rannikko]

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.

>> - 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
there were no calls to myusec_delay bigger than the 10ms used for
AT29C020 detect.

>
>> - 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)


>
> For SPI, you also need select_chip() and deselect_chip().
>
I'll have to read more on SPI flash chips someday.


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


> Some external programmers (Cheetah, some FT2232 designs) also have their
> own buffer management. Any buffer management design will have to be
> compatible with them.
>

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

>> Peter wrote:
>>
>>> I think there are two parts to it. One is about the flashrom data
>>> model, which has been expanded a little lately but really needs to be
>>> very different.
>
> The big problem with a totally different data model is that we can't
> know for sure if it will work for everything in the future. Our current
> model was extended when it didn't fit anymore and each time it seemed
> that the model would be good enough after the change. There's no
> guarantee that we won't fall into the same trap with a complete redesign.
>
>
>>> The timing properties you mention are required for
>>> some chips and other chip types have other required property sets.
>>>
>>> The challenge here is to create a complete data model.
>>>
>
> Agreed. However, the data model needs to be understandable as well.
>
>
>>> The second part is to communicate that data from flashrom to
>>> satellite entities which all implement the same state machine.
>>>
>
> We have two state machines: One in the external flasher driver and one
> in the external flasher. The only thing we need is translation capability.
>
>
>>> The challenge here is to create a state machine which works for
>>> abstracting all the different ways we want to reach flash chips.
>>>

I wouldnt go and change a lot of things just to find out that the new
design has some big flaw...

>> Then maybe some command to return information about programmer
>> functionality would be good - eg.
>> - what bus type(s) it supports
>>
>
> The code already does that.

I'm talking about the serial protocol - i knew that flashrom already
has support for this information.

>
> Let's add
> programmer_can_access(struct flashchip *flash)
> which performs size checking etc so that probe_* can indeed return
> success even for too big chips. Some SPI controllers need that badly.
>
>
Ok.

-- 
urjaman