From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Robert Jarzmik <robert.jarzmik@free.fr>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: pxa3xx_nand times out in 4.14 with JFFS2
Date: Sun, 17 Dec 2017 19:07:46 +0100 [thread overview]
Message-ID: <20171217190746.2a61232c@bbrezillon> (raw)
In-Reply-To: <20171217162342.GA1833@1wt.eu>
On Sun, 17 Dec 2017 17:23:42 +0100
Willy Tarreau <w@1wt.eu> wrote:
> On Sun, Dec 17, 2017 at 12:53:36PM -0300, Ezequiel Garcia wrote:
> > If not too much to ask, this is the test that I believe is needed.
> > You seem to have a setup ready, hence why I'm asking you, if
> > possible, to give it a shot.
> >
> > (1) Scrub the BBT from the NAND. Or scrub the whole NAND.
> > You cannot do this from the kernel, it needs to be done from the bootloader.
> >
> > (2) Mark a couple blocks as bad using the OOB -- AFAICR, there
> > was a command to do this in the bootloader.
> >
> > (3) Boot, let Linux create the BBT and see if it catches the bad blocks.
>
> Are the current boot loaders safe regarding the scrub operation ? I'm
> asking because that's how I bricked my mirabox a few years ago when
> trying to mark a bad block from u-boot :-/ If someone has a good
> knowledge of these commands to limit the risk and helps me only playing
> with a small part at the end of the flash (or in the unused area) I'd
> prefer it :-)
>
> > This would guarantee that devices with factory bad blocks,
> > (and no BBT), would be OK with this patch.
>
> I see. I'm fine with trying provided I have reasonably good assurance
> that I won't have to go through the kwboot pain again :-/
There's a easy test you can do without scrubing the NAND:
1/ comment the nand-on-flash-bbt property in your DT (this will trigger
a full scan)
2/ from u-boot (before booting the kernel), erase a block that you know
contains nothing important
3/ during the kernel scan, make sure this block is not reported as bad
WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: pxa3xx_nand times out in 4.14 with JFFS2
Date: Sun, 17 Dec 2017 19:07:46 +0100 [thread overview]
Message-ID: <20171217190746.2a61232c@bbrezillon> (raw)
In-Reply-To: <20171217162342.GA1833@1wt.eu>
On Sun, 17 Dec 2017 17:23:42 +0100
Willy Tarreau <w@1wt.eu> wrote:
> On Sun, Dec 17, 2017 at 12:53:36PM -0300, Ezequiel Garcia wrote:
> > If not too much to ask, this is the test that I believe is needed.
> > You seem to have a setup ready, hence why I'm asking you, if
> > possible, to give it a shot.
> >
> > (1) Scrub the BBT from the NAND. Or scrub the whole NAND.
> > You cannot do this from the kernel, it needs to be done from the bootloader.
> >
> > (2) Mark a couple blocks as bad using the OOB -- AFAICR, there
> > was a command to do this in the bootloader.
> >
> > (3) Boot, let Linux create the BBT and see if it catches the bad blocks.
>
> Are the current boot loaders safe regarding the scrub operation ? I'm
> asking because that's how I bricked my mirabox a few years ago when
> trying to mark a bad block from u-boot :-/ If someone has a good
> knowledge of these commands to limit the risk and helps me only playing
> with a small part at the end of the flash (or in the unused area) I'd
> prefer it :-)
>
> > This would guarantee that devices with factory bad blocks,
> > (and no BBT), would be OK with this patch.
>
> I see. I'm fine with trying provided I have reasonably good assurance
> that I won't have to go through the kwboot pain again :-/
There's a easy test you can do without scrubing the NAND:
1/ comment the nand-on-flash-bbt property in your DT (this will trigger
a full scan)
2/ from u-boot (before booting the kernel), erase a block that you know
contains nothing important
3/ during the kernel scan, make sure this block is not reported as bad
next prev parent reply other threads:[~2017-12-17 18:07 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-17 12:05 pxa3xx_nand times out in 4.14 with JFFS2 Willy Tarreau
2017-12-17 12:05 ` Willy Tarreau
2017-12-17 12:33 ` Boris Brezillon
2017-12-17 12:33 ` Boris Brezillon
2017-12-17 13:17 ` Willy Tarreau
2017-12-17 13:17 ` Willy Tarreau
2017-12-17 14:25 ` Ezequiel Garcia
2017-12-17 14:25 ` Ezequiel Garcia
2017-12-17 14:27 ` Ezequiel Garcia
2017-12-17 14:27 ` Ezequiel Garcia
2017-12-17 14:53 ` Boris Brezillon
2017-12-17 14:53 ` Boris Brezillon
2017-12-17 15:00 ` Willy Tarreau
2017-12-17 15:00 ` Willy Tarreau
2017-12-17 15:09 ` Willy Tarreau
2017-12-17 15:09 ` Willy Tarreau
2017-12-17 15:53 ` Ezequiel Garcia
2017-12-17 15:53 ` Ezequiel Garcia
2017-12-17 16:23 ` Willy Tarreau
2017-12-17 16:23 ` Willy Tarreau
2017-12-17 18:07 ` Boris Brezillon [this message]
2017-12-17 18:07 ` Boris Brezillon
2017-12-17 19:00 ` Willy Tarreau
2017-12-17 19:00 ` Willy Tarreau
2017-12-17 21:01 ` Ezequiel Garcia
2017-12-17 21:01 ` Ezequiel Garcia
2017-12-17 21:16 ` Willy Tarreau
2017-12-17 21:16 ` Willy Tarreau
2017-12-17 21:26 ` Boris Brezillon
2017-12-17 21:26 ` Boris Brezillon
2017-12-17 21:46 ` Miquel RAYNAL
2017-12-17 21:46 ` Miquel RAYNAL
2017-12-18 6:37 ` Willy Tarreau
2017-12-18 6:37 ` Willy Tarreau
2017-12-18 7:06 ` Willy Tarreau
2017-12-18 7:06 ` Willy Tarreau
2017-12-18 10:22 ` Miquel RAYNAL
2017-12-18 10:22 ` Miquel RAYNAL
2017-12-18 21:52 ` Willy Tarreau
2017-12-18 21:52 ` Willy Tarreau
2017-12-19 0:13 ` Miquel RAYNAL
2017-12-19 0:13 ` Miquel RAYNAL
2017-12-19 5:34 ` Willy Tarreau
2017-12-19 5:34 ` Willy Tarreau
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=20171217190746.2a61232c@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=robert.jarzmik@free.fr \
--cc=w@1wt.eu \
/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.