[U-Boot] TSEC ethernet controller problems (crc errors/ corruption)

[David Hawkins]

Hi all,

I modified the MPC8349E-MDS board and can create the
same problem we were experiencing on our boards;
CRC errors and data packets with received bytes
repeated within the receive packets.

So I am certain we have tracked the root cause of
the problem we were having with our boards.

The problem was related to the EC_GTX_CLK125MHZ
signal being sent from the PHY to the PowerPC
processor. The termination resistance on our board
was too large (33-Ohms). Reducing the termination
resistor value increased the signal swing, and
produced a better looking clock at the PowerPC
BGA pin; a 10-Ohm source resistor was required
in our case. Linux network stress tests now pass.

The modification to break the MDS board was simple;
I increased the CLK125MHz source termination to
50-Ohms (from its nominal 22-Ohms).
The MDS board had another error; there is a jumper
on the board for selecting the supply rail for
2.5V GETH (JS2 and JS3 on the MPC8349E-MDS-PB
schematic) as either 3.3V for GMII, or 2.5V for
RGMII. The jumper on our board was in the 2.5V
location, whereas it should be on 3.3V. Changing
this jumper made no real difference.

This testing revealed some interesting observations;

1) The Marvell 88E1111 PHY generates a 125MHz output
    clock that is used as the PowerPC EC_GTX_CLK125MHZ
    clock source on the MDS board.

    The MDS board has to use the PHY output as the 125MHz
    clock source to the PowerPC, as the PHY is clocked
    using a 25MHz oscillator, so there is no alternative
    source of 125MHz on the board.

    However, the PHY 125MHz output has a *huge* amount
    of duty cycle variation depending on whether the
    PHY has negotiated as a *master* (clock looks good),
    or as a *slave* (horrible looking clock).

    When the PHY on the MDS board, or our board,
    negotiates the 1Gbit link as a *slave*, observing
    the 125MHz output clock with an oscilloscope
    triggered on the rising edge of the clock, there
    is about 1ns of variation in the timing of the
    falling edge.

    Yikes!!!

    Has anyone else been disturbed by this???

    I know its not just on our board, as I can see
    it on the MDS board too.

2) The MPC8349EA hardware specification indicates
    a 45% to 55% duty cycle requirement on the
    EC_GTX_CLK125MHZ clock signal. The duty
    cycle is measured at LVDD/2 = 1.65V for
    GMII operating at LVDD = 3.3V.

    With the PHY generating the 125MHz clock,
    and the PHY operated at 2.5V, the duty
    cycle specification is *not* met by the
    MDS board - especially when the PHY has
    negotiated slave mode and has a huge
    amount of jitter on it.

    This seems like a minor design error,
    in that a 3.3V buffer could have been used
    on the PHY output clock to ensure 3.3V levels
    at the PowerPC.

    Anyone out there care to comment how this has
    been implemented on other boards?

Our board has a 3.3V 125MHz oscillator as the PHY source,
and clock source for other devices on the board. I need
to make some changes to our PCB, so I'll also route an
option for a 3.3V 125MHz clock to the PowerPC pin
(I'll put a 3.3V buffer on the board that can be
driven by the oscillator directly, or by the PHY
output).

I'd be interested in hearing anyone else's experience
with the 125MHz Gigabit PHY clock.

And for those finding this email in the archive,
I hope this helps you :)

Cheers,
Dave