Message-ID: <CANeKEMNdGvteumpvLHhDoiVoZwPJ4iOs+Ej8KDoXR9-Vz0-rvQ@mail.gmail.com>
Date: Mon, 23 Sep 2024 21:30:41 +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 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.


>
> > 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