From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Mon, 03 Feb 2014 13:54:33 -0700 Subject: [U-Boot] [PATCH] pci: mx6: Implement reset callback In-Reply-To: <201402032116.16945.marex@denx.de> References: <1390577140-7402-1-git-send-email-marex@denx.de> <201402032033.32072.marex@denx.de> <52EFF4AA.1030804@boundarydevices.com> <201402032116.16945.marex@denx.de> Message-ID: <52F00209.2040201@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 02/03/2014 01:16 PM, Marek Vasut wrote: > On Monday, February 03, 2014 at 08:57:30 PM, Eric Nelson wrote: > > [...] > I like having this bit included, but do you need to attribute copyright for this block? >>> " >>> 6.6.1. Conventional Reset >>> >>> Conventional Reset includes all reset mechanisms other than Function >>> Level Reset. There are two categories of Conventional Resets: >>> Fundamental Reset and resets that are not Fundamental Reset. This >>> section applies to all types of Conventional Reset. >>> >>> In all form factors and system hardware configurations, there must, at >>> some level, be a hardware mechanism for setting or returning all Port >>> states to the initial conditions specified in this document ? this >>> mechanism is called ?Fundamental Reset.? This mechanism can take the >>> form of an auxiliary signal provided by the system to a component or >>> adapter card, in which case the signal must be called PERST#, and must >>> conform to the rules specified in Section 4.2.4.8.1. When PERST# is >>> provided to a component or adapter, this signal must be used by the >>> component or adapter as Fundamental Reset. >>> >>> When PERST# is not provided to a component or adapter, Fundamental Reset >>> is generated autonomously by the component or adapter, and the details >>> of how this is done are outside the scope of this document. If a >>> Fundamental Reset is generated autonomously by the component or adapter, >>> and if power is supplied by the platform to the component/adapter, the >>> component/adapter must generate a Fundamental Reset to itself if the >>> supplied power goes outside of the limits specified for the form factor >>> or system. >>> " >>> >>> This means, your platform _MUST_ have a FR implementation. If you have >>> PERST connected (that's the reset pin) to for example GPIO, then so be >>> it and that's your FR. >>> >>> The third paragraph states that if you do NOT have PERST connected, you >>> need some other way of doing FR. Another way of generating FR is to >>> depend on POR, so when power is applied to the component, it will >>> generate FR internally. Thus to produce an "alternative" FR without >>> PERST connected, you toggle the power GPIO of the particular slot. >>> >>> I think the SL can do neither, right ? :-( >> >> Right again. >> >> PCIe was very much an afterthought (and late addition) on SABRE Lite, >> and unfortunately only slightly improved on Nitrogen6x. > > OK. This wasn't an attack in the SL direction, really. I really want to warn > people to comply with the spec, since otherwise they will suffer from weird bugs > that are hard to find. The PERST is a prime example of that :-( > No worries. I appreciate the details. > We really should start waving a sign "YOU MUST CONNECT PERST IN YOUR NEW DESIGN, > OTHERWISE A KITTEN DIES!" > Hey, leave the kittens alone! >> We have had success in using/testing PCIe devices without either, but >> that doesn't mean we match the spec, and I suppose we'll have to live >> with the "broken design" message... > > I know. The design without FR works most of the time, but there is one > particular scenario where it may fail (means it fails reliably). I will assume > we have just a simple RC<->EP connection with EP being i82574L card (well > supported and easily available intel NIC): > > 1) Cold boot the system > 2) Bring up the PCIe link in U-Boot > 3) Use the e1000e driver for some transfer > 4) Boot Linux > 5) Bring up the PCIe link in Linux > 6) Use the e1000e driver for some transfer > 7) Reboot the system from Linux > 8) Bring up the PCIe link in U-Boot > > In case you don't have means to do FR, your system will fail during 5) and/or > during 8) because in either case, the link and/or EP device can be in undefined > state from previous usage. You are therefore not able to send in-band messages > to the EP (to issue hot reset for example*) nor restart the link, thus you're > trapped. > > * if you try to send anything over unstable PCIe link on MX6, it can stall your > entire system to the point where the system bus is stuck and not even JTAG > debugger can halt the CPU (!) > Thanks. That's a useful test scenario.