Hi Anastasia, list, On Tue, Jul 2, 2024 at 1:01 PM Anastasia Klimchuk <a...@chromium.org> wrote: > > Greg, Angel, so great to have your thoughts on the topics! Especially > such in-depth discussion, I like it so much <3 > > Just to clarify, there are no plans to remove anything from > flashchips, and this is exactly why the topic exists (the topic being, > how to handle repeated IDs better). > I was thinking whether we can handle duplicate IDs better.
Ack. > I created new ticket for SFDP, that's a great idea > https://ticket.coreboot.org/issues/546 > Also I closed the ticket about end-of-life flag. That's the easiest > resolution for me to do. If it's not very helpful, then there is no > need to spend any more time on it. > Especially since there is a better idea (SFDP)! Ack. > Why IDs are repeating, in addition to reasons that Angel mentioned, it > seems that ID encodes some info (like memory density). So not every > hash can be a model ID. So it's even less of them available, within 4 > bytes length. I remember checking some spec (probably the JEDEC SPI standard) that described the RDID command's response bytes. The two bytes flashrom currently treats together as a single 16-bit "device ID" value actually have different meanings: one of them specifies "memory type" and the other one specifies "memory density", but I don't recall if the standard specifies the encoding. > By the way, converting flashchips to JSON is also a good idea, which > is half done. But then, the developer who did the first half, left, so > now this is waiting for someone to allocate time to finish. Oof, I'm sorry to hear that. > Another topic in the notes was splitting large flashchips file into > smaller pieces (one per manufacturer I think). Since no one commented > I assume you support the idea. Sounds good. I'd also consider splitting them by buses (it's orthogonal). As a conjurer of cursed ideas, I can think of a way to contain the bulk of the changes in reproducible commits: split off parts of the flashchips array into separate files, and `#include` said files inside the array. And since I don't trust myself explaining it, I decided to create https://review.coreboot.org/83307 to show what I mean. > I see this as the effort which is orthogonal to converting from C to > JSON, I think it can be done before or after, either way. And by the > way things are looking now, it might happen earlier. But please tell > me if you have concerns. I think it's mostly orthogonal, and I also believe that restructuring the flashchips data could make it easier to compare against SFDP information. But we'll cross the bridge when we get there (it'll be easier to decide later, with more information). > On Fri, Jun 28, 2024 at 9:27 AM Greg Troxel <g...@lexort.com> wrote: > > > > 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. > > -- > Anastasia. Best regards, Angel _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
