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

Urja Rannikko urjaman at gmail.com
Tue Jun 23 23:58:29 CEST 2009


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 at 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 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.
>
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
>
> --
> http://www.hailfinger.org/
>
>


-- 
urjaman




More information about the coreboot mailing list