Re: Tri-mode auto-negotiation on ML405
Hi Peter, Peter Mendham wrote: > Andrei Konovalov wrote: > >> And I've tried the PHY library (drivers/net/phy/*) introduced by Andy >> Fleming. >> Kinda works. [...] >> 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). > > Hi Andrei, > > I've now had a chance to have a go at the adapter.c you sent properly > (sorry about the delay). I'm afraid I can't get it to work. I was > wondering if you could tell me what I'm doing wrong. When I try and > bring the interface up I get: > SIOCSIFADDR: No such device > SIOCSIFNETMASK: No such device > SIOCSIFBRDADDR: No such device > SIOCGIFFLAGS: No such device > route: SIOC[ADD|DEL]RT: No such device > > I have included PHYLIB and even tried including support for the Marvell > PHY. I still get the same. I'm sure I've made a stupid mistake, any ideas? Has the ethernet device been registered on the platform bus? There should be a call to platform_device_register() in arch/ppc/syslib/virtex_devices.c or arch/ppc/platforms/4xx/virtex.c depending on the kernel tree used and the patches appiled. Thanks, Andrei > Thanks, > -- Peter > > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Tri-mode auto-negotiation on ML405
Andrei Konovalov wrote: > Has the ethernet device been registered on the platform bus? > There should be a call to platform_device_register() > in arch/ppc/syslib/virtex_devices.c or arch/ppc/platforms/4xx/virtex.c > depending > on the kernel tree used and the patches appiled. Hi Andrei, Drat. I forgot to put that back in when I went to Grant Likely's latest patchset. The errors I am getting now are (when I try and bring the network up): eth0: XTemac Options: 0xbcf0 eth0: XTemac could not start device. SIOCSIFFLAGeth0: XTemac Options: 0xbcf0 eth0: XTemac could not start device. S: Device or resource busy SIOCSIFFLAGS: Device or resource busy route: SIOC[ADD|DEL]RT: Network is unreachable During boot it said: eth%d: XTemac using fifo direct interrupt driven mode. mdiobus_reset on eth%d temac_mii: probed eth%d: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1) eth0: Xilinx TEMAC #0 at 0x8000 mapped to 0xC502, irq=0 eth0: XTemac id 1.0f, block id 5, type 8 It seems like it's finding the MAC and PHY OK, what else have I done wrong? Thanks, -- Peter -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Tri-mode auto-negotiation on ML405
Andrei Konovalov wrote: > And I've tried the PHY library (drivers/net/phy/*) introduced by Andy > Fleming. > Kinda works. [...] > 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). Hi Andrei, I've now had a chance to have a go at the adapter.c you sent properly (sorry about the delay). I'm afraid I can't get it to work. I was wondering if you could tell me what I'm doing wrong. When I try and bring the interface up I get: SIOCSIFADDR: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device SIOCGIFFLAGS: No such device route: SIOC[ADD|DEL]RT: No such device I have included PHYLIB and even tried including support for the Marvell PHY. I still get the same. I'm sure I've made a stupid mistake, any ideas? Thanks, -- Peter -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Tri-mode auto-negotiation on ML405
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
/*
* adapter.c
*
* Xilinx Ethernet Adapter component to interface XTemac component to Linux
*
* Author: MontaVista Software, Inc.
* [EMAIL PROTECTED]
*
* 2002-2007 (c) MontaVista, Software, Inc. This file is licensed under the
* terms of the GNU General Public License version 2.1. This program is
* licensed "as is" without any warranty of any kind, whether express
* or implied.
*/
/*
* This driver is a bit unusual in that it is composed of two logical
* parts where one part is the OS independent code and the other part is
* the OS dependent code. Xilinx provides their drivers split in this
* fashion. This file represents the Linux OS dependent part known as
* the Linux adapter. The other files in this directory are the OS
* independent files as provided by Xilinx with no changes made to them.
* The names exported by those files begin with XTemac_. All functions
* in this file that are called by Linux have names that begin with
* xtenet_. The functions in this file that have Handler in their name
* are registered as callbacks with the underlying Xilinx OS independent
* layer. Any other functions are static helper functions.
*
* Current Xilinx Trimode EMAC device version this adapter supports does
* not have MII/GMII interface, and this adapter assumes that the PHY
* connecting the Trimode EMAC to the ethernet bus runs at 1Gbps, has
* Full duplex turned on and PHY link is always on.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "xbasic_types.h"
#include "xtemac.h"
#include "xipif_v1_23_b.h"
/* Must be shorter than length of ethtool_drvinfo.driver field to fit */
#define DRIVER_NAME "xilinx_temac"
#define DRIVER_VERSION "2.00b/1.00" /* "level 1 ver."/"adapter ver." */
#define DRIVER_DESCRIPTION "Xilinx Tri-Mode Eth MAC driver"
MODULE_AUTHOR("MontaVista Software, Inc. <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION(DRIVER_NAME);
MODULE_LICENSE("GPL");
#d
Tri-mode auto-negotiation on ML405
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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
