mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

[Christian Eggers]

I try to use a Foresee FSNS8A002G SLC flash chip on an i.MX6 GPMI controller:

https://www.lcsc.com/datasheet/C5126835.pdf

The kernel output looks promising, but one line looks suspicious:

...
nand: device found, Manufacturer ID: 0xcd, Chip ID: 0xda
nand: Foresee FSNS8A002G
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
nand: SDR timing mode 4 not acknowledged by the NAND chip
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
3 fixed-partitions partitions found on MTD device gpmi-nand
...

According to the documentation of "Read Parameter Page", byte 129-130, 
SDR modes 0 to 5 should be supported (page 19 on the data sheet).
But the documentation of the GET_FEATURE/SET_FEATURE operation misses
the "Timing mode" register (data sheet, page 24).

I saw that there is a quirk for some Macronix chips which also seem
not to support getting/setting the timing mode (but declaring them
in the parameter page).

My main question is whether this is "normal variation within the flash
market" or a serious issue. In contrast to another device I currently
use, the Foresee chip also doesn't support "cached" operations. Is there
much value writing a fix for Timing Mode issue, or should I better
use another flash device?

regards,
Christian

Re: mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

[Miquel Raynal]

Hi Christian,

On 18/08/2025 at 19:02:49 +02, Christian Eggers <ceggers@arri.de> wrote:

> I try to use a Foresee FSNS8A002G SLC flash chip on an i.MX6 GPMI controller:
>
> https://www.lcsc.com/datasheet/C5126835.pdf
>
> The kernel output looks promising, but one line looks suspicious:
>
> ...
> nand: device found, Manufacturer ID: 0xcd, Chip ID: 0xda
> nand: Foresee FSNS8A002G
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> nand: SDR timing mode 4 not acknowledged by the NAND chip
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Bad block table found at page 131008, version 0x01
> Bad block table found at page 130944, version 0x01
> 3 fixed-partitions partitions found on MTD device gpmi-nand
> ...
>
> According to the documentation of "Read Parameter Page", byte 129-130, 
> SDR modes 0 to 5 should be supported (page 19 on the data sheet).
> But the documentation of the GET_FEATURE/SET_FEATURE operation misses
> the "Timing mode" register (data sheet, page 24).
>
> I saw that there is a quirk for some Macronix chips which also seem
> not to support getting/setting the timing mode (but declaring them
> in the parameter page).

Unfortunately, it happens that sometimes flash vendor mess up parameter
pages, so either the flash supports mode 5 and it is lying to you (you
can test it and add a quirk) or the flash does not because this batch
could not stand a faster rate (?).

> My main question is whether this is "normal variation within the flash
> market" or a serious issue. In contrast to another device I currently
> use, the Foresee chip also doesn't support "cached" operations. Is there
> much value writing a fix for Timing Mode issue, or should I better
> use another flash device?

I cannot tell for sure, I hope it is rare enough but we've already seen
variations between identical devices with the same ID... So it is up to
you to talk to your NAND vendor in order to know whether there's been a
change in their line or if this chip is special and decide what's
best. If you think a quirk is relevant, don't hesitate to submit that
(and yes, the Macronix NAND flash driver gives you an example of how to
do that).

Thanks,
Miquèl

Re: mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

[Christian Eggers]

Hi Miquel,

On Sunday, 24 August 2025, 18:37:06 CEST, Miquel Raynal wrote:
> Hi Christian,
> 
> On 18/08/2025 at 19:02:49 +02, Christian Eggers <ceggers@arri.de> wrote:
> 
> > I try to use a Foresee FSNS8A002G SLC flash chip on an i.MX6 GPMI controller:
> >
> > https://www.lcsc.com/datasheet/C5126835.pdf
> >
> > The kernel output looks promising, but one line looks suspicious:
> >
> > ...
> > nand: device found, Manufacturer ID: 0xcd, Chip ID: 0xda
> > nand: Foresee FSNS8A002G
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > nand: SDR timing mode 4 not acknowledged by the NAND chip
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Bad block table found at page 131008, version 0x01
> > Bad block table found at page 130944, version 0x01
> > 3 fixed-partitions partitions found on MTD device gpmi-nand
> > ...
> >
> > According to the documentation of "Read Parameter Page", byte 129-130, 
> > SDR modes 0 to 5 should be supported (page 19 on the data sheet).
> > But the documentation of the GET_FEATURE/SET_FEATURE operation misses
> > the "Timing mode" register (data sheet, page 24).
> >
> > I saw that there is a quirk for some Macronix chips which also seem
> > not to support getting/setting the timing mode (but declaring them
> > in the parameter page).
> 
> Unfortunately, it happens that sometimes flash vendor mess up parameter
> pages, so either the flash supports mode 5 and it is lying to you (you
> can test it and add a quirk) or the flash does not because this batch
> could not stand a faster rate (?).

What does "lying" in this context mean? The message 
"nand: SDR timing mode 4 not acknowledged by the NAND chip"
implies to me, that the flash device doesn't respond to the mode setting
command. I see 2 possible reasons:
1. The mode setting command is not supported (at least it isn't mentioned
in the data sheet).
2. The selected mode is too fast for the flash/PCB, so the response from
the flash is not correct received by the CPU.

Would it make sense, trying to reapply the current mode (0) first in order
to confirm that the flash supports the mode setting opcode at all?

> > My main question is whether this is "normal variation within the flash
> > market" or a serious issue. In contrast to another device I currently
> > use, the Foresee chip also doesn't support "cached" operations. Is there
> > much value writing a fix for Timing Mode issue, or should I better
> > use another flash device?
> 
> I cannot tell for sure, I hope it is rare enough but we've already seen
> variations between identical devices with the same ID... So it is up to
> you to talk to your NAND vendor in order to know whether there's been a
> change in their line or if this chip is special and decide what's
> best. If you think a quirk is relevant, don't hesitate to submit that
> (and yes, the Macronix NAND flash driver gives you an example of how to
> do that).

I am still waiting for the response of the manufacturer...

> 
> Thanks,
> Miquèl
> 

regards,
Christian

Re: mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

[Miquel Raynal]

Hi Christian,

On 28/08/2025 at 07:24:48 +02, Christian Eggers <ceggers@arri.de> wrote:

> Hi Miquel,
>
> On Sunday, 24 August 2025, 18:37:06 CEST, Miquel Raynal wrote:
>> Hi Christian,
>> 
>
> _______________________________________________________ ​​​​   
> Christian   Eggers     
> Software Engineer     
> ​     
> ARRI     
> Arnold & Richter Cine Technik GmbH & Co. Betriebs KG      
> Arriweg 17 ,  83071   Stephanskirchen     
> www.arri.com      
> * +49 8036 3009-3118      
>        
>        
> * CEggers@arri.de      
> ​   
> ALEXA 35 XTREME  
>   
> Arnold & Richter Cine Technik GmbH & Co. Betriebs KG   
> Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRA 57918   
> Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH   
> Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRB 54477   
> Geschäftsführer: David Bermbach, Wolfgang Börsig, Christian Richter   
> ​   
> *
> *
> ALEXA 35 XTREME
>> On 18/08/2025 at 19:02:49 +02, Christian Eggers <ceggers@arri.de> wrote:
>> 
>> > I try to use a Foresee FSNS8A002G SLC flash chip on an i.MX6 GPMI controller:
>> >
>> > https://www.lcsc.com/datasheet/C5126835.pdf
>> >
>> > The kernel output looks promising, but one line looks suspicious:
>> >
>> > ...
>> > nand: device found, Manufacturer ID: 0xcd, Chip ID: 0xda
>> > nand: Foresee FSNS8A002G
>> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> > nand: SDR timing mode 4 not acknowledged by the NAND chip
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > Bad block table found at page 131008, version 0x01
>> > Bad block table found at page 130944, version 0x01
>> > 3 fixed-partitions partitions found on MTD device gpmi-nand
>> > ...
>> >
>> > According to the documentation of "Read Parameter Page", byte 129-130, 
>> > SDR modes 0 to 5 should be supported (page 19 on the data sheet).
>> > But the documentation of the GET_FEATURE/SET_FEATURE operation misses
>> > the "Timing mode" register (data sheet, page 24).
>> >
>> > I saw that there is a quirk for some Macronix chips which also seem
>> > not to support getting/setting the timing mode (but declaring them
>> > in the parameter page).
>> 
>> Unfortunately, it happens that sometimes flash vendor mess up parameter
>> pages, so either the flash supports mode 5 and it is lying to you (you
>> can test it and add a quirk) or the flash does not because this batch
>> could not stand a faster rate (?).
>
> What does "lying" in this context mean? The message 
> "nand: SDR timing mode 4 not acknowledged by the NAND chip"
> implies to me, that the flash device doesn't respond to the mode setting
> command. I see 2 possible reasons:
> 1. The mode setting command is not supported (at least it isn't mentioned
> in the data sheet).

Setting a mode requires:
- set_features, to change the value
- get_features, to verify the value has been changed

Normally device which support the former support the latter, but
sometimes they do not. Just get rid of the check manually and make a
test, if that works, the chip is working just fine and you must flag it
as unable to perform a get_features(timings).

See:
https://elixir.bootlin.com/linux/v6.16.3/source/drivers/mtd/nand/raw/nand_macronix.c#L186
(you would only need the get_features() part of this quirk).

> 2. The selected mode is too fast for the flash/PCB, so the response from
> the flash is not correct received by the CPU.

I don't believe so.

>
> Would it make sense, trying to reapply the current mode (0) first in order
> to confirm that the flash supports the mode setting opcode at all?

Commenting out the check and using the chip at this speed sounds more
relevant IMO.

Thanks,
Miquèl