Message-ID: <CANeKEMOH=CTC9GY5LFLj0mx2OoytR-9bOsFM7edDQ6-e=CaNgw@mail.gmail.com>
Date: Mon, 23 Sep 2024 23:41:13 +0200
From: Erez <erezgeva2@...il.com>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Erez Geva <erezgeva@...ime.org>, linux-mtd@...ts.infradead.org, 
	Pratyush Yadav <pratyush@...nel.org>, Michael Walle <mwalle@...nel.org>, linux-kernel@...r.kernel.org, 
	Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>, 
	Vignesh Raghavendra <vigneshr@...com>, devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags

On Mon, 23 Sept 2024 at 21:30, Erez <erezgeva2@...il.com> wrote:
>
> On Mon, 23 Sept 2024 at 19:53, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> >
> >
> >
> > On 9/23/24 3:51 PM, Erez wrote:
> > > On Mon, 23 Sept 2024 at 16:18, Tudor Ambarus <tudor.ambarus@...aro.org> 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

Powered by blists - more mailing lists