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

["SkyLake Huang (黃啟澤)" <SkyLake.Huang@mediatek.com>]

On Mon, 2024-11-18 at 11:53 +0100, Miquel Raynal wrote:
> 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 <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://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?

> As
> another example, there is no read retry information.
What will retry information look like?

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

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?

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

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

BRs,
Sky