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.

Signed-off-by: Sky Huang <skylake.huang@mediatek.com>
---
Sky Huang (4):
  mtd: nand: Create param.c to do CRC check and bitwise majority for
    Parameter & CASN page
  include: mtd: Add CASN page definition and related structs.
  include: mtd: spinand: Add CASN page related macros and flags.
  mtd: nand: spi: Add CASN page support

 drivers/mtd/nand/Makefile        |   2 +-
 drivers/mtd/nand/param.c         |  52 +++
 drivers/mtd/nand/raw/nand_onfi.c |  43 +-
 drivers/mtd/nand/spi/core.c      | 741 ++++++++++++++++++++++++++++++-
 include/linux/mtd/casn.h         | 191 ++++++++
 include/linux/mtd/param.h        |  20 +
 include/linux/mtd/spinand.h      | 100 ++++-
 7 files changed, 1094 insertions(+), 55 deletions(-)
 create mode 100644 drivers/mtd/nand/param.c
 create mode 100644 include/linux/mtd/casn.h
 create mode 100644 include/linux/mtd/param.h

-- 
2.45.2

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

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

On 20/11/2024 at 07:24:28 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@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@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?

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

On Sun, 2024-10-20 at 21:27 +0800, Sky Huang 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:
> 
gentle ping

BRs,
Sky

Hello,

On 28/10/2024 at 15:25:59 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.com> wrote:

> On Sun, 2024-10-20 at 21:27 +0800, Sky Huang 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:
>> 
> gentle ping

I had a look at it, it is interesting but I have some questions and need
to come back to it. Unfortunately I was a bit busy these days. Sorry for
the delay.

Thanks,
Miquèl