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

[Urja Rannikko]

On Sat, Jun 6, 2009 at 01:36, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> 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.

I mean that take a look of the start of file:
PC: LENGHT(8bit) COMMAND(8bit) <LENGHT PARAMETER BYTES>
This allows the AVR to skip commands for which it doesnt know the
purpose of the parameters and just NAK them.
"24-bit addr + 24-bit length + n bytes data" would cause
"lenght" +  "command" + "addr" + "bigger lenght" + data to be sent to
the AVR --- if after the command there's a different amount of bytes
than specified in the first lenght ... boom

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

Well the commands in the internal AVR buffer are generated by the
checked commands, so they are "sure" to be correct - no need to check
them, though the code does basic checking on that stream too during
execution, for example if a command that doesnt exist is found in the
stream or the stream ends mid-command, a NAK is returned.

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

A write-n with n max 252 would be easy to implement as compatible with
the protocol, and actually even the AVR could handle it. The point in
the ACK/NAK system was in the beginning to allow a programmer to not
implement any opcode (exept NOPACK - now also query interface version)
and return NAK when trying to do that (the flashrom driver could issue
write-n, get NAK, try with singular/"AAI" writes as a fallback). I
chose not to have 24-bit lenght header in every opcode because of the
limits on serial speeds.

>>> I'd like all commands to send a return code. All those write opcodes
>>> could be returning ACK even before they are sent.
>>>
>
> 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.
> From your proposal it is not clear if flashrom receives an ACK/NAK after
> sending the command to the programmer or after successful execution of
> the command. Could you elaborate?
>

Hmm... the only ACK from a write on the buffer is got when executing
the buffer ("the whole buffer was executed") as a reply to execute
buffer, this is in purpose not to have PC's doing "ping-pong" with the
AVR during writing of the buffer - the host can do non-blocking I/O to
check for a NAK after streaming the write commands. (Or send an NOPACK
and read until you get an ACK - then there were no NAK's when
writing). Of course it would also be possible to have them all return
ACK and then do write lots + count all the ACK's on the host side, but
i dont see that as necessary.

-- 
urjaman