I'm replying from my phone with opera mini, so sorry bad formatting/short text.
On 2009-06-23, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 14.06.2009 20:23, Urja Rannikko wrote:
Support for an external serial flasher protocol. Supports RS-232, USB serial converters (untested) and TCP streams.
Signed-off-by: Urja Rannikko urjaman@gmail.com
Serial Flasher Protocol Specification - version 1 (0x01 return value == 1)
Command And Answer Sequence - not all commands give an answer
AFAICS all commands in your revised spec give an answer.
will fix
PC: COMMAND(8bit) <parameters determined by opcode> DEV: ACK/NAK(8bit) <OPTIONAL RETURN BYTES (only if ACK)> or nothing
ACK = 0x06 NAK = 0x15
All multibyte values are little-endian.
COMMAND Description Parameters Return Value 0x00 NOP none ACK 0x01 Query programmer iface version none ACK + 16bit version (nonzero) 0x02 Query supported commands bitmap none ACK + 32 bytes (256 bits) of supported cmds flags eg. cmd 0 support: byte 0 bit 0 cmd 1 support: byte 0 bit 1 cmd 7 support: byte 0 bit 7 cmd 8 support: byte 1 bit 0 0x03 Query programmer name none ACK + 16 bytes string (null padding) / NAK 0x04 Query serial buffer size none ACK + 16bit size / NAK 0x05 Query supported bustypes none ACK + 8-bit flags (as per flashrom) / NAK bit 0: PARALLEL bit 1: LPC bit 2: FWH bit 3: SPI if ever supported
We're missing a "set bustype" command here. Such a command should be sent directly after querying the supported bus types.
i already mentioned that somewhere, will add (the flash driver will need access to the cur flashchip struct for this to work)
0x06 Query supported chip size none ACK + 8bit power of two / NAK
Maybe extend this a bit to say "number of address lines" or somesuch.
Ok
0x07 Query operation buffer size none ACK + 16bit size / NAK 0x08 Query write-n maximum data len none ACK + 24bit maximum length / NAK
What about a "read-n maximum data length" command?
i dont know if necessary - the avr can stream the entire 24bit address space, this doesnt need ram to do - but could add "just in case".
0x00 Read byte 24-bit addr ACK + BYTE / NAK 0x0A Read n bytes 24-bit addr + 24-bit length ACK + length bytes / NAK 0x0B Initialize operation buffer none ACK / NAK 0x0C Write to opbuf: Write byte 24-bit addr + 8-bit byte ACK / NAK (NOTE: takes 6 bytes in opbuf)
I think it takes 5 bytes (1 command, 3 addr, 1 data).
hm - current avr code saves codespace by encoding all writes in the same len=1-256 format - can change
0x0D Write to opbuf: Write n 24-bit length + 24-bit addr + ACK / NAK (NOTE: takes 7+n bytes in opbuf) + length bytes of data 0x0E Write to opbuf: delay 32-bit usecs ACK / NAK (NOTE: takes 5 bytes in opbuf) 0x0F Execute operation buffer none ACK / NAK - Execute operation buffer will also clear it, regardless of the return value 0x10 Sync NOP none NAK + ACK (for synchronization)
0x?? unimplemented command - dont do, dangerous, check for support with 0x02 before using any opcode exept 0x10, 0x00, 0x01 and 0x02. if 0x01 doesn't return 1, dont do anything if you dont support a newer protocol.
You may want to add the following commands for handling of CE#, OE#, WE#. Read GPIO direction bitfield none ACK + 32 bits / NAK (0 is IN, 1 is OUT) Write GPIO direction bitfield 32 bits ACK / NAK Read GPIO status bitfield none ACK + 32 bits / NAK (status of each GPIO) Write GPIO status bitfield 32 bits ACK / NAK (bits with direction=IN are ignored) The GPIO stuff is pretty much optional for the first version of the spec, though.
one would need to define the GPIO's too. I think we can add these later if/when needed. The command support bitmap is there just for this kind of stuff.
I have no idea how fast the AVR is. If the AVR is fast enough to actually cause timing problems for Parallel flash with 120 nanosecond timing, we may have to handle this in some way, but then again, we have no way to query chip speed, so it's a moot point.
It depends. Maximum speed for an atmega{8,16,32}8 is 20mhz giving 50ns for the fastest possible operation (operating the shift regs makes things much slower for my board). The AVR code must just have the correct amount of nop's in the read/write cycle code - at 20mhz 2 nops = at best 150ns timing, my code has 2 nops now btw (the AVR runs at 18.432mhz for good serial though) .
Other than that, I think the protocol is fine for parallel flash.
Overall, I'd say it is a pretty extensible and roubust spec.
We should ship this as serprog.txt in the source tree.
ok :)
Regards, Carl-Daniel