[coreboot] [flashrom] [PATCH] external serial flasher protocol support

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Jun 23 14:50:21 CEST 2009

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

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

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

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

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

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

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.

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.



More information about the coreboot mailing list