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.
next 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