[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAEAJfArtxcWgcjHAb__3BQxWEBgWU8uWtHGYETc-m9eUs91nA@mail.gmail.com>
Date: Sun, 17 Dec 2017 18:01:29 -0300
From: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To: Willy Tarreau <w@....eu>
Cc: Boris Brezillon <boris.brezillon@...e-electrons.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
Robert Jarzmik <robert.jarzmik@...e.fr>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: pxa3xx_nand times out in 4.14 with JFFS2
On 17 December 2017 at 16:00, Willy Tarreau <w@....eu> wrote:
> On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
>> > > 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
>
> OK so I tried and never faced any error. Thus I also attempted to mark
> a bad block in u-boot, it appeared in the bad blocks table, then I had
> to scrub the whole table to get rid of it. Each time when I booted I
> saw the message "Scanning device for bad blocks" but no error ever
> happened. So I hope it's OK.
>
Nice. Thanks a lot Willy. I think this acks Boris' patch.
--
Ezequiel GarcĂa, VanguardiaSur
www.vanguardiasur.com.ar
Powered by blists - more mailing lists