[coreboot] [RFC] [flashrom] "accelerated" high-level external programmer functions and serial external programmer protocol

[Urja Rannikko]

Hi all,

I have a device that i would like to make a flashrom supported
external programmer, an atmega168 with 3 shift registers as address
bus and a DIL32 socket connected via RS232. Currently it runs it's own
special software and i have special software on the PC to use it - but
this combination supports (at the moment) only AT29C020 and W29C020C,
so using flashrom's great database of flash chips would be great. Ok,
so i would just implement a protocol for passing read and write cycles
though the serial bus, sounds easy but there's a caveeat: eg. for the
W29C020C there's a timeout between the bytes in the page load algo,
200us. For serial only i might be able to do that, but as my device
isnt really attached to my computer's serial port (it's transmitter is
busted..) but instead an serial<->ethernet adapter, there's no way one
can do a "ping" in 200us, same problem applies for the USB FTDI chips
i think. Even if it would work, the performance would be way too low.

So, i suggest a way for external programmers to provide alternatives
to the normal flash chip functions like probe_jedec, read_memmapped,
write_jedec, etc. In the external programmer init function the code
could/would "attach" a table to a global pointer that defines
re-mappings of chip functions, and before calling a chip function
flashrom would check if the pointer is non-null and then check if
there's an alternative to the function that is to be used, and would
call the alternative instead. The alternative function would then use
it's special protocol to actually cause the function to be "executed"
on the programmer device, requiring much less bandwidth and making
those timing requirements  easy to meet. In case there's no re-mapping
of some flash chip function (i wouldnt want to implement all the flash
chip functions on my external programmer at once), the external
programmer would ofcourse also implement the basic read and write
cycles and the original flash chip access function would try to
operate using those - whether that works is a different issue.

That's the first part of  this "RFC" ... comments please.

Then i suggest that we would try to make some kind of a "standard" for
an external serial programmer protocol - it could run over the normal
serial port, an USB<->serial converter chip or over an TCP socket.
This would allow use to reuse a simple "serialprog" external
programmer module for any serial programming devices which some of us
might make. That would allow eg. to support my device, but because
that is propably an one-off device (it's cheap only because the base
board was free for me) make the protocol usable with other possible
devices too.

My suggestion would be a simple protocol in wich "calls" are the
sending of a lenght word + function byte + parameters. The device
would return with support byte + optional return value.
eg in theory a read cycle:
PC: 0x04 0x00 0x00 0xAA 0xBB 0xCC
----   16-bit little endian lenght (of bytes after it) + function
number 0 (read byte) + 24-bit address
then device would return eg:
DEV: 0xAA 0xBB
0xAA = I support this function, 0xBB = data returned
or
DEV: 0x55
= I dont support this function.

The values i picked are pretty much arbitary, but the idea is that
different devices could support different sets of functions and could
skip over not-supported functions in the data stream, just reporting
that they dont support it. The scheme would allow upto 256 different
functions with arbitary parameters (per-function). I chose 24-bit
addresses as i havent heard of a bios flash chip that's even near
16MiB, and because we are tight on space in the protocol.

I might be into implementing this all, but it will take some time, and
i would like to get it right so that it's of best possible use for
all. Any input is appreciated.

-- 
urjaman