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

[Urja Rannikko]

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

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)
- initialize/clear buffer
- entering a write command to the buffer (with data and address)
- appending to a previous write command with a byte
- entering a delay command to the buffer (how long could it be? eg. is
16-bit udelay enough?)
- execute buffer

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.

(Peter wrote:) (i lost the header when editing...)
> I think these two issues go hand in hand.
That's propably why i brought them both up in the same mail.

> 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 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.
>
>
> The second part is to communicate that data from flashrom to
> satellite entities which all implement the same state machine.
Hmm programming a satellite remotely :P (j/k)

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

Then maybe some command to return information about programmer
functionality would be good - eg.
- what bus type(s) it supports
  - 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).
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.

-- 
urjaman