[flashrom] SPI. RDID, REMS, RES and other probe variants

[Stefan Tauner]

On Wed, 17 Aug 2011 00:09:02 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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).

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner