linux-kernel - Re: mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87o6rz6a8t.fsf@bootlin.com>
Date: Thu, 28 Aug 2025 11:55:46 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Christian Eggers <ceggers@...i.de>
Cc: Richard Weinberger <richard@....at>,  <linux-mtd@...ts.infradead.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: mtd: rawnand: Inconsistent parameter page on Foresee FSNS8A002G ?

Hi Christian,

On 28/08/2025 at 07:24:48 +02, Christian Eggers <ceggers@...i.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@...i.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@...i.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