Hi Urja,
Urja Rannikko wrote:
a way for external programmers to provide alternatives to the normal flash chip functions like probe_jedec, read_memmapped, write_jedec, etc.
..
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
I think these two issues go hand in hand. You have the right idea about how this should work to be efficient. A similar scheme was discussed around the Windows flashrom GSoC project, where the "external serial programmer" would have been a Windows kernel driver.
The conclusion back then was that while it would be a great solution it was maybe not feasible for the summer project, so another solution was implemented.
Some of our ramblings back then are probably still good, and some are no longer useful. Two links to the archive for some of the discussion but there might be more:
http://www.coreboot.org/pipermail/coreboot/2007-April/020206.html http://www.coreboot.org/pipermail/coreboot/2007-May/020488.html
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.
I think there are two parts to it. One is about the flashrom data model, which has been expanded a little lately but really needs to be very different. The timing properties you mention are required for some chips and other chip types have other required property sets.
The challenge here is to create a complete data model.
The second part is to communicate that data from flashrom to satellite entities which all implement the same state machine.
The challenge here is to create a state machine which works for abstracting all the different ways we want to reach flash chips.
//Peter