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>,
Boris Brezillon <Boris.Brezillon@free-electrons.com>
Subject: Re: [BUG] pxa3xx: wait time out when scanning for bb
Date: Fri, 1 Dec 2017 09:15:39 +0100 [thread overview]
Message-ID: <20171201091539.5d6b7572@xps13> (raw)
In-Reply-To: <5bc5d326-af1f-44d2-468a-d211212c4612@prevas.dk>
> >>>>>> (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/
> >> Yes the NAND chip is working fine and stores our data.
> >>
> >> It is the command NAND_CMD_READOOB that causes it to timeout.
> > Ok, I had a look at the nand_cmdfunc() function which is, I suppose,
> > the one that is in use (because you are using 2k pages) but I could
> > not see anything obvious. Is your setup special in some way?
> Yes it's nand_cmdfunc()
> No a clean 4.14.0 kernel with a custom dts.
> >
> > Could you enable dynamic debug by adding "#define DEBUG" *before*
> > all #includes at the top of the pxa3xx_nand.c driver? It should
> > display all register accesses. Also, can you read the content of
> > NDCR and NDSR when it timeouts?
> >
> [ 32.765604] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():605
> nand_writel(0x1, 0x0028)
> [ 32.765609] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625
> nand_writel(0xfff, 0x0014)
> [ 32.765614] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626
> nand_writel(0x0, 0x0000)
> [ 32.765620] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627
> nand_writel(0xd1078000, 0x0000)
This is a write command request.
> [ 32.765627] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x1
> [ 32.765632] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874
> nand_writel(0x1, 0x0014)
The command is ready to be written in NDCB* registers (0x48).
> [ 32.765637] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888
> nand_writel(0xd3000, 0x0048)
> [ 32.765643] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889
> nand_writel(0x2060000, 0x0048)
> [ 32.765648] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890
> nand_writel(0x0, 0x0048)
> [ 32.765653] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894
> nand_writel(0x0, 0x0048)
"Command" registers are set:
- READ0/READSTART commands (double byte command)
- 5 address cycles: column is 0, page is 0x206 which is weird if this
is a READOOB operation, where column should be something like 0x800
(mtd->writesize).
> [ 32.765677] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x800
> [ 32.765682] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874
> nand_writel(0x800, 0x0014)
> [ 32.765797] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x2
> [ 32.765886] pxa3xx-nand f10d0000.flash:
> pxa3xx_nand_irq_thread():804 nand_writel(0x6, 0x0014)
Read data request received, the FIFO may be drawn.
> [ 32.765893] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x500
> [ 32.765899] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874
> nand_writel(0x500, 0x0014)
> [ 32.765950] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():609
> nand_writel(0x0, 0x0028)
> [ 32.765956] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625
> nand_writel(0xfff, 0x0014)
Command done received, it means data was read correctly.
And this is the start of another "action".
> [ 32.765961] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626
> nand_writel(0x0, 0x0000)
> [ 32.765966] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627
> nand_writel(0x91078000, 0x0000)
> [ 32.765974] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x1
> [ 32.765979] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874
> nand_writel(0x1, 0x0014)
Same as before, command is ready to be written, single difference is
the use of the HW ECC engine. But, a few lines earlier, 0 was written
to NDECCCTRL (0x28), disabling BCH, which is weird because there we
will do an operation under Hamming ECC engine.
> [ 32.765984] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888
> nand_writel(0xd3000, 0x0048)
> [ 32.765989] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889
> nand_writel(0x2060000, 0x0048)
> [ 32.765994] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890
> nand_writel(0x0, 0x0048)
> [ 32.766000] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894
> nand_writel(0x0, 0x0048)
Same read operation as before.
> [ 32.766022] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x800
> [ 32.766028] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874
> nand_writel(0x800, 0x0014)
> [ 32.766143] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824
> nand_readl(0x0014) = 0x2
> [ 32.766233] pxa3xx-nand f10d0000.flash:
> pxa3xx_nand_irq_thread():804 nand_writel(0x6, 0x0014)
Read data request received, I guess there is some ioread32_rep here
which is not traced and finally:
> [ 32.970203] pxa3xx-nand f10d0000.flash: Wait time out!!!
Next lines are the error path.
> *[ 32.975535] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():636
> nand_readl(0x0014) = 0x0*
> *[ 32.975540] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():637
> nand_readl(0x0000) = 0x91078000*
> [ 32.975546] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639
> nand_readl(0x0000) = 0x91078000
> [ 32.975552] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639
> nand_readl(0x0000) = 0x91078000
> [ 32.975559] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639
> nand_readl(0x0000) = 0x91078000
> [ 32.975565] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639
> nand_readl(0x0000) = 0x91078000
> [ 32.975572] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():645
> nand_writel(0x81078000, 0x0000)
> [ 32.975577] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():651
> nand_writel(0xfff, 0x0014)
>
> I think I got one whole timeout sequence here :-)
> Register 0x0014 is NDSR and reg 0x0000 is NDCR, I have added a read
> of the NDSR register in the pxa3xx_nand_stop routine as highlighted
> above. It pussles me that the nand_start is called two times before
> the timeout, maybe it's okay.
Can you add traces there [1] to see which path is used ?
[1]
http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/pxa3xx_nand.c#L669
Thanks,
Miquèl
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-12-01 8:16 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
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 [this message]
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=20171201091539.5d6b7572@xps13 \
--to=miquel.raynal@free-electrons.com \
--cc=Boris.Brezillon@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