On Wed, 17 Aug 2011 00:09:02 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Stefan Tauner mentioned that we use probe methods inconsistently: Some SPI chips use RDID, some use REMS, some use RES, and then there are various variants (mostly varied response length) of those probe functions. The reason is that we originally had exactly one possible probe function per chip. With SPI chips, there are up to 5 different probe functions for the same chip, each with a different ID. Fun!
We need to revamp the probing architecture, preferably in a future-proof way.
Possible solutions:
- Handle probing like erase, i.e. an array of ID+function pairs.
way to go for now imho.
- Add n variants of each chip, one per probe function. That's what works
with the current architecture and what has been done for a few chips in the past.
easy, but super ugly.
- Something completely different which I haven't thought of.
Comments? I once had a prototype patch for the first solution, but it bitrotted and I was not happy with the design back then, but nowadays the flashrom architecture is better and this could be done in a non-ugly way.
the question is what the long-term solution will be. there was some discussion already about changing the way probing is done on the whole in flashrom. i have a vague idea of what it should look like, but this would be a major change. the general idea is to separate the probing functions more from the flash chips. to make it more clear, this could be achieved by the following changes:
- add a table with all possible probing functions and the matching buses - change the probing functions so that their reply identifies the chip (probably a byte array) in a generic way (same return type for all). - add a table to each flash chip that contains the possible probing functions together with the expected reply - change the probing infrastructure to iterate over the probing functions table and execute the probing functions that are compatible with the accessible buses. - for each valid reply we get, iterate over the flash chips (possibly by also taking the buses into account) - for each flash chip iterate over its array of probing functions and matching reply. if the reply received matches the one of the chip, add it to the list of detected chips - after all probing functions are executed and their replies are evaluated, continue as before (show the user the list of detected chips, or just continue if there is just one)
i am quite certain that something like this is a good solution for spi chips. i am also quite certain that it will be frown on and/or that it is total nonsense for non-spi chips. :)
the first solution mentioned by carl-daniel above would be a possible intermediate step, although it may be unnecessary work (changing the imho awful probing infrastructure one time now, and then a second time). but it would change the flashchips.c database into something more useful for any future improvements (like the one outlined by me).