On Mon, 23 Sept 2024 at 21:30, Erez <erezgeva2@xxxxxxxxx> wrote: > > On Mon, 23 Sept 2024 at 19:53, Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: > > > > > > > > On 9/23/24 3:51 PM, Erez wrote: > > > On Mon, 23 Sept 2024 at 16:18, Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: > > > > cut > > > > >>> After reading a lot of Mactronix datasheets, I suggest also reading > > >>> all SFDP to all Mactronix chips. > > >> > > >> Why? It seems too invasive. Generally it is not recommended to issue > > >> unsupported commands to flashes. Change just the flash that you use and > > >> can test. > > > > > > It is not, All Mactronix chips in the last 15 years have SFDP. > > > > This is false. I worked with an octal macronix flash that didn't define > > SFDP tables, mx66something. > > I did not use the mx66XXX. Is it an SPI-NOR? > I would guess that mx66something you use is already obsolete. > Or marked by Mactronix as 'not recommended for new HW'. > It might be used by a big customer using the HW for a long time. > > > > > > > The chips in the manufacturer compatibility table are all obsolete. > > > Mactronix reuse the JEDEC IDs. There is no point pretending these are > > > the same chips. > > > > > > > If macronix doesn't care about backward compatibility, we/I do, and we > > can't break it. > > As I said, I do not ask you to do that. > > I do not represent Macronix, so I can not speak in their name. > My conclusions are based on examining their datasheet. > I did ask their technical representor. > The only straight answer I got from the technical support is > that you can not derive OTP configuration based on JEDEC ID/SFDP, > and you must know what chip you use. > > > > > >> cut > > >> > > >>>> Which flash do you have at hand, both, none, just one of them? > > >>> > > >>> When I started working on the OTP code, I used MX25L12833F. > > >>> But later I left the company. > > >>> So I use my beaglebone black and connect it to a MX25L3233F. > > >> > > >> I understand mx25l12805d and mx25l12833f share the same ID. How is > > >> mx25l3233f related, does it share the same ID as the previous two? > > > > > > They are not. I just replaced the company hardware with a different one. > > > You ask me to report the hardware I use for testing. > > > > So MX25L3233F does not share the same ID as MX25L12833F and mx25l12805d? > > Then why do we talk about ID reuse? > > I replaced the hardware I use. > Most of the reused IDs are of old chips, usually obsolete, not selled > or not recommended for new HW. > So the chance to use 2 new chips with the same ID is limited. > > I respect the fact you want to keep backward compatibility. > I just extend the approach to OTP parameters. > If an old chip with the same JEDEC ID uses different OTP parameters. > We will break backward compatibility with this old chip. > > > > > > > The patch covers the one I use with beaglebone black. > > > I just mentioned the OTP callbacks are per manufacturer. > > > But if a new chip in the future would require different callbacks, > > > then just add them. > > > My patch is using a single chip, the one I send the testing with. > > > beaglebone black + MX25L3233F. > > > > Sounds good. > > + > > > > > cut > > > > >> I said new compatibility will be introduced as a last resort only if we > > >> can't differentiate the flashes at run-time. You haven't proved me yet > > >> that this is the case. > > > > > > Then you do not read my explanation. > > > > What explanation? I've read your cover letter, commit message and I > > didn't understood what you're trying to achieve. > > This is on me. > I'll try harder with the cover letter. > I apologize. > > > > > > Do you wish me to send the Macronix datasheet of the 4 chips? > > > > No, I need just a paragraph where you explain what are the challenges > > and how you want to address them. > > + > > I try to explain that we can not based on JEDEC ID + SFDP to figure > out the correct OTP parameters. > This is also the only straight answer from Maxtronix I got. > > > > > > > > >> > > >>> You ask if it is possible to deduce it from JEDEC ID and SFDP, > > >>> I answer that this is not possible, at least in some cases.. > > >> > > >> I'm interested just about your case, not all the possible cases. > > > > > > Actually it is the MX25L3233F and its previous chips. > > > > Which previous chips? Do you have any such chip at hand? If not, why are > > we talking about collisions? > > JEDEC ID 0xc22016 > MX25L3205D - No SFDP, 2 OTP regions of 128-bit, 384-bit, Status:End of Life, > Recommended Product MX25L3206E > MX25L3206E - support SFDP, 2 OTP regions of 128-bit, 384-bit, Status: > Not recommend for new design Recommended Product MX25L3233F > MX25L3233F - support SFDP, 1 OTP region of 4096-bit, Status Production > > JEDEC ID 0xc22017 > MX25L6405D - No SFDP, 2 OTP regions of 128-bit, 384-bit, Status: End > of Life, recommend Product MX25L6406E. > MX25L6406E - support SFDP, 2 OTP regions of 128-bit, 384-bit, > Status:Not recommended for new design, > Recommended Product MX25L6433F. > MX25L6433F - support SFDP, 2 OTP regions of 4096-bit, 4096-bit, Status > Production. > > JEDEC ID 0xc22015 > MX25L1606E - support SFDP, 2 OTP regions of 128-bit, 384-bit,Status: > Not recommend for new design, > Recommended Product MX25V16066 > MX25V16066 - support SFDP, No OTP. Status Production. > > The older chips with the same JEDEC IDs are at end of life or not > commended for new design. > But if we talk about backward compatibility, we can have them on old Hardware. > > I think that I miss a chip in the list, I remember finding 4 chips > with the same JEDEC ID. > > > > > > Anyway, I will not submit a broken solution. > > > Whether you like the idea or not. > > > > > > > Fine by me. > > + > > > > > cut > > > > >>>>> I told you we can not "guess" OTP settings based on JEDEC ID and SFDP existence. > > >>>> > > >>>> When? And more importantly, why? > > >>> > > >>> I send you example of 3/4 chips that using JEDEC ID and SFDP existence > > >>> is not enough. > > >> > > >> Why? Do they have the exact SFDP tables? Prove me, drop them all. > > >> Any bit that differs in the SFDP tables is enough to differentiate the > > >> flavors of flashes. Vendor tables included ;) > > > > > > Because the SFDP is not related to OTP in any way. > > > You are planning to decide OTP parameters on non relevant information. > > > If you wish to implement such a broken feature, you are welcomed. > > > I'll pass. > > > > Ideally we have a single jedec,spi-nor compatible. If there are flash ID > > collisions we try very hard to differentiate the flashes at run-time. > > New compatibles are introduced only if we can't differentiate the flavor > > at runtime (be it by parsing SFDP or some other way). > > > > All I say is that it is a dangerous approach to deduce in this way. > Macronix does not care about breaking, they might introduce new chips > with different SFDP. > They usually do not sell new chips with the same JEDEC IDs. but apart > from that, we can not rely on any assumption. > > I can understand if you say that you do not wish to go into this mess. > But indirect probing based on JEDEC ID + SFDP is a risk, I don't think > we should take with Macronix. > > > > cut > > > > >>>> And I think I already said that you can differentiate between the two > > >>>> based on SFDP presence. mx25l12833f has SFDP, thus when SFDP present use > > >>>> the mx25l12833f-OTP configuration. When SFDP is not presence one may add > > >>>> support for the mx25l12805d-OTP configuration. > > >>> > > >>> No, we have 3 chips. > > >>> 2 are using the same JEDEC ID and both using SFDP, yet they use a different OTP. > > >> > > >> Which ones are these? > > >> > > >> I guess mx25l12805d is non-SFDP. Then mx25l12833f and mx25l3233f define > > >> some SFDP tables. Do mx25l12833f and mx25l3233f have the same OTP > > >> organization? > > > > > > No, that is the point. > > > > > ? Do you care to explain? > > The point is that you can not predict OTP based on JEDEC ID + SFDP. > It seems as if Macronix does the OTP in parallel. > See the list above. > > > > > cut > > > > > > > >>> > > >>>> > > >>>> Is there any case that I miss? > > >>> > > >>> According to your reply, I would say pretty much most. > > >> > > >> This is again inappropriate ... I will read your next email as well, but > > >> I'm not going to tolerate such replies anymore. > > > > > > I agree on this one. > > > Seems you are looking for something I do not agree on. > > > > Michael disagrees with OTP being specified in DT too. We both already > > suggested how to deal with flash ID collisions but you keep ignoring us ... > > I apologize, but I do not insist on DT. > Any solution that configures OTP regardless of JEDEC ID + SFDP is OK by me, > I am open to testing and submit a patch accordingly. Just a thought. What if we put a JEDEC ID + SFDP Macronix OTP probing code under a kernel configuration with a poorer warning? Erez > > > > > > > This is not because I oppose probing, > > > this is because you ask for indirect probing, against Macronix own > > > recommendation. > > > > What did macronix exactly recommend? Did they say that we shouldn't > > interrogate the SFDP data in order to differentiate the flashes at > > run-time? If yes, why is that? > > > I forward the reply from Holger Schulze, Field Application Engineer, > Macronix Europe N.V. I received on the 3 Jul. > > I ask: > "But the OTP setting is not in the SFDP. > How can we know which OTP size and number of regions to set?" > > And the reply: > "You are correct, the OTP setting is not defined in the JEDEC spec for > the SFDP table. The only way is to refer to the data sheet." > > Thanks for your feedback > Erez Geva
