public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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