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. > 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. >> 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? > > 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. > 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. > >> >>> 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? > 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). 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? 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 ... > 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?
