From: Miquel RAYNAL <miquel.raynal@free-electrons.com>
To: "Sean Nyekjær" <sean.nyekjaer@prevas.dk>
Cc: ezequiel.garcia@free-electrons.com,
linux-mtd@lists.infradead.org,
"Kasper Revsbech (KREV)" <krev@triax.com>
Subject: Re: [BUG] pxa3xx: wait time out when scanning for bb
Date: Wed, 29 Nov 2017 09:03:05 +0100 [thread overview]
Message-ID: <20171129090305.0174246d@xps13> (raw)
In-Reply-To: <1e2bea86-e429-e3c4-a6e4-c2c82457a061@prevas.dk>
Hi Sean,
> >>>> [ 2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >>>> step size 2048
> >>> In theory, Marvell NAND flash controller does support 16-bit
> >>> strength per 512 bytes over 2048 bytes pages. However, this
> >>> controller driver (pxa3xx_nand) does not. See [1] for the
> >>> supported configurations.
> >>>
> >>> The ECC strength shown here is probably the best to use with this
> >>> type of NAND device but I suggest you try with 4b/512B by using
> >>> these two properties like in [2]:
> >>>
> >>> nand-ecc-strength = <4>;
> >>> nand-ecc-step-size = <512>;
> >> My dts iscreated with great inspiration from the
> >> armada-385-dp-ap.dts
> >>
> >> &nand {
> >> status = "okay";
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >> num-cs = <1>;
> >> nand-on-flash-bbt;
> >> nand-ecc-strength = <4>;
> >> nand-ecc-step-size = <512>;
> >> };
> > Just for testing purpose, could you also put the keep-config and
> > enable-arbiter properties ?
> Yes, but i don't think the arbiter have any affect in the nand
> controller. Bit 12 in NDCR register is marked reserved in the
> datasheet.
Be careful with that. I recently enabled 64-bit platforms featuring
this NAND controller. After hours of digging because it was not
working, I set this bit by adding this property like in any other device
tree and it worked. I am not telling that it will solve your issue,
mostly not, but this is something you should be careful about.
> >
> >> Why does the driver not set these values?
> > Perhaps you can add traces there [3] and see where it fails?
> >
> > [3]
> > http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1721
> See here [4] the driver is selecting 16 bit strength when we are
> specifying 4 bits in the dts.
That is right.
>
> [4]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1595
> >> (I only see the timeouts if I remove the nand-on-flash-bbt)
> > The nand-on-flash-bbt will read some of the last pages in you NAND
> > chip where a bad block table is supposed to be and derive from that
> > whether a block is bad or not. So this does only one read. I guess
> > you should have at least one timeout there?
> Maybe, but the flash is fine we are running a rootfs in the NAND chip.
So you can safely use the content of the NAND chip? Without any timeout
neither with reads nor writes? Can you try the mtd-utils from [5]:
nanddump/nandwrite or nandpagetest?
Also, can you isolate the line that produces the timeouts?
[5] http://www.linux-mtd.infradead.org/
>
> > Without this property, the NAND core will read every bad block
> > marker (a few bytes at the beginning of the OOB area) and detect if
> > the block was marked bad. Each access seems to produce a timeout,
> > hence the big amount of errors you see.
> in the old thread I linked, they had the same issue and like me only
> when scanning for
> bad blocks.
>
> /Sean
next prev parent reply other threads:[~2017-11-29 8:03 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 9:12 [BUG] pxa3xx: wait time out when scanning for bb Sean Nyekjær
2017-11-28 13:02 ` Miquel RAYNAL
2017-11-28 13:12 ` Sean Nyekjær
2017-11-28 13:30 ` Miquel RAYNAL
2017-11-28 13:42 ` Sean Nyekjær
2017-11-28 14:04 ` Miquel RAYNAL
2017-11-29 7:14 ` Sean Nyekjær
2017-11-29 8:03 ` Miquel RAYNAL [this message]
2017-11-30 12:00 ` Sean Nyekjær
2017-11-30 17:18 ` Miquel RAYNAL
2017-11-30 18:13 ` Sean Nyekjær
2017-12-01 8:15 ` Miquel RAYNAL
2017-12-01 8:54 ` Sean Nyekjær
2017-12-07 20:38 ` Miquel RAYNAL
2017-12-08 9:04 ` Sean Nyekjær
2017-12-08 9:21 ` Miquel RAYNAL
2017-12-11 8:25 ` Sean Nyekjær
2017-12-11 8:45 ` Sean Nyekjær
2017-12-11 9:53 ` Miquel RAYNAL
2017-12-11 10:20 ` Sean Nyekjær
2017-12-11 11:35 ` Sean Nyekjær
2017-12-11 13:22 ` Sean Nyekjær
2017-12-11 14:02 ` Miquel RAYNAL
2017-12-11 14:09 ` Miquel RAYNAL
2017-12-11 14:49 ` Boris Brezillon
2017-12-12 8:44 ` Sean Nyekjær
2017-12-12 8:51 ` Miquel RAYNAL
2017-12-12 8:56 ` Sean Nyekjær
2017-12-12 10:12 ` Miquel RAYNAL
2017-12-12 10:55 ` Sean Nyekjær
2017-12-12 11:08 ` Miquel RAYNAL
2017-12-12 11:28 ` Sean Nyekjær
2017-12-12 11:35 ` Miquel RAYNAL
2017-12-12 11:49 ` Sean Nyekjær
2017-12-12 12:47 ` Miquel RAYNAL
2017-12-12 13:09 ` Sean Nyekjær
2017-12-12 13:35 ` Miquel RAYNAL
2017-12-12 18:10 ` Sean Nyekjær
2017-12-12 18:23 ` Miquel RAYNAL
2017-12-13 6:25 ` Sean Nyekjær
2017-12-13 8:41 ` Miquel RAYNAL
2017-12-13 9:31 ` Sean Nyekjær
2017-12-15 17:25 ` Miquel RAYNAL
2017-12-15 18:56 ` Sean Nyekjær
2017-12-15 19:19 ` Miquel RAYNAL
2017-12-17 11:56 ` Sean Nyekjaer
2017-12-17 13:19 ` Boris Brezillon
2017-12-17 21:47 ` Sean Nyekjaer
2017-12-17 22:00 ` Boris Brezillon
2017-12-17 22:15 ` [SPAM] " Sean Nyekjær
2017-12-17 22:19 ` Boris Brezillon
2017-12-17 22:19 ` Miquel RAYNAL
2017-12-18 6:23 ` Sean Nyekjær
2017-12-18 8:56 ` Miquel RAYNAL
2017-12-18 9:26 ` Sean Nyekjær
2017-12-18 9:35 ` Miquel RAYNAL
2017-12-18 10:12 ` Sean Nyekjær
2017-12-18 10:19 ` Miquel RAYNAL
2017-12-18 10:26 ` Sean Nyekjær
2017-12-18 10:45 ` Boris Brezillon
2017-12-18 10:48 ` Sean Nyekjær
2017-12-18 12:43 ` Boris Brezillon
2017-12-18 8:57 ` [SPAM] " Boris Brezillon
2017-12-17 13:48 ` Boris Brezillon
2017-12-11 20:11 ` Miquel RAYNAL
2017-12-09 23:18 ` Ezequiel Garcia
2017-12-10 14:17 ` Miquel RAYNAL
2017-12-11 12:30 ` Ezequiel Garcia
2017-12-11 13:13 ` Miquel RAYNAL
2017-12-11 16:08 ` Ezequiel Garcia
2017-12-11 16:41 ` Miquel RAYNAL
[not found] ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
2017-12-11 16:24 ` Ezequiel Garcia
2017-12-11 16:45 ` Boris Brezillon
2017-12-11 21:16 ` Boris Brezillon
2017-12-12 6:01 ` Greg Cook
2017-12-12 7:09 ` Ezequiel Garcia
2017-12-12 7:30 ` Greg Cook
2017-12-12 8:15 ` Boris Brezillon
2017-12-12 16:22 ` Ezequiel Garcia
2017-12-12 6:36 ` Sean Nyekjær
2017-12-12 6:50 ` Ezequiel Garcia
2017-12-12 7:17 ` Greg Cook
2017-12-09 23:04 ` Ezequiel Garcia
2017-12-09 23:22 ` Ezequiel Garcia
2017-12-09 23:24 ` Ezequiel Garcia
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=20171129090305.0174246d@xps13 \
--to=miquel.raynal@free-electrons.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=krev@triax.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sean.nyekjaer@prevas.dk \
/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