From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.nelson@boundarydevices.com (Eric Nelson) Date: Tue, 01 Apr 2014 11:11:46 -0700 Subject: FEC ethernet issues [Was: PL310 errata workarounds] In-Reply-To: <20140401172933.GB7528@n2100.arm.linux.org.uk> References: <20140319225137.GM7528@n2100.arm.linux.org.uk> <20140321173252.GL7528@n2100.arm.linux.org.uk> <201403242121.58705.marex@denx.de> <20140324234443.GS7528@n2100.arm.linux.org.uk> <20140326001135.GV7528@n2100.arm.linux.org.uk> <20140401092638.GA10224@n2100.arm.linux.org.uk> <533AC67D.2060906@boundarydevices.com> <20140401172933.GB7528@n2100.arm.linux.org.uk> Message-ID: <533B0162.9090305@boundarydevices.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/01/2014 10:29 AM, Russell King - ARM Linux wrote: > On Tue, Apr 01, 2014 at 07:00:29AM -0700, Eric Nelson wrote: >> Hi Russell, >> >> What value do you have for pad control register >> IOMUXC_SW_PAD_CTL_PAD_RGMII_TX_CTL (0x020E0388)? > > You're referring to the iMX6Q, the Hummingboard is iMX6S, so that's > 0x20e06bc. I have value 0x1b030. > Right. I missed that you were running on Solo. >> I notice in some of the DTS files that this has a value of 0x100b0, >> which seems wrong. Bit 16 seems to be a HYSteresis bit, and enabling >> that seems wrong (also bit 7 seems wrong, as it's undefined in the RM). > > Yes, bit 7 should not be set as it's reserved, but this is ignored. > Setting the hysteresis bit affects the input thresholds, and this signal > is only ever used as an output. While selecting HYS mode for an output > may seem odd, that should not have any effect here. > > In any case, TX_CTL doesn't have much to do with it. I've fully proved > that the interface works fine under full duplex conditions, achieving > 500Mbps transmit and 570-600Mbps receive with TCP connections (which is > nicely beyond what freescale claim the hardware is capable of.) > > The phy needs TX_CTL asserted in order to transmit anything, so as it > works in full duplex mode, this must be happening correctly. > It appears I'm gender-challenged and confused TX_CTL and RX_CTL. My thought (and question) was whether the pad setup for "transmit enable" to the i.MX is either being missed entirely, or arriving late because of an internal pullup/pull down or other pad misconfiguration. The pad settings have every indication of being cut/pasted, which made me question them. > The FEC needs RX_CTL asserted to indicate that valid data is being > received by the phy - if this was not being recognised by the FEC, full > duplex mode wouldn't work. > > The last scenario is the error signals encoded onto TX_CTL/RX_CTL. This > is one area I can't comment on yet - monitoring these signals is not > exactly easy (and requires two steady hands.) However, I have briefly > monitored these signals when running at 100mbit half-duplex. With the > scope RX_CTL and triggering on it, I do see TX_CTL being raised by the > FEC. > > Whether TX_CTL is raised by the FEC just before or after RX_CTL has been > asserted I can't say yet. > > However, TX_CTL raised while RX_CTL is raised or toggling means that a > collision has occurred. TX_CTL should never be raised while RX_CTL > indicates that there is a "carrier" present in half-duplex mode (and > therefore there is already another ethernet station transmitting on > the wire.) > > Remember, I'm seeing late collisions. The only way that happens is if > something starts transmitting after 64 bytes into an ethernet frame, and > it implies that something is not noticing that the link is busy before it > starts blurting out. > I guess we can rule out slew rate. > I know that my hubs are fine - the 10mbit hub has been used over _many_ > years (it's more than 20 years old now) and has always been rock solid... > unlike the 10/100 hub with a dodgy switch between the two segments which > I can lock out the 10 mbit segment with enough 100mbit traffic. > > Let's also not forget that these signals run at 125MHz at gigabit speeds, > and 2.5MHz at 10mbit... if they were marginal at 10mbit, gigabit > certainly would not work. > Based on this, I don't see how a badly-configured pad could produce the symptoms you're seeing.