Tri-mode auto-negotiation on ML405

Andrei Konovalov akonovalov at ru.mvista.com
Sat Apr 14 02:25:49 EST 2007


Hi Peter,

I've had some problems with a self-made "TEMAC in SGDMA mode" design for ML403,
so working with TEMAC in FIFO mode at the moment.

And I've tried the PHY library (drivers/net/phy/*) introduced by Andy Fleming.
Kinda works. The only problem I have no explanation for yet is that after
turning auto-negotiation off (with ethtool), and playing with switching
between 1000/100/10Mbits, I could not make the board to get back to 1000Mbits
(the board simply stops advertising 1000Mbits at some point).

Attached is the incomplete adapter.c (with FIFO mode support only) which
uses the PHY lib to handle the PHY. Just to illustrate the idea (will post the
patch later when it is completed).
It could auto-negotiate faster than the driver you are using, as there are
no explicit 2 second delays. But the things could be even faster if the
auto-negotiation interrupt would be used (this is TBD).

Don't forget to "select PHYLIB" in the drivers/net/Kconfig for TEMAC
if you want to try this approach.

Thanks,
Andrei


Peter Mendham wrote:
> Dear all,
> 
> I have the Xilinx TEMAC (kind of) working on an ML405 using an adapter.c 
> file posted by Rick Moleres on 8th Feb 2007.  However, there are some 
> serious issues with auto-negotiation:
> 1. link negotiation at startup is *very* slow - in the order of ten seconds
> 2. if no network is detected at the boot time the auto-negotiation runs 
> through 1G, 100M, 10M before giving up.  I guess this leaves the PHY in 
> a 10M state.  When I plug a link in the PHY says 10M.  I have 100M and 
> 1G links available (but no 10M link) neither work.
> 3. if a link is present boot time the auto-negotiation correctly chooses 
> the link speed and the link appears to function.  If I unplug the link 
> and replace it with a different speed the link will not function.  If 
> the original link was 100M, the PHY identifies a 1G link as 100M and it 
> does not work.  If the original link was 1G the PHY gives up altogether 
> and no link is detected.
> I guess this all makes sense: it just means that the PHY is not 
> auto-negotiating the link speed.
> 
> Being a newbie at this and really not knowing what I am doing I tried 
> adding a call to set_mac_speed in poll_gmii where a link carrier is 
> detected (after it prints "link carrier restored").  This successfully 
> renegotiated the link speed when a link was inserted, but only in 
> certain cases.  If the link first inserted was 100M, or if there was no 
> link present an inserted link of either 100M or 1G would renegotiate 
> fine.  After having a 100M link, inserting a 1G link would *say* it had 
> renegotiated, the PHY lights up and tells me the link is running at 1G, 
> but nothing works.  Also, whenever this negotiation is going on, 
> everything grinds to a halt.  After having a 1G link, inserting a 100M 
> link would result in the PHY not even picking up the link, as before. 
> 
> I'm clearly barking up the wrong tree here, please can someone tell me 
> The Right Way?
> 
> Many thanks in advance,
> -- Peter
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: adapter.c
Type: text/x-csrc
Size: 28079 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070413/11a12b8a/attachment.c 


More information about the Linuxppc-embedded mailing list