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

[Carl-Daniel Hailfinger]

On 05.06.2009 15:44, Urja Rannikko wrote:
> I'm essentially replying to two mails at once now ...
>
> On Fri, Jun 5, 2009 at 15:17, Carl-Daniel
> Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> 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.
>>     

One of the most important design considerations is to make buffer
management optional. On-board programming doesn't need it (and would be
slowed down by it), lots of external programmers don't need it either.


> Actually this got me to thinking of the protocol and buffer storage
> format again.
> There would be commands to:
> - query buffer size (so different devices can support different
> amounts of buffer)
>   

OK.


> - initialize/clear buffer
>   

Maybe two separate functions for this.


> - entering a write command to the buffer (with data and address)
>   

OK.


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


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


> - execute buffer
>   

OK.

- read byte
is missing from your design.

For SPI, you also need select_chip() and deselect_chip().

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.

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


> A write command with data and address would be if it's a single byte,
> 6 bytes on buffer - 1 byte op, 1 byte len, 3 byte addr, 1 byte data,
> but continuation with append data to buffer would be the minimalist 1
> byte per byte, unless it's already 256 bytes of data inserted (encoded
> as 0-byte write) - then it would create a new write command. A delay
> would take 3 bytes on the buffer, 1 byte op, 2 byte delay value(?).
>
> This would allow for the programmer driver to feed the data to the
> device during flashrom execution, and upon the first read perform the
> execute buffer command. I think that with this format the AVR's SRAM
> is enough for this to work with all the parallel chips with 256 byte
> or less page size, propably even 512. (1 byte op, 1 byte len (0), 3
> byte addr, 256 byte data = 261 bytes)
>
> And here i'm a bit worried about flow control - or actually the lack
> of it in my hardware. Making each command immediately return an "OK"
> byte - and waiting for it makes it way too slow, so I'm thinking of by
> default making those "add write/delay command to buffer" commands
> return nothing and adding a NOP command that returns a byte and a
> command that returns the size of the serial buffer on the device, so
> that the programmer driver can send n bytes of commands in a stream,
> then send NOP, then wait for answer, then again send n bytes.
>   

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


> 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.
>>     
>
> You think of this a bit more abstract than i usually do, but basically i agree.
>
> Continuing on the protocol - it would need (ofcourse) also an n-byte read,
> I'm thinking that it could even be with 24-bit n so that the device
> could be instructed to read the entire chip in a single operation.
>   

That's what I wrote about the chip_readn function.

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

>   - if parallel, how many address lines it has attached to the chip socket
>    - actually offtopic, but i think it would be good for external
> programmers to have the ability to report the size of chip they
> support (eg 128k for the 3C905B) and for flashrom to issue a warning
> in case a bigger chip is detected (dont bail - it's still of some use
> for some purposes where you dont for example need the lower half of an
> 256k chip).
>   

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.


> I think that LPC and FWH can be operated over the same
> read/write/delay protocol as parallel, but
> i dont know how different SPI chips are and what extensions (if any)
> using them would need.
>
> And in reality my programmer supports only parallel (at the moment),
> so that will be my priority - but i hope i can make a protocol that
> suits any chip type well.
>   

For SPI, the design is necessarily different, but I'll submit a driver
for the TotalPhase Cheetah SPI programmer soon.

Regards,
Carl-Daniel

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