[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