From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sean Nyekjaer <sean@geanix.com>
Cc: mkl@pengutronix.de, Sascha Hauer <s.hauer@pengutronix.de>,
linux-mtd@lists.infradead.org
Subject: Re: [Bug] mtd: rawnand: gpmi
Date: Thu, 19 Sep 2019 13:27:19 +0200 [thread overview]
Message-ID: <20190919132719.3ca48967@xps13> (raw)
In-Reply-To: <a4a68ef3-3f66-3e5e-b0d9-cf5d5e898b40@geanix.com>
Hi Sean,
Sean Nyekjaer <sean@geanix.com> wrote on Thu, 19 Sep 2019 13:21:56
+0200:
> On 10/09/2019 13.51, Sean Nyekjaer wrote:
> >
> >
> > On 10/09/2019 13.08, Sascha Hauer wrote:
> >> On Tue, Sep 10, 2019 at 01:00:30PM +0200, Sean Nyekjaer wrote:
> >>>
> >>>
> >>> On 10/09/2019 12.48, Sascha Hauer wrote:
> >>>> On Tue, Sep 10, 2019 at 12:18:25PM +0200, Sean Nyekjaer wrote:
> >>>>>
> >>>>>
> >>>>> On 10/09/2019 11.55, Sascha Hauer wrote:
> >>>>>>> [ 2.434057] Bad block table written to 0x00001ffc0000, version >>>>>>> 0x01
> >>>>>>> [ 2.437254] Bad block table written to 0x00001ff80000, version >>>>>>> 0x01
> >>>>>> What about this "Bad block table written" message? You should see >>>>>> this
> >>>>>> exactly once. Do you see this multiple times, especially when >>>>>> switching
> >>>>>> kernels between the good one and the bad one?
> >>>>>>
> >>>>>> Sascha
> >>>>>
> >>>>> Not exactly sure what you mean, but here is the dumps:
> >>>>>
> >>>>> Before (mtd: rawnand: gpmi: Implement exec_op)
> >>>>> [ 3.389352] Bad block table written to 0x00001ffc0000, version 0x01
> >>>>> [ 3.399019] Bad block table written to 0x00001ff80000, version 0x01
> >>>>>
> >>>>> After
> >>>>> [ 3.301096] Bad block table written to 0x00001ffc0000, version 0x01
> >>>>> [ 3.310599] Bad block table written to 0x00001ff80000, version 0x01
> >>>>
> >>>> The Bad block table is written once. When you see this message multiple
> >>>> times then this means that Linux can't read the BBT and writes it >>>> again.
> >>>> So the question is: Start the good kernel multiple times. Do you see
> >>>> this message once or on each boot? Then start the bad Kernel multiple
> >>>> times. Do you see the message once or on each boot?
> >>>>
> >>>> Sascha
> >>>>
> >>>
> >>> U-boot:
> >>> => nand erase.chip
> >>>
> >>> NAND erase.chip: device 0 whole chip
> >>> Skipping bad block at 0x0c780000
> >>> Skipping bad block at 0x18000000
> >>> Skipping bad block at 0x18040000
> >>> Skipping bad block at 0x1ff00000
> >>> Skipping bad block at 0x1ff40000
> >>> Skipping bad block at 0x1ff80000
> >>> Skipping bad block at 0x1ffc0000
> >>>
> >>> Look weird it marks the bbt location bad ?
> >>
> >> Yes, that's normal. The BBT itself is marked as bad. Otherwise the they
> >> would just be used by regular mtd users.
> >>
> >>> Or is it a uboot feature?
> >>> I have tried another board, and uboot marks the bbt location bad on >>> that as
> >>> well
> >>>
> >>> First boot:
> >>> [ 4.149870] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xdc
> >>>
> >>>
> >>> [ 4.156589] nand: Toshiba NAND 512MiB 3,3V 8-bit
> >>> [ 4.161500] nand: 512 MiB, SLC, erase size: 256 KiB, page size: >>> 4096, OOB
> >>> size: 128
> >>>
> >>> [ 4.175918] Bad block table not found for chip 0
> >>> [ 4.184059] Bad block table not found for chip 0
> >>> [ 4.188808] Scanning device for bad blocks
> >>> [ 4.690183] Bad eraseblock 798 at 0x00000c780000
> >>> [ 5.155504] Bad eraseblock 1536 at 0x000018000000
> >>> [ 5.161008] Bad eraseblock 1537 at 0x000018040000
> >>> [ 5.487883] Bad block table written to 0x00001ffc0000, version 0x01
> >>
> >> And is this the bad kernel or the good kernel? The question I am trying
> >> to answer is: Can the good kernel read the BBT it has written? Can the
> >> bad Kernel do that?
> >
> > The "First boot" and "Second boot" was before the exec_op patch...
> >
> > This is the new kernel including the exec_op patch:
> > [ 1.343615] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xdc
> >
> > [ 1.343656] nand: Toshiba NAND 512MiB 3,3V 8-bit
> >
> > [ 1.343693] nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, > OOB size: 128
> > [ 1.348666] random: fast init done
> > [ 1.349518] Bad block table not found for chip 0
> > [ 1.351451] Bad block table not found for chip 0
> > [ 1.351486] Scanning device for bad blocks
> > [ 1.827337] Bad eraseblock 798 at 0x00000c780000
> >
> > [ 2.265949] Bad eraseblock 1536 at 0x000018000000
> > [ 2.266318] Bad eraseblock 1537 at 0x000018040000
> >
> > [ 2.572820] Bad block table written to 0x00001ffc0000, version 0x01
> > [ 2.576120] Bad block table written to 0x00001ff80000, version 0x01
> >
> > [ 2.577087] 3 fixed-partitions partitions found on MTD device gpmi-nand
> > [ 2.577127] Creating 3 MTD partitions on "gpmi-nand":
> > [ 2.577188] 0x000000000000-0x000000800000 : "boot"
> >
> >
> >
> > [ 2.584162] 0x000000800000-0x00001ca00000 : "ubi"
> > [ 2.608571] 0x00001ca00000-0x000020000000 : "testing"
> > [ 2.614136] gpmi-nand 1806000.gpmi-nand: driver registered.
> >
> > Exactly the same output... which must mean it fails reading/writing the > bbt on the 4.19.x series kernel.
> >
> > /Sean
>
> Hi Sascha
>
> Please let me know when you have some time to look into this :-)
> I dosen't seem right that it writes the bbt on a 4.19 series kernel twice
>
For me the disturbing part is:
> >>> [ 4.175918] Bad block table not found for chip 0
> >>> [ 4.184059] Bad block table not found for chip 0
Writing the BBT twice is expected.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-09-19 11:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 20:26 [Bug] mtd: rawnand: gpmi Sean Nyekjaer
2019-09-05 20:39 ` Marc Kleine-Budde
[not found] ` <E8555824-943E-45B4-A0ED-D42E13156EEC@geanix.com>
2019-09-06 7:01 ` Marc Kleine-Budde
2019-09-06 7:12 ` Sascha Hauer
2019-09-06 9:59 ` Sean Nyekjaer
2019-09-06 10:13 ` Sascha Hauer
2019-09-06 11:06 ` Sean Nyekjaer
2019-09-06 13:28 ` Sascha Hauer
2019-09-06 15:05 ` Sean Nyekjaer
2019-09-10 9:55 ` Sascha Hauer
2019-09-10 10:18 ` Sean Nyekjaer
2019-09-10 10:48 ` Sascha Hauer
2019-09-10 11:00 ` Sean Nyekjaer
2019-09-10 11:08 ` Sascha Hauer
2019-09-10 11:51 ` Sean Nyekjaer
2019-09-19 11:21 ` Sean Nyekjaer
2019-09-19 11:27 ` Miquel Raynal [this message]
2019-09-19 12:15 ` Sean Nyekjaer
2019-09-20 6:54 ` Sean Nyekjaer
2019-09-20 9:17 ` Sascha Hauer
2019-09-23 10:37 ` Sean Nyekjaer
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=20190919132719.3ca48967@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=linux-mtd@lists.infradead.org \
--cc=mkl@pengutronix.de \
--cc=s.hauer@pengutronix.de \
--cc=sean@geanix.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 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.