Re: [RFC PATCH nand/next 0/4] mtd: nand: spi: Add CASN page support

On 20/11/2024 at 07:24:28 GMT, SkyLake Huang (黃啟澤) [off-list ref] wrote:

On Mon, 2024-11-18 at 11:53 +0100, Miquel Raynal wrote:

quoted

External email : Please do not click links or open attachments until
you have verified the sender or the content.


On 20/10/2024 at 21:27:18 +08, Sky Huang [off-list ref]
wrote:

quoted

From: "Sky Huang" <skylake.huang@mediatek.com>

Hi, this is Qi-Ze Huang(Sky Huang) from MediaTek. On our router
platforms
chips, we have to quality lots of SPI-NAND devices and are eager
for
a standard so that we don't need to maintain trivial flash ID table
anymore. I also noticed a talk in 2019 Embedded Linux Conference,
Memory Technology Devices: what's new, which mentioned "ONFI for
SPI-NANDs? Maybe, maybe not".

So earlier this year, I proposed a bold idea, CASN page (Common
Attributes
for SPI-NAND). I worked together with top 3 SPI-NAND market share
flash
vendors and other vendors to integrate CASN page on their SPI-NAND
devices
including but not limited to:
[ESMT]
F50L1G41LB
F50L2G41KA

[Etron]
EM73C044VCF-H
EM73D044VCO-H
EM73E044VCE-H
EM73F044VCA-H

[GigaDevice]
GD5F1GM7UE
GD5F1GQ5UEYIG
GD5F2GM7UE
GD5F2GQ5UEYIG
GD5F4GM8UE
GD5F4GQ6UEYIG

[Macronix (MXIC)]
MX35LF1GE4ABZ4IG

[Winbond]
W25N01GV
W25N01KV
W25N02KV
W25N04KV

A document of CASN is hosted on github(
https://urldefense.com/v3/__https://github.com/mtk-openwrt/__;!!CTRNKA9wMg0ARbw!j_TES7dJ_An-9wtyQqWgGBE9ovPnUA-tDNlZ-pGpUdYv4gphzW4v54Fal8i_nLwSmPAzK9ApgSBG1XQ_mREdTS0ZwrBWRA$
doc/blob/main/CASN%20Page%20Introduction.pdf) So I'll try to keep
it
simple here.

With CASN page, we don't need to maintain SPI-NAND flash ID table
anymore.
Currently, it's integrated in 3.3V SPI-NANDs of small density and
it's not
JEDEC standard yet. But it should be able to handle 1.8V and can be
easily
integrated by flash vendors.

I believe this idea and implementation have room for improvement.
Hope to
hear you open source community's comments soon.

I think this is a bright initiative. I'd welcome some standardisation
on
the discovery indeed.

But to be really useful, I believe this table must be really
complete,
otherwise ID's will remain. For instance SDR/DDR modes are not
entirely
defined as we already have mixed modes. There is also no information
about what maximum frequencies can be used with each operation. 

Maximum frequencies are limited by SPI controller's max freq now, I
guess?

No, this is just the PCB/controller limitation. But there are chips with
frequency limitations depending on the type of command (see for instance
Winbond AC timings tables for DDR capable devices).

quoted

As
another example, there is no read retry information.

What will retry information look like?

Number of retry modes, how to enable retry mode (which is maybe
standardized per manufacturer, in this case we can just get the right
hook from the manufacturer information, but otherwise if there are
differences inside production lines from a single manufacturer, we'll
still need either a table or some extension of CASN.

quoted

Nor anything about
the fact that the on-die ECC engine might not be disabled.

As far as I know, only SkyHigh's SPI-NAND's ECC engine can't be
disabled since its on-die ECC engine contains randomizer.

Randomizer and ECC engine are two different things, there are many raw
NAND controllers with a programmable ECC engine *and* randomizer. They
just choose to hide the controls.

Today it is SkyHigh. What about tomorrow?

There are some reserved fields. We can handle above requirements in
CASN V1.2 or V2. But may I ask what's the purpose of involving above
information in CASN? Are there any practical application scenarios?

You claim you want to replace the ID tables. These tables are filled
with all the relevant data to make the chips supported in Linux. If one
of these fields is missing from CASN, it means we need to keep the
tables. So it kind of defeats the CASN purpose. Yes we may have dynamic
vendor hooks to adapt these parameters "on the fly", but we still need
internal tables for that.

quoted

Overall I think this is an interesting initiative but I would like it
to
be more advanced.

Agree.

quoted

Is there a plan on getting this standardized through
eg. a JEDEC spec?

Thanks,
Miquèl

Yes. We're working on it. But it will take some time. Your opinions
mean a lot to CASN page standardisation.

Thanks,
Miquèl