Angel Pons <th3fan...@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. _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
