From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Miquel RAYNAL <miquel.raynal@free-electrons.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
Date: Fri, 12 Jan 2018 11:21:08 +0100 [thread overview]
Message-ID: <20180112112108.2e20dc14@bbrezillon> (raw)
In-Reply-To: <876087beui.fsf@belgarion.home>
On Fri, 12 Jan 2018 10:34:13 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> > On Fri, 12 Jan 2018 09:09:17 +0100
> > Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >
> >> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
> >>
> >> I begun all your test procedure (on my zylonite board).
> >> The timing registers are the same in both pxa3xx_nand and marvell_nand, ie :
> >> [ 3.085539] Timing registers from Bootloader:
> >> [ 3.089971] - NDTR0: 0x00161c1c
> >> [ 3.095979] - NDTR1: 0x0f3c00a2
> >>
> >> I can attach the dmesg of the first run (dump of OOB). Yet I think you're
> >> missing the point as to where the bug lies.
> >
> > We definitely don't know where the bug lies, otherwise we wouldn't do
> > the remote debug session we're doing here.
> Fair enough.
> > The driver is not searching for a BBT because it's explicitly disabled
> > in your pdata (if it was enabled we would see something like "Bad block
> > table not found ..." or "Bad block table found ..." in the logs).
> You're right, and that's because I was told to remove the "flash_bbt=1" from my
> platform data by Miquel in order to not destroy it again.
>
> > And that's anyway not the bug we're trying to fix here. In your setup (2k
> > pages with Hamming ECC), the bad block markers, i.e. the markers present in
> > each block and used to mark a block good or bad (0xffff => good, != 0xffff =>
> > bad), should be preserved.
> I think we're still not aligned here. There are _no_ bad block markers in the
> OOB on my flash, because there is a BBT at the end.
I think I'm still missing something. If I look at the branch you just
pushed, I see that ->flash_bbt was not set to 1 before this commit [1],
which means the pxa3xx driver was no setting the NAND_BBT_USE_FLASH
flag, which in turn means you were not using the on-flash-bbt.
When you test the old (pxa3xx) driver, are you sure you're testing
things with a mainline kernel? If you have extra commits on top of
mainline, can you push them somewhere?
[1]https://github.com/rjarzmik/linux/commit/5d391176c89a777f1c7d082cd50c1dc87e54b355#diff-6e551812174323b126d3f20eff6eec83
next prev parent reply other threads:[~2018-01-12 10:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 10:36 [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op() Miquel Raynal
2018-01-09 10:36 ` [PATCH v3 1/7] dt-bindings: mtd: document new nand-rb property Miquel Raynal
2018-01-11 22:23 ` Rob Herring
2018-01-09 10:36 ` [PATCH v3 2/7] dt-bindings: mtd: add Marvell NAND controller documentation Miquel Raynal
2018-01-11 22:25 ` Rob Herring
2018-01-09 10:36 ` [PATCH v3 3/7] mtd: nand: add reworked Marvell NAND controller driver Miquel Raynal
2018-01-09 10:36 ` [PATCH v3 4/7] mtd: nand: use reworked NAND controller driver with Marvell EBU SoCs Miquel Raynal
2018-01-09 10:36 ` [PATCH v3 5/7] mtd: nand: use Marvell reworked NAND controller driver with all platforms Miquel Raynal
2018-02-12 10:20 ` Boris Brezillon
2018-01-09 10:36 ` [PATCH v3 6/7] dt-bindings: mtd: remove pxa3xx NAND controller documentation Miquel Raynal
2018-01-09 10:36 ` [PATCH v3 7/7] mtd: nand: remove useless fields from pxa3xx NAND platform data Miquel Raynal
2018-02-12 10:17 ` Miquel Raynal
2018-02-17 9:43 ` Robert Jarzmik
2018-01-11 11:27 ` [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op() Boris Brezillon
2018-01-11 17:42 ` Robert Jarzmik
2018-01-11 22:24 ` Miquel RAYNAL
2018-01-12 8:09 ` Robert Jarzmik
2018-01-12 8:45 ` Boris Brezillon
2018-01-12 9:01 ` Miquel Raynal
2018-01-12 9:34 ` Robert Jarzmik
2018-01-12 9:52 ` Boris Brezillon
2018-01-12 20:44 ` Robert Jarzmik
2018-01-13 8:38 ` Boris Brezillon
2018-01-13 11:05 ` Miquel Raynal
2018-01-14 10:35 ` Robert Jarzmik
2018-01-22 8:51 ` Boris Brezillon
2018-01-27 10:33 ` Robert Jarzmik
2018-01-29 10:36 ` Boris Brezillon
2018-01-12 10:21 ` Boris Brezillon [this message]
2018-01-12 16:43 ` Robert Jarzmik
2018-01-13 8:38 ` Boris Brezillon
2018-01-14 10:20 ` Robert Jarzmik
2018-01-22 8:54 ` Boris Brezillon
2018-01-11 22:28 ` Willy Tarreau
2018-01-12 18:21 ` Miquel Raynal
2018-01-12 15:55 ` 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=20180112112108.2e20dc14@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@free-electrons.com \
--cc=robert.jarzmik@free.fr \
/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