public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Steve deRosier <derosier@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Tobi Wulff <Tobi.Wulff@alliedtelesis.co.nz>
Subject: NAND ecc-strength (was Re: NAND timeout issues with blank chip and Marvell NFC)
Date: Sun, 29 Apr 2018 22:17:08 +0000	[thread overview]
Message-ID: <2847aa9260084a6da170afe239a33d36@svr-chch-ex1.atlnz.lc> (raw)

Hi Boris & all,

Permit me a slight tangent.

On 27/04/18 18:16, Boris Brezillon wrote:
>> The one problem it does have in this configuration is the familiar
>> "nand: WARNING: pxa3xx_nand-0: the ECC used on your system is too weak
>> compared to the one required by the NAND chip". From what I read in the
>> Marvell datasheet even though the chip requires 8-bits of ECC per 540
>> bytes of data the 16-bits per 2048 bytes of data implemented by the
>> controller should satisfy this.
 >
> No, it's not true. Well, it will work for some time, and then fail when
> too many erase cycles have been done on a block. You should always try
> to at least meet the chip requirements. Anyway, that's not really the
> issue here.
> 
>> If I set marvell,nand-keep-config or nand-ecc-strength = <8>. I get ECC
>> errors reported (probably due to the change in configuration) and
>> ultimately the mount fails "mount: mounting ubi0:user on /flash failed:
>> Invalid argument" I haven't really dug into where that's coming from.
 >
> For the ECC change, that's not surprising, since u-boot probably writes
> things in the 4bit/512 config.
> 

So this raises a bit of concern. A certain NAND flash vendor has 
released an end of life notice for some of their chips (I won't name 
them specifically because I'm not sure if there is a NDA in place). The 
suggested replacement part requires 8bit/540byte ECC whereas the old one 
required 4bit/540byte.

The first problem I face is how do we handle the possibility of having 
either chip installed. Since the current dtb has ecc-strength = <4> do 
we need the bootloader to modify this on the fly this based on some 
identifier that distinguishes old from new? Or is there some way of 
saying ecc-strength = <pick a value appropriate for the chip>.

The second problem is that, if I understand correctly, the Marvell NFCv2 
BCH implementation is always 16bit/2048bytes. So even if I get the dts 
to say the right thing the hardware based ECC will ignore it.

             reply	other threads:[~2018-04-29 22:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-29 22:17 Chris Packham [this message]
2018-04-30  6:06 ` NAND ecc-strength (was Re: NAND timeout issues with blank chip and Marvell NFC) Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2847aa9260084a6da170afe239a33d36@svr-chch-ex1.atlnz.lc \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=Tobi.Wulff@alliedtelesis.co.nz \
    --cc=boris.brezillon@bootlin.com \
    --cc=derosier@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox