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

[Carl-Daniel Hailfinger]

On 06.06.2009 00:08, Urja Rannikko wrote:
> On Sat, Jun 6, 2009 at 00:37, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 05.06.2009 23:12, Urja Rannikko wrote:
>>     
>>> Serial Flasher Protocol Specification
>>>
>>> All multibyte values are little-endian.
>>>
>>> COMMAND       Description                     Parameters                      Return Value
>>>
>>> 0x07  Initialize operation buffer     none                            ACK / NAK
>>> 0x08  Write to opbuf: Write byte      24-bit addr + 8-bit byte        nothing / NAK (NOTE: takes 6 bytes in opbuf)
>>> 0x09  Write to opbuf: Write byte seq  8-bit byte                      nothing / NAK (NOTE: takes 1 bytes in opbuf)
>>>
>>>       
>> Hm. I don't understand the opbuf lengths here.
>> By the way, having a single-byte write command (like you have) and a
>> multi-byte write command would probably be a more future-proof design.
>> 0x09     Write to opbuf: Write byte seq 24-bit addr + 24-bit length + n
>> bytes data                   ACK/NAK (Note: takes 7+n bytes in opbuf)
>>     
> Firstly, realize that the above command would have a second length
> parameter of different size than the first in parameters - a parser
> without knowledge of the commands parameters would surely fail.
>   

We're misunderstanding each other here.
I propose that flashrom does all the merging internally (up to a maximum
write size). Thus the n-byte read command and the n-byte write command
would be very similar.


> the opbuf lenghts are because the driver must take note not to buffer
> too much operations in the AVR before executing them. A write command
> format in the AVR memory is essentially 0x00 (writeop) 0xnn (lenght)
> 0xaa 0xbb 0cc (begin address) + n bytes of data. the 0x08 operation
> creates the initial 1-lenght write op that takes 6 bytes (1 op, 1
> lenght, 3 addr, 1 data) and each 0x09 operation adds one to lenght and
> appends the data. In case the length is already 0 (meaning 256), a new
> write operation with modified address (+256) is created, etc. So a
> continouous write of 256 bytes takes 261 bytes in the buffer.
>   

Unless there is some device limitation, I think it is easier to already
send a byte stream the AVR uses internally than having the AVR translate
it in a complicated way. OTOH, your AVR internal representation is
designed for compactness.


> I considered adding a write n function, but realized that it would
> make the parameter lenght variable - now i can check that it is
> correct with a simple op2len table (a double-check that the parameters
> are correct). I dont see it worth the hassle, and it could code at a
> maximum 252 bytes of data with the current opcode lenght format - and
> the AVR's memory would surely run out if i asked it to take in some
>  >1k operation anyways.
>   

So you check the commands the AVR receives from the host, but not the
commands in the internal AVR buffer? Because according to your
description, the internal commands can have variable size.


> The read n operation is in many ways different - it can have the
> length in parameters because that is the return data length (not
> command parameter length), and the AVR doesnt need to buffer the data
> it sends in a reply.
>   

If I understand this correctly, your command-from-host parser in the AVR
is easier to write if the commands from the host have per-opcode
constant length?
If that is the case, I propose to add an additional opcode 0x02 which
returns a 32-bit field of supported opcodes. Then your device could mark
the write-n as unsupported and the write-next as supported.


>> I'd like all commands to send a return code. All those write opcodes
>> could be returning ACK even before they are sent.
>>     
>
> Huh? (My AVR doesnt know the future... And the computer would surely
> be baffled about an ACK before sending the command :P)
>   

Bad wording on my side. A write opcode should be acked after it is
received by the programmer. No need to wait until the write reaches the
flash chip.