From: Baruch Siach <baruch@tkos.co.il>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>,
linux-mtd@lists.infradead.org,
Sascha Hauer <kernel@pengutronix.de>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/4] mtd: mxc_nand: limit the size of used oob
Date: Mon, 27 Apr 2015 10:20:57 +0300 [thread overview]
Message-ID: <20150427072057.GT2258@tarshish> (raw)
In-Reply-To: <20150427071238.GE19431@pengutronix.de>
Hi Uwe,
On Mon, Apr 27, 2015 at 09:12:38AM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 27, 2015 at 07:39:06AM +0300, Baruch Siach wrote:
> > On Sun, Apr 26, 2015 at 10:07:25PM +0200, Uwe Kleine-König wrote:
> > > On Sun, Apr 26, 2015 at 11:16:49AM +0300, Baruch Siach wrote:
> > > > + /* hardware can only use 218 or 128 oob bytes for ecc */
> > > > + if (mtd->oobsize >= 218)
> > > IMHO this is the wrong check. What if your part (with 224 bytes spare)
> > > is used but the machine only uses the small layout e.g. for booting?
> > > (That would work, wouldn't it?)
> >
> > Yes, but how would I know? I am following here the assumption of get_eccsize()
> > that enables 8 bit ECC when there is enough oobsize.
> Hmm I rechecked the reference manual and found a register to specify the
> size of the spare area (I didn't notice that one before). Did you try
> what happens if you set this to 0x70 for 224 bytes oob?
Which register is that?
> Optimally this would result in the last 6 bytes being written but not
> protected by hardware ecc.
Last 6 bytes of what? AFAIK, hardware ECC does not protect oob at all.
> > > Moreover the comment is misleading as it
> > > only applies to 4K flashes. At least the driver works well with (2ki +
> > > 128) bytes pages (while there are only 64 bytes spare used?? Maybe there
> > > are still more bugs?).
> >
> > I suspect there are more bugs. A simple way to trigger the bug I encountered
> > is by doing a sub-page write, that is:
> >
> > dd if=/dev/zero bs=1024 count=1 of=/dev/mtd2
> > dd if=/dev/zero bs=1024 count=1 seek=1 of=/dev/mtd2
> >
> > and then try reading this page. You may need to dirty the (useless; random)
> > content of ecccalc to see the bug (you can conveniently use
> > mxc_nand_calculate_ecc() for that). What copy_spare() currently do (spread ECC
> > chunks evenly over oob) does not match nandv2_hw_eccoob_largepage.
> I didn't follow, but would be willing to review a fix :-)
OK. I'll try something.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
WARNING: multiple messages have this Message-ID (diff)
From: baruch@tkos.co.il (Baruch Siach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] mtd: mxc_nand: limit the size of used oob
Date: Mon, 27 Apr 2015 10:20:57 +0300 [thread overview]
Message-ID: <20150427072057.GT2258@tarshish> (raw)
In-Reply-To: <20150427071238.GE19431@pengutronix.de>
Hi Uwe,
On Mon, Apr 27, 2015 at 09:12:38AM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Apr 27, 2015 at 07:39:06AM +0300, Baruch Siach wrote:
> > On Sun, Apr 26, 2015 at 10:07:25PM +0200, Uwe Kleine-K?nig wrote:
> > > On Sun, Apr 26, 2015 at 11:16:49AM +0300, Baruch Siach wrote:
> > > > + /* hardware can only use 218 or 128 oob bytes for ecc */
> > > > + if (mtd->oobsize >= 218)
> > > IMHO this is the wrong check. What if your part (with 224 bytes spare)
> > > is used but the machine only uses the small layout e.g. for booting?
> > > (That would work, wouldn't it?)
> >
> > Yes, but how would I know? I am following here the assumption of get_eccsize()
> > that enables 8 bit ECC when there is enough oobsize.
> Hmm I rechecked the reference manual and found a register to specify the
> size of the spare area (I didn't notice that one before). Did you try
> what happens if you set this to 0x70 for 224 bytes oob?
Which register is that?
> Optimally this would result in the last 6 bytes being written but not
> protected by hardware ecc.
Last 6 bytes of what? AFAIK, hardware ECC does not protect oob at all.
> > > Moreover the comment is misleading as it
> > > only applies to 4K flashes. At least the driver works well with (2ki +
> > > 128) bytes pages (while there are only 64 bytes spare used?? Maybe there
> > > are still more bugs?).
> >
> > I suspect there are more bugs. A simple way to trigger the bug I encountered
> > is by doing a sub-page write, that is:
> >
> > dd if=/dev/zero bs=1024 count=1 of=/dev/mtd2
> > dd if=/dev/zero bs=1024 count=1 seek=1 of=/dev/mtd2
> >
> > and then try reading this page. You may need to dirty the (useless; random)
> > content of ecccalc to see the bug (you can conveniently use
> > mxc_nand_calculate_ecc() for that). What copy_spare() currently do (spread ECC
> > chunks evenly over oob) does not match nandv2_hw_eccoob_largepage.
> I didn't follow, but would be willing to review a fix :-)
OK. I'll try something.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2015-04-27 7:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-26 8:16 [PATCH 0/4] mtd: mxc_nand: fix 8 bit ECC and large oob Baruch Siach
2015-04-26 8:16 ` Baruch Siach
2015-04-26 8:16 ` [PATCH 1/4] mtd: nand: mxc_nand: cleanup copy_spare function Baruch Siach
2015-04-26 8:16 ` Baruch Siach
2015-04-26 8:16 ` [PATCH 2/4] mtd: mxc_nand: limit the size of used oob Baruch Siach
2015-04-26 8:16 ` Baruch Siach
2015-04-26 20:07 ` Uwe Kleine-König
2015-04-26 20:07 ` Uwe Kleine-König
2015-04-27 4:39 ` Baruch Siach
2015-04-27 4:39 ` Baruch Siach
2015-04-27 7:12 ` Uwe Kleine-König
2015-04-27 7:12 ` Uwe Kleine-König
2015-04-27 7:20 ` Baruch Siach [this message]
2015-04-27 7:20 ` Baruch Siach
2015-04-27 7:50 ` Uwe Kleine-König
2015-04-27 7:50 ` Uwe Kleine-König
2015-04-27 11:43 ` Baruch Siach
2015-04-27 11:43 ` Baruch Siach
2015-04-27 19:31 ` Uwe Kleine-König
2015-04-27 19:31 ` Uwe Kleine-König
2015-04-29 6:18 ` Baruch Siach
2015-04-29 6:18 ` Baruch Siach
2015-04-29 6:35 ` Uwe Kleine-König
2015-04-29 6:35 ` Uwe Kleine-König
2015-04-30 15:20 ` Fabio Estevam
2015-04-30 15:20 ` Fabio Estevam
2015-05-03 7:55 ` Baruch Siach
2015-05-03 7:55 ` Baruch Siach
2015-04-26 8:16 ` [PATCH 3/4] mtd: mxc_nand: fix truncate of unaligned oob copying Baruch Siach
2015-04-26 8:16 ` Baruch Siach
2015-04-26 19:52 ` Uwe Kleine-König
2015-04-26 19:52 ` Uwe Kleine-König
2015-04-27 4:46 ` Baruch Siach
2015-04-27 4:46 ` Baruch Siach
2015-04-27 6:56 ` Uwe Kleine-König
2015-04-27 6:56 ` Uwe Kleine-König
2015-04-26 8:16 ` [PATCH 4/4] mtd: mxc_nand: generate nand_ecclayout for 8 bit ECC Baruch Siach
2015-04-26 8:16 ` Baruch Siach
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=20150427072057.GT2258@tarshish \
--to=baruch@tkos.co.il \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=shawn.guo@linaro.org \
--cc=u.kleine-koenig@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.