[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Some thoughts on ethernet.c



Hi,

>There seems to be a "feature" in ethernet.c that it just reads data from
>MDIO address 0 to detect whether full duplex is on or not.

Yes, the MDIO should really be probed instead of assuming 0. Every
ETRAX based hardware I have seen uses address 0 but of course some
customers may choose to set it differently.

>First I thought to make some kind of an auto detect for the PHY address,
but
>it made no sense as the position of the full duplex bit seems to be
>different for each vendor. Beware.

There is a general bit indicating duplex (don't remember exactly which
bit it is now). The problem is that this bit doesn't work as I expect
in Broadcom transceivers. This has to be solved by reading the chip
id (available in MDIO registers) and treat them differently.

>What happens is that the PHY is told to output a bit, and Etrax reads it
>right away. It depends on the PHY whether the data line has enought time to
>settle or not. On our board this resulted in plain garbage to be read back
>most of the time. Moving the udelay call where it should be solved the
>problem.

Ok, thanks.

I will put these issues on my TODO list.


Thanks for the input
/Mikael


-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Jarkko Tuomi
Sent: Thursday, July 04, 2002 9:31 PM
To: dev-etrax
Subject: Some thoughts on ethernet.c



There seems to be a "feature" in ethernet.c that it just reads data from
MDIO address 0 to detect whether full duplex is on or not. Our PHY was at
another address, so Etrax always got 0xffff, and turned full duplex on when
it shouldn't. This resulted in very strange network behaviour. For example
ftp control connection was very quickly established, but the data connection
took ages.

First I thought to make some kind of an auto detect for the PHY address, but
it made no sense as the position of the full duplex bit seems to be
different for each vendor. Beware.

---

There also seems to be a bug in e100_receive_mdio_bit()

*R_NETWORK_MGM_CTRL = 0;
bit = IO_EXTRACT(R_NETWORK_STAT, mdio, *R_NETWORK_STAT);
udelay(1);

What happens is that the PHY is told to output a bit, and Etrax reads it
right away. It depends on the PHY whether the data line has enought time to
settle or not. On our board this resulted in plain garbage to be read back
most of the time. Moving the udelay call where it should be solved the
problem.

*R_NETWORK_MGM_CTRL = 0;
udelay(1);
bit = IO_EXTRACT(R_NETWORK_STAT, mdio, *R_NETWORK_STAT);

Those looking for near-real-time performance might also want to make the
delay shorter, just check your PHY datasheet.

---

And finally a tip for people like us who are using a PHY that powers up with
the MII-interface isolated: Put series resistors on Etrax MDIO pins and use
a small microcontroller to turn the PHY on for flashing. Then it also
doubles as a real-time clock and/or an extra serial port :-)



Best regards,

Jarkko

--
Jarkko Tuomi jtuomi@xxxxxxx.fi/~jtuomi/">http://www.hut.fi/~jtuomi/
EMACS - Escape Meta Alt Control Shift