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

Urja Rannikko urjaman at gmail.com
Sun Jun 14 12:21:31 CEST 2009


On Wed, Jun 10, 2009 at 23:20, Warren Turkal<wt at penguintechs.org> wrote:
> Technically speaking, the ACK/NAK ASCII codes don't need to be used,
> but I think that it would be much more approachable for folks
> implementing the protocol if the traditional ASCII codes were used.

Ok, i'll change those then - not a big issue for me.

> Also, if you are using the NAK+ACK for synchronizing, it might be good
> to do more than one round, like NAK+ACK+NAK+ACK+NAK+ACK. I just pulled
> this suggestion out of the air, so maybe rs232 geeks can speak up as
> to whether it makes sense or not.

It might be worth it doing one additional SYNCNOP cycle with a
condition that the NAK must be the first byte received (after giving
the command) to make sure of the synchronization, but i wont do more
than that because this synchronization function is pretty slow already
(and kinda udelay-dependent).

> It also might make sense to have the NOP for synchronization use some
> combination of 1's and 0's so that an improper speed configuration on
> the computer side would be less likely to cause problems. Again, rs232
> geeks can tell us of if that suggestion makes sense.

I think that this is not necessary (see next "chapter"), altough i
might change the protocol to have command 0x10 as SYNCNOP (returning
NAK+ACK) and 0x00 as just NOP - returning ACK, this might improve the
robustness of the protocol.

If the receiver samples 0x00 too slowly, it will get a byte with some
bits set (in the on-the-line last bits).
If the receiver samples 0x00 too fast, it will get 0x00, but also a
stop bit error (framing error. stop bit = 0) and should be able to
filter it out.

I'll modify all the code and specification and send a new patch (maybe
today (this mail is sent 13:20)).

-- 
urjaman




More information about the coreboot mailing list