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