I'd like to pass on a fix for a nasty PPC860 FEC bug in 7-wire mode

I'd like to pass on a fix for a nasty PPC860 FEC bug in 7-wire mode

[Ron Flory]

hi-

 We are building a 860P/T based embedded system using the FEC that is
present on this chip.  Due to historical reasons, we are using the
FEC in 7-wire mode (10 Mbit rate), not in MII mode.

 What we were seeing over the past few months was occasional RX packets
with a reported length of over 52 Kbytes (!!) for pings and other data
packets over 800 bytes long.  We could repeatedly cause this to happen
with ping-floods generated by a Linux/Unix/BSD machine:

    ping -nf -s1400 target_ip

 What we were able to determine was that the FEC was concatenating
subsequent RX packets together (i.e. not correctly detecting inter-
packet boundaries).

 The solution was to gate the RX_CLK signal from the PHY chip with the
RX_DV signal, which blocks any RX clocks from reaching the FEC after the
end of an RX packet.

 What we learned from a Moto FAE was that the FEC switches over to an
internal clock when RX_DV is de-asserted, BUT it continues to see
external clocks as well (which are random and async with respect to the
internal clock).

 This problem is know to happen with several different PHY chips,
even if they are configured in "Motorola" mode (the FEC is not well
documented, so its hard to confirm timing compatibility from looking
at the specs).

 I hope someone finds this of use-

ron flory
Adtran

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/