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

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