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.