From: Miquel RAYNAL <miquel.raynal@free-electrons.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
Date: Sat, 23 Dec 2017 15:57:09 +0100 [thread overview]
Message-ID: <20171223155709.2ba16e95@xps13> (raw)
In-Reply-To: <87k1xdblxf.fsf@belgarion.home>
Hi Robert,
On Sat, 23 Dec 2017 14:42:20 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
>
> I removed a lot of people from the recipients, as this is a debug
> session.
Sure!
>
> >> > Now I get a lot of these message which I didn't have before :
> >> > [ 26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error)
> >> > while reading 126976 bytes from PEB 242:4096, read only 126976
> >> Looks like a mismatch in the ECC config. Can you check the ecc
> >> strength/step_size in both situation (old driver vs new driver)?
> >
> > For that, you might want to add traces in marvell_nand_ecc_init()
> > and marvell_nand_hw_ecc_ctrl_init().
> >
> >> Could you also dump the NDCR register in both cases?
> >
> > NDCR register (as well as NDCBx registers) will appear if you let
> >
> > #define DEBUG
> >
> > at the beginning of the driver.
> >
> > Also, can you please give us the entire dmesg (I mean the boot, not
> > the flow of UBIFS errors of course).
> Here it comes in [3]. I suspect the BBT parser here, here is the
> extract that _might_ be relevant:
> [ 3.372907] nand: ->exec_op() parser: pattern not found!
Indeed this might be the problem, it means there is one scenario that
should be handled by the parser that is missing. I am really
interrogative about which one it is and to discover it, can you rebuild
with
#define DEBUG
in drivers/mtd/nand/nand_base.c too.
This way the core will display the patterns it try to find a match for.
Also to ease the understanding, you might add a dump_stack() right
next to this error message.
> [ 3.378445] marvell-nfc pxa3xx-nand:
> ... repeats many times ...
> [ 3.666571] Bad block table not found for chip 0
> [ 3.671368] Scanning device for bad blocks
> [ 3.675540] nand: nand_do_read_oob: from = 0x00000000, len = 64
> [ 3.681688] marvell-nfc pxa3xx-nand:
> [ 3.681688] NDCR: 0x9d079fff
> [ 3.681688] NDCB0: 0x000d3000
> [ 3.681688] NDCB1: 0x00000000
> [ 3.681688] NDCB2: 0x00000000
> [ 3.681688] NDCB3: 0x00000000
> [ 3.700570] Bad eraseblock 0 at 0x000000000000
>
> My configuration is :
> - make zylonite_defconfig
> - apply patch in [1] for arch/arm/mach-pxa
> - apply patch in [2] for drivers/mtd
> - run the test (make zylonite_defconfig; make;
> do_the_test_with_jenkins) That should give you all my setup
> information, ie. platform_data, ECC and BBT settings (ie. the
> "MBBbt0" pattern).
This is probably a typo, because we expect the pattern to be "MVBbt0"?
>
> Cheers.
>
Thanks for the help,
Miquèl
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: miquel.raynal@free-electrons.com (Miquel RAYNAL)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
Date: Sat, 23 Dec 2017 15:57:09 +0100 [thread overview]
Message-ID: <20171223155709.2ba16e95@xps13> (raw)
In-Reply-To: <87k1xdblxf.fsf@belgarion.home>
Hi Robert,
On Sat, 23 Dec 2017 14:42:20 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Miquel RAYNAL <miquel.raynal@free-electrons.com> writes:
>
> I removed a lot of people from the recipients, as this is a debug
> session.
Sure!
>
> >> > Now I get a lot of these message which I didn't have before :
> >> > [ 26.897372] ubi0 warning: ubi_io_read: error -74 (ECC error)
> >> > while reading 126976 bytes from PEB 242:4096, read only 126976
> >> Looks like a mismatch in the ECC config. Can you check the ecc
> >> strength/step_size in both situation (old driver vs new driver)?
> >
> > For that, you might want to add traces in marvell_nand_ecc_init()
> > and marvell_nand_hw_ecc_ctrl_init().
> >
> >> Could you also dump the NDCR register in both cases?
> >
> > NDCR register (as well as NDCBx registers) will appear if you let
> >
> > #define DEBUG
> >
> > at the beginning of the driver.
> >
> > Also, can you please give us the entire dmesg (I mean the boot, not
> > the flow of UBIFS errors of course).
> Here it comes in [3]. I suspect the BBT parser here, here is the
> extract that _might_ be relevant:
> [ 3.372907] nand: ->exec_op() parser: pattern not found!
Indeed this might be the problem, it means there is one scenario that
should be handled by the parser that is missing. I am really
interrogative about which one it is and to discover it, can you rebuild
with
#define DEBUG
in drivers/mtd/nand/nand_base.c too.
This way the core will display the patterns it try to find a match for.
Also to ease the understanding, you might add a dump_stack() right
next to this error message.
> [ 3.378445] marvell-nfc pxa3xx-nand:
> ... repeats many times ...
> [ 3.666571] Bad block table not found for chip 0
> [ 3.671368] Scanning device for bad blocks
> [ 3.675540] nand: nand_do_read_oob: from = 0x00000000, len = 64
> [ 3.681688] marvell-nfc pxa3xx-nand:
> [ 3.681688] NDCR: 0x9d079fff
> [ 3.681688] NDCB0: 0x000d3000
> [ 3.681688] NDCB1: 0x00000000
> [ 3.681688] NDCB2: 0x00000000
> [ 3.681688] NDCB3: 0x00000000
> [ 3.700570] Bad eraseblock 0 at 0x000000000000
>
> My configuration is :
> - make zylonite_defconfig
> - apply patch in [1] for arch/arm/mach-pxa
> - apply patch in [2] for drivers/mtd
> - run the test (make zylonite_defconfig; make;
> do_the_test_with_jenkins) That should give you all my setup
> information, ie. platform_data, ECC and BBT settings (ie. the
> "MBBbt0" pattern).
This is probably a typo, because we expect the pattern to be "MVBbt0"?
>
> Cheers.
>
Thanks for the help,
Miqu?l
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-12-23 14:57 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 20:18 [PATCH 00/12] Marvell NAND controller rework with ->exec_op() Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 01/12] dt-bindings: mtd: add Marvell NAND controller documentation Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-08 20:56 ` Boris Brezillon
2017-12-08 20:56 ` Boris Brezillon
2017-12-08 20:56 ` Boris Brezillon
2017-12-07 20:18 ` [PATCH 02/12] mtd: nand: add reworked Marvell NAND controller driver Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-11 16:27 ` Ezequiel Garcia
2017-12-11 16:27 ` Ezequiel Garcia
2017-12-11 16:55 ` Miquel RAYNAL
2017-12-11 16:55 ` Miquel RAYNAL
2017-12-11 16:55 ` Miquel RAYNAL
2017-12-11 17:05 ` Boris Brezillon
2017-12-11 17:05 ` Boris Brezillon
2017-12-11 17:05 ` Boris Brezillon
2017-12-11 21:02 ` Miquel RAYNAL
2017-12-11 21:02 ` Miquel RAYNAL
2017-12-11 21:02 ` Miquel RAYNAL
2017-12-07 20:18 ` [PATCH 03/12] mtd: nand: replace pxa3xx_nand driver by its rework called marvell_nand Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 04/12] dt-bindings: mtd: remove pxa3xx NAND controller documentation Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 05/12] mtd: nand: remove useless fields from pxa3xx NAND platform data Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 06/12] ARM: dts: armada-370-xp: use reworked NAND controller driver Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 07/12] ARM: dts: armada-375: " Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 08/12] ARM: dts: armada-38x: " Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 09/12] ARM: dts: armada-39x: " Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 10/12] ARM: dts: pxa: " Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` [PATCH 11/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 7K Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-07 20:18 ` [PATCH 12/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 8K Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-07 20:18 ` Miquel Raynal
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:29 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-15 10:44 ` Gregory CLEMENT
2017-12-09 23:27 ` [PATCH 00/12] Marvell NAND controller rework with ->exec_op() Ezequiel Garcia
2017-12-09 23:27 ` Ezequiel Garcia
2017-12-09 23:27 ` Ezequiel Garcia
2017-12-14 6:09 ` Boris Brezillon
2017-12-14 6:09 ` Boris Brezillon
2017-12-14 6:09 ` Boris Brezillon
2017-12-18 7:11 ` Robert Jarzmik
2017-12-18 7:11 ` Robert Jarzmik
2017-12-18 7:11 ` Robert Jarzmik
2017-12-18 8:25 ` Miquel RAYNAL
2017-12-18 8:25 ` Miquel RAYNAL
2017-12-18 8:25 ` Miquel RAYNAL
2017-12-20 21:26 ` Robert Jarzmik
2017-12-20 21:26 ` Robert Jarzmik
2017-12-20 21:26 ` Robert Jarzmik
2017-12-20 21:41 ` Boris Brezillon
2017-12-20 21:41 ` Boris Brezillon
2017-12-20 21:41 ` Boris Brezillon
2017-12-22 20:11 ` Robert Jarzmik
2017-12-22 20:11 ` Robert Jarzmik
2017-12-22 20:11 ` Robert Jarzmik
2017-12-22 21:24 ` Boris Brezillon
2017-12-22 21:24 ` Boris Brezillon
2017-12-22 21:24 ` Boris Brezillon
2017-12-22 22:37 ` Miquel RAYNAL
2017-12-22 22:37 ` Miquel RAYNAL
2017-12-22 22:37 ` Miquel RAYNAL
2017-12-22 22:50 ` Miquel RAYNAL
2017-12-22 22:50 ` Miquel RAYNAL
2017-12-22 22:50 ` Miquel RAYNAL
2017-12-23 13:42 ` Robert Jarzmik
2017-12-23 13:42 ` Robert Jarzmik
2017-12-23 14:57 ` Miquel RAYNAL [this message]
2017-12-23 14:57 ` Miquel RAYNAL
2017-12-23 17:14 ` Robert Jarzmik
2017-12-23 17:14 ` Robert Jarzmik
2017-12-23 22:42 ` Miquel RAYNAL
2017-12-23 22:42 ` Miquel RAYNAL
2018-01-02 11:03 ` Miquel RAYNAL
2018-01-02 11:03 ` Miquel RAYNAL
2018-01-02 19:21 ` Robert Jarzmik
2018-01-03 7:40 ` Miquel RAYNAL
2018-01-03 7:40 ` Miquel RAYNAL
2018-01-03 19:58 ` Robert Jarzmik
2018-01-03 19:58 ` Robert Jarzmik
2018-01-03 20:10 ` Boris Brezillon
2018-01-03 20:10 ` Boris Brezillon
2018-01-03 20:52 ` Boris Brezillon
2018-01-03 20:52 ` Boris Brezillon
2018-01-07 20:55 ` Robert Jarzmik
2018-01-07 20:55 ` Robert Jarzmik
2018-01-07 21:09 ` Miquel RAYNAL
2018-01-07 21:09 ` Miquel RAYNAL
2018-01-07 21:19 ` Boris Brezillon
2018-01-07 21:19 ` Boris Brezillon
2018-01-07 21:26 ` Boris Brezillon
2018-01-07 21:26 ` Boris Brezillon
2018-01-09 7:57 ` Robert Jarzmik
2018-01-09 7:57 ` Robert Jarzmik
2018-01-09 11:06 ` Miquel RAYNAL
2018-01-09 11:06 ` Miquel RAYNAL
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=20171223155709.2ba16e95@xps13 \
--to=miquel.raynal@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--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 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.