FEC ethernet issues [Was: PL310 errata workarounds]

[eric.nelson@boundarydevices.com (Eric Nelson)]

Hi Russell,

On 04/01/2014 02:26 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 26, 2014 at 12:11:35AM +0000, Russell King - ARM Linux wrote:
>> On Mon, Mar 24, 2014 at 11:44:43PM +0000, Russell King - ARM Linux wrote:
>>> Now, you mention packet loss above.  Even on half-duplex networks, I
>>> would not expect there to be much packet loss because of the
>>> retransmissions after a collision, and 100Mbit networks handle this
>>> much better than 10Mbit.  It takes repeated collisions to cause a
>>> packet to actually be dropped (and a packet being dropped because
>>> of collisions should be logged by the transmitting host in its
>>> interface statistics.)
>>>
>>> Another possibility is that the FEC isn't properly negotiating with
>>> the hub, and the two ends are ending up configured differently, or
>>> that it is negotiating properly but the FEC isn't being configured
>>> correctly.
>>>
>>> Now that we know a little more about your setup, including that it
>>> seems to be one specific setup which is causing the problems, I'll
>>> do some more testing - I have an old Allied Telesys 10/100 hub here
>>> which I'll try putting the iMX6 on and re-run your tests.
>>
>> PC --- 100Mbit hub --- iMX6S
>>
>> iperf (2.0.5) -c PC -r reports:
>>
>> iMX6 Tx: [  5]  0.0-10.0 sec  85.5 MBytes  71.5 Mbits/sec
>> iMX6 Rx: [  3]  0.0-10.0 sec   103 MBytes  86.2 Mbits/sec
>>
>> However, there's a marked difference when the iMX6 sends - the
>> collision LED is almost permanently on at full brightness, whereas
>> when the PC is sending, it's almost always off.
>>
>> I'm seeing lots of late collisions and CRC errors in the statistics
>> registers.
>>
>> It looks to me like the iMX6's transmitter is blathering at any moment,
>> not taking any notice whether there's already a carrier on the RX side.
>> I'm not yet sure what to make of this yet.
>
> Last night, I performed a different test:
>
> PC --- Gigabit switch --- 10/100Mbit hub --- 10Mbit hub --- iMX6S
>             |
>    (the rest of my network)
>
> This shows that all the (late) collisions occur in the 10Mbit domain,
> and very few in the 100Mbit domain, which puts the blame fairly
> squarely on the iMX6 side.
>
> I can see nothing wrong with the setup of the iMX6, nor of the AR8035
> phy which my board has.  Both the phy and the FEC appear to correctly
> indicate that they are configured for half-duplex with flow control
> disabled, and I've been through the iomux settings for the RGMII
> interface.
>
> So, I'm left with three possibilities:
> - the AR8035 doesn't work with half-duplex
> - there is something wrong with the signalling for carrier sense between
>    the AR8035 and the FEC.
> - the iMX6 FEC doesn't work with half-duplex
>
> It's not easy to monitor the TX_CTL and RX_CTL signals and make sense of
> them, so I can't really say what's at fault at the moment, but from what
> I can see, my hardware fails to work correctly with half-duplex
> connections.
>

What value do you have for pad control register
IOMUXC_SW_PAD_CTL_PAD_RGMII_TX_CTL (0x020E0388)?

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).