Angel Pons th3fanbus@gmail.com writes:
Newer chips support SFDP (Serial Flash Discoverable Parameter), a specification that allows (at least) SPI flash chips to self-document themselves to software, and that nearly all flash chips from the last decade or so support. So, I would highly recommend using SFDP to differentiate between flash chips with same ID but different capabilities, and thus rule out incompatible chip definitions. One can even use whether the probed flash chip supports SFDP to rule out entries (a flash chip that does not respond to SFDP should not be used with a chip definition of a SFDP-capable chip). Unfortunately, it looks like the flashchips database does not have a feature flag for SFDP (just a bunch of comments that may or may not be accurate).
Ah, I had no idea. I think you are wise to suggest that SFDP be used when available and for that data to be part of the info that is treated as identity.
Are there chips whose IDs have been reused that we are willing to say that essentially none of them are in service, so that flashrom can just treat any with that ID as the new version? This is a combination of "will doing this brick the old ones" and "how many are there". This is really a secondary question; the main one is how to use both.
I believe ID reusing became noticeably more common after SFDP got introduced, as SFDP provides significantly more detailed information about a flash chip's capabilities. Flash chips still have IDs because older software may rely on them. And yes, I am implying (and hereinafter explicitly stating) that flashrom is "old software": while it does incorporate SFDP support, it does not take advantage of SFDP to enhance matching against the flashchips database.
It sounds like using SFDP is the right answer then.
I don't really see "end of life" as the real issue. I see it as "chip vendor has shipped two kinds of chips with the same ID and we need to invoke some further disambiguation mechanism before we operate on it".
The fact that they did it because they stopped selling the other one, rather than that they did it because they are just confused, is not really relevant. The only thing that matters is that when flashrom reads that ID, it does not know what chip it is dealing with.
This. Even if one were to mark chip definitions for older chips as "end of life", there are more cases of ID reuse happening with *newer* chips that would not be dealt with.
IMHO, this "end of life" flag would be like applying a band-aid to to someone who lost a loved one (it does not help, and it probably makes things worse).
:-)
But sounds like we agree, even more so after you have unconfused me about SFDP.
Given that there were only two people in the meeting, it is likely that things everyone agreed with were never questioned. Fortunately, posting the meeting minutes on the mailing list brought this to the attention of a much larger audience (*waves at the reader*).
Indeed. It is a huge positive to have sent this to the list and this is a great discussion.
To me, the idea of a "flashrom revision code" sounds extremely cumbersome to maintain. Who assigns flashrom revision codes, for both existing chip definitions and new ones? Why would revision codes exist when there's chip definition names?
It was my guess at how to work around truly not being able to tell. I withdraw it in favor of SFDP.