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 <[email protected]> > > 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 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. 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. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
