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

[Miquel Raynal <miquel.raynal@bootlin.com>]

On 20/10/2024 at 21:27:18 +08, Sky Huang <SkyLake.Huang@mediatek.com> wrote:

> 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://github.com/mtk-openwrt/
> 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. As
another example, there is no read retry information. Nor anything about
the fact that the on-die ECC engine might not be disabled.

Overall I think this is an interesting initiative but I would like it to
be more advanced. Is there a plan on getting this standardized through
eg. a JEDEC spec?

Thanks,
Miquèl