From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-boot hangs on imx6 pci driver
Date: Fri, 20 Jun 2014 02:11:18 +0200 [thread overview]
Message-ID: <201406200211.18240.marex@denx.de> (raw)
In-Reply-To: <CAJ+vNU3DOdLjeaETA=GWac_GH4GpPGaAgYF=GSRfYcU8+je+4Q@mail.gmail.com>
On Thursday, June 05, 2014 at 12:13:39 PM, Tim Harvey wrote:
> On Wed, Jun 4, 2014 at 11:30 PM, "David M?ller (ELSOFT AG)"
>
> <d.mueller@elsoft.ch> wrote:
> > Tim Harvey wrote:
> >> When enabling PCI support in u-boot my 3.14 kernel hangs somewhere
> >> during PCI init or enumeration (can't tell as uart is not up yet)
> >
> > Enabling "earlyprintk" support may help.
>
> David,
>
> This is definitely related to PCI_RST# as the delay you inserted is
> essentially after imx6_pcie_probe() gets the reset_gpio from OF and
> asserts it low. Moving the delay around I find that it must come
> before imx6_pcie_assert_core_reset(), specifically before
> IMOUX_GPR1:18 is set (phy power down request).
>
> Enabling earlyprintk to try to debug the 'hang' on my boards further I
> find that I hang in in imx6_pcie_link_up() during the
> readl(pp->dbi_base + PCIE_PHY_DEBUG_R1) which is called after setting
> IOMUXC_GPR12:1 to start LTSSM. If I add a udelay(55) (55us determined
> via trial and error) directly after setting IOMUXC_GPR12:1 I get
> passed 'this' hang however during pci_scan_bridge() I find that
> PCI_PRIMARY_BUS config dword comes back as 0x00000000 instead of
> 0x00010100. This appears to cause the causes the pci code to think the
> RC is a bridge, tries to scan behind it, and hangs (because its not a
> bridge and those transactions are not valid).
>
> All of this seems to indicate to me that the PLX bridge I have on my
> boards requires a longer minimum time to be held in reset 'before' the
> PCIe PHY is powered down 'if' it has already been enumerated (or
> something to that nature) as I only see this if I enable PCI in uboot.
> Why I also need the extra udelay after enabling LTSSM in this scenario
> I can't say.
>
> This may correlate with your findings as I believe you say you have an
> i210 attached to the IMX6 RC and have found an errata indicating the
> i210 needs a longer time in reset. Do you find that this is the case
> even if you disable PCI in uboot? My first thought when I read about
> that i210 errata you pointed out was that it wasn't an issue because
> we do hold reset low for 100ms in the kernel but if the issue has
> something to do with holding it in reset with the PHY being powered
> down then perhaps this explains things.
>
> Merek,
>
> you've done much more work on IMX6 link than I... any of this make
> sense to you? I believe you have never encountered this 100%
> repeatable issue on your board(s) that David and I do encounter, but
> you have encountered a 1% PCIe link failure rate (which I'm inclined
> to say is something completely different?).
Sorry for the later reply. Most certainly, I observe a failure rate of 1-out-
of-200 or so. I also use i210 though, so it might be related somehow. Can you
tell me which i210 errata are you talking about here please?
I am currently discussing this with FSL, but it didn't yield any results yet.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-06-20 0:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 12:30 [U-Boot] U-boot hangs on imx6 pci driver Fabio Estevam
2014-05-27 13:25 ` Marek Vasut
2014-05-27 14:43 ` "David Müller (ELSOFT AG)"
2014-05-27 14:56 ` Marek Vasut
2014-05-28 7:40 ` "David Müller (ELSOFT AG)"
2014-05-28 16:43 ` Fabio Estevam
2014-05-30 7:04 ` "David Müller (ELSOFT AG)"
2014-06-05 0:16 ` Tim Harvey
2014-06-05 6:30 ` "David Müller (ELSOFT AG)"
2014-06-05 10:13 ` Tim Harvey
2014-06-20 0:11 ` Marek Vasut [this message]
2014-06-05 15:27 ` Fabio Estevam
2014-06-05 17:53 ` Marek Vasut
2014-06-05 19:20 ` Fabio Estevam
2014-06-05 22:04 ` Marek Vasut
2014-06-05 22:14 ` Fabio Estevam
2014-06-05 22:15 ` Marek Vasut
2014-06-06 4:35 ` Tim Harvey
2014-06-17 14:14 ` Fabio Estevam
2014-06-20 0:22 ` Marek Vasut
2014-05-28 16:42 ` Fabio Estevam
2014-05-28 18:31 ` Marek Vasut
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=201406200211.18240.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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