| Message ID | 20241020132722.20565-1-SkyLake.Huang@mediatek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mtd: nand: spi: Add CASN page support | expand |
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
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