From: David Hawkins <dwh@ovro.caltech.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot] TSEC ethernet controller problems (crc errors/ corruption)
Date: Mon, 08 Jun 2009 09:46:04 -0700 [thread overview]
Message-ID: <4A2D404C.5050103@ovro.caltech.edu> (raw)
In-Reply-To: <20090608105026.572b00c8.kim.phillips@freescale.com>
Hi all,
Over the weekend we performed some hardware modifications
on our boards with their troublesome gigabit interfaces.
We performed a couple of tests, one of which may be
the solution to our problem.
1) Modified the value of the series termination of EC_GTX_CLK125
The PHY drives a 125MHz clock signal to the PowerPC
(EC_GTX_CLK125 signal) when operating in gigabit ethernet
mode.
Our schematic used a 33-Ohm series termination on this
125MHz signal, but we had used 22-Ohms for all other series
terminations. The MDS board also uses 22-Ohms series
terminations.
We replaced the 33-ohm termination with 22-ohms ... and
things started working. We looked at the 125MHz signal at
the destination pin on the BGA of the PowerPC using
a high-bandwidth scope (2GHz LeCroy) for both 22-Ohms
termination and 33-Ohms, and there is a slight
difference in waveform shape, but no obvious ringing,
or steps in the clock edges that might suggest
transmission line reflections.
The fact that we only ever observed errors in gigabit
mode, that the PHY never reports any errors,
that EC_GTX_CLK125 is only used in gigabit mode,
and that the data errors looked like a FIFO clocking
issue, is consistent with the error being related to
the quanlity of the EC_GTX_CLK125 signal.
I'm not ready to claim success, as I need to make the
change on other boards ... but its very encouraging!
2) Frequency accuracy testing
We replaced the PHY 125MHz clock source (an onboard
oscillator) with a frequency synthesizer driven into
a buffer (to create a 3.3V logic level clock).
The frequency was adjusted to 124.90MHz, 124.95MHz,
125.00MHz, 125.05MHz, and 125.10MHz. Errors were
generated for the +/-0.1MHz cases, but things worked
fine for the +/-0.05MHz offsets.
So the PHY is tolerant of frequency errors in the
oscillator.
(This test was performed after the series termination
had been changed).
Ira is going to boot the working board with Linux and
perform some network stress tests.
I'll modify some other boards, and we'll tests those too.
Cheers,
Dave
next prev parent reply other threads:[~2009-06-08 16:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-02 16:27 [U-Boot] TSEC ethernet controller problems (crc errors / corruption) Ira Snyder
2009-06-02 16:42 ` David Hawkins
2009-06-02 17:35 ` Peter Tyser
2009-06-02 18:17 ` David Hawkins
2009-06-02 18:17 ` Ira Snyder
2009-06-02 18:41 ` Kim Phillips
2009-06-02 18:50 ` Wolfgang Denk
2009-06-02 19:01 ` David Hawkins
2009-06-02 19:46 ` Ira Snyder
2009-06-02 20:38 ` [U-Boot] TSEC ethernet controller problems (crc errors/ corruption) Liu Dave-R63238
2009-06-02 20:44 ` Liu Dave-R63238
2009-06-02 21:25 ` Ira Snyder
2009-06-02 22:10 ` [U-Boot] TSEC ethernet controller problems (crc errors/corruption) Liu Dave-R63238
2009-06-02 22:19 ` [U-Boot] TSEC ethernet controller problems (crc errors/ corruption) Ira Snyder
2009-06-02 22:22 ` [U-Boot] TSEC ethernet controller problems (crc errors/corruption) Liu Dave-R63238
2009-06-02 23:08 ` [U-Boot] TSEC ethernet controller problems (crc errors/ corruption) Kim Phillips
2009-06-03 17:50 ` Ira Snyder
2009-06-03 20:19 ` Kim Phillips
2009-06-03 20:46 ` Ira Snyder
2009-06-03 21:41 ` Paul Gortmaker
2009-06-05 18:45 ` Paul Gortmaker
2009-06-06 0:38 ` Kim Phillips
2009-06-06 2:31 ` dwh at ovro.caltech.edu
2009-06-08 15:50 ` Kim Phillips
2009-06-08 16:46 ` David Hawkins [this message]
2009-06-08 23:06 ` Liu Dave-R63238
2009-06-08 23:36 ` David Hawkins
2009-06-09 21:46 ` David Hawkins
2009-06-09 23:21 ` Liu Dave-R63238
2009-06-09 23:35 ` David Hawkins
2009-06-03 21:51 ` [U-Boot] TSEC ethernet controller problems (crc errors/corruption) Liu Dave-R63238
2009-06-03 21:58 ` David Hawkins
2009-06-02 22:30 ` Liu Dave-R63238
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A2D404C.5050103@ovro.caltech.edu \
--to=dwh@ovro.caltech.edu \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox