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

[Miquel Raynal]

On 20/11/2024 at 07:24:28 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang at mediatek.com> wrote:

> 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 at mediatek.com>
>> wrote:
>> 
>> > From: "Sky Huang" <skylake.huang at 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).

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

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

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

Thanks,
Miquèl