RE: MPC8xx, FEC and DP83847 !?

RE: MPC8xx, FEC and DP83847 !?

[Kerl, John]

We are using a DP83846 with 857T FEC.  At the software
level, I am just using the plain fec.c, and it works for me.

One note (if you want details, I'll have to check with my
hardware guys and get back to you, but here's the gist):
The Motorola reference boards use port D for MII, but we
used PCMCIA/port A pins instead.  This caused us a bit of
trouble when bringing up the board, but the resolution
was that we had to clear PDPAR[UT], set ECNTRL[PIN_MUX]
and set UTMODE[SPLIT].  I pasted these few lines into
fec.c's init function and it works like a charm.



-----Original Message-----
From: Steven Scholz [mailto:steven.scholz@imc-berlin.de]
Sent: Thursday, March 21, 2002 5:37 AM
To: LinuxPPC; PPCBoot
Subject: MPC8xx, FEC and DP83847 !?



Hi there,

I am about to redesign my board and consider to replace Level One's
LXT971 with National's DP83847.

Is anyone using National's Phyter DP83846/7 together with MPC8xx FEC?
Is there support for this chip like it is for LXT97x, AMD79c874 and
QS6612?
Or do I have to use ./drivers/net/natsemi.c or somthing similar?

Are there any (dis)advantages over the LXT971?

Cheers,

Steven


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

Re: MPC8xx, FEC and DP83847 !?

[Wolfgang Denk]

In message <3C9A1F5C.61673202@imc-berlin.de> you wrote:
>
> Ok. Since there are special options in DENX kernel for LXT, AMD and QS I
> thought special support for these PHYs is neccessary. Maybe only if you
> want to use the vendor specific special registers of the PHYs in
> addition to the standart MII register!?

It depends on hwat you have to do, and an the PHY.

In most cases ypu can just switch off the whole MDIO stuff  and  rely
on  autonegotiation; the only thing you lose is a kernel message when
the link status changes. Of course this requires sane hardware, which
is not always the case :-(

> > The Motorola reference boards use port D for MII, but we
> > used PCMCIA/port A pins instead.
>
> Why would you probably do this?
> I supposed you're using PORT D for something else!?

Probably.

> It would be really interessting to know...

See the ICU862 configuration in our sources. They do the same  thing,
and had similar problems...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
       There is enough for the need of everyone in this world,
       but not for the greed of everyone.     - Mahatma Gandhi

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

Re: MPC8xx, FEC and DP83847 !?

[Dan Malek]

Steven Scholz wrote:

>> The Motorola reference boards use port D for MII, but we
>> used PCMCIA/port A pins instead.
>
>
> Why would you probably do this?

If someone is doing this, please send me some patches for the
driver when you get it working.  All of the 857s I have seen
are still using Port D for the FEC.  I guess I could make the
changes if someone else can test them.

> I supposed you're using PORT D for something else!?

The intention is to also be able to use Port D for the ATM UTOPIA
so you can have 10/100 and ATM on the same part.  This is really
the purpose of the 857, although I have yet to see anyone use it
that way :-).


	-- Dan


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

Re: MPC8xx, FEC and DP83847 !?

[Wolfgang Denk]

In message <3C9A35AB.9080701@embeddededge.com> Dan Malek wrote:
>
> >> The Motorola reference boards use port D for MII, but we
> >> used PCMCIA/port A pins instead.
>
> If someone is doing this, please send me some patches for the
> driver when you get it working.  All of the 857s I have seen
> are still using Port D for the FEC.  I guess I could make the
> changes if someone else can test them.

Just grab our latest source tarball, and look  at  the  configuration
for the ICU862 board.

> > I supposed you're using PORT D for something else!?
>
> The intention is to also be able to use Port D for the ATM UTOPIA
> so you can have 10/100 and ATM on the same part.  This is really
> the purpose of the 857, although I have yet to see anyone use it
> that way :-).

Well, the ICU862 is such a board, based on a MPC862.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Things that try to look like things often do look  more  like  things
than things. Well-known fact.       - Terry Pratchett, _Wyrd Sisters_

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

RE: MPC8xx, FEC and DP83847 !?

[Jean-Denis Boyer]

Steven,

> I am about to redesign my board and consider to replace Level One's
> LXT971 with National's DP83847.

> Are there any (dis)advantages over the LXT971?

We have experienced many problems using the NS DP83846, on many of our
boards,
even though one model is using the DP83843, and never had problem with it.
We decided to throw away the DP83846 to use the LXT972A instead.
This has fixed many stability problems we have had.

Well, the DP83847 looks more recent, so I can not say about its stability.
We have spent too much effort... :-(

Some advantages for the LXT972A?
- The price was a bit cheaper for us, but that may
  depend on the quantities (I don't have this information).
- The DP83847 can not drive an external IRQ on the PPC, while LXT can.
- The LXT972A can drive 3 LEDs. The LED behavior is easy to configure and
  is very versatile. It perfectly suited our needs, since we use
  only 1 LED to display both the link state and the activity
  (as many hubs do). The DP83847 outputs 6 LEDs with dedicated behavior.
  To combine the link, rx and tx, you need additional hardware.

> Is anyone using National's Phyter DP83846/7 together with MPC8xx FEC?

However, I have added to the 8xx FEC driver the support for the DP83846.
I can give it to you, just ask.

Hope this information helps!

--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------


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

RE: MPC8xx, FEC and DP83847 !?

[Jean-Denis Boyer]

Steven,

> > - The DP83847 can not drive an external IRQ on the PPC,
> while LXT can.
> So does that mean, that the kernel can't detect link changes?
Exactly!

However, I have added a call back, driven by the timer interrupt,
to periodically check for link changes. Of course, it can not
be detected as fast as with interrupt, but it will be correct
in most applications.

Detecting link changes at run-time is not absolutely neccessary,
except for the duplex mode, because the FEC must be aware of it.

> Is there any special reason why your code is not in a recent
> kernel (e.g DENX)?
You are the first one to ask for it ;-)
Really, I have sent it in the past (without the timer call back),
along with a bug fix. But someone at MVista (Tom Rini, I think),
decided not to integrate it for now, since only a few (or no) people
were using it, and it did not follow extensive testing.

And BTW, Mr. Denx just asked me for the patch a few minutes ago.


Another cool thing I have added to the 8xx FEC driver is the standard IOCTL
interface,
to manipulate the PHY through the mii-tool program (net-tools package).
If someone wants it, I will prepare a patch.

--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

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

RE: MPC8xx, FEC and DP83847 !?

[Jean-Denis Boyer]

> In most cases you can just switch off the whole MDIO stuff  and  rely
> on  autonegotiation; the only thing you lose is a kernel message when
> the link status changes. Of course this requires sane hardware, which
> is not always the case :-(

On full duplex connections, we have experienced problems with
the kernel-level BOOTP/DHCP. The offer returned by the server was not
caught. After investigating, it appeared that even though the PHY
auto-negociated correctly, the FEC was not aware of the full duplex
condition. I had to fix it by correctly reading the duplex mode
from the PHY, since this information should be given to the FEC.

It may also cause a 'working but deficient' communication,
especially under heavy traffic, since the collision detection should
be disabled in full duplex.

--------------------------------------------
 Jean-Denis Boyer, B.Eng., System Architect
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-8749 x241
--------------------------------------------

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