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.
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.
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?
Regards, Carl-Daniel