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

[Liu Dave-R63238]

Hi Dave,

Good news, Good summary!

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

IIRC, The FPGA of MPC8349EA-MDS can control if we use the PHY
as master. We were aware of this.

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