Date: Mon, 9 Mar 2015 15:19:26 +0900 From: Yonghyeon PYUN <pyunyh@gmail.com> To: Matt Dooner <dclscratch@gmail.com> Cc: freebsd-net@freebsd.org, matt@doonerconsulting.com Subject: Re: cpsw/atphy network drivers Message-ID: <20150309061926.GA975@michelle.fasterthan.com> In-Reply-To: <CAJi99x3QuM2rh4OZBJMCSB3%2BU2Gkaqh6EUiax54PV8cR5ZxaWg@mail.gmail.com> References: <CAJi99x3QuM2rh4OZBJMCSB3%2BU2Gkaqh6EUiax54PV8cR5ZxaWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 06, 2015 at 12:45:22PM +0000, Matt Dooner wrote: > Hello, > > I am having some trouble configurating the network driver on a TI > T335x-based CoM system > (http://www.compulab.co.il/products/computer-on-modules/cm-t335/). It > uses the "the AM335x integrated Ethernet MAC coupled with the AR8033 > RGMII Ethernet PHY from Atheros". U-Boot is able to find the device as > expected: > > CM-T335w # mii device > MII devices: 'cpsw' > Current device: 'cpsw' > > CM-T335w # mdio list > cpsw: > 0 - AR8031/AR8033 <--> cpsw > > CM-T335w # dhcp > link up on port 0, speed 100, half duplex > BOOTP broadcast 1 > DHCP client bound to address 10.1.192.67 > CM-T335w # ping 8.8.8.8 > link up on port 0, speed 100, half duplex > Using cpsw device > host 8.8.8.8 is alive > [...] > root@beaglebone:~ # ifconfig > cpsw0: flags=8847<UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST> metric > 0 mtu 1500 > options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE> > ether 1c:ba:8c:ed:40:99 > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > 09:58:57 cpsw_ifmedia_sts > 09:58:57 cpsw_ifmedia_sts > 09:58:57 cpsw_ifmedia_sts > media: Ethernet autoselect (100baseTX <half-duplex>) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Given that you get a half-duplex link, I guess there is speed or duplex mismatch with link partner. Does link partner also agree on the established link speed/duplex? If this is not the case, you may be able to see alignment errors or CRC errors via H/W MAC statistics counters. Quick reading the code indicates that cpsw(4) exports sysctl stat nodes(dev.cpsw.%d.stats). If link partner also supports H/W MAC statistics counters you can consult the info on the link partner. If the issue is really speed/duplex mismatch issue, probably you can try one of the following. - If you have manual media configuration for cpsw(4), use auto. - If link partner uses fixed speed/duplex instead of auto, use the same media configuration on cpsw(4). - If neither helps, try unplugging the UTP cable and wait a couple of seconds then plug it again. It seems there is no miibus_statchg handler in cpsw(4) so I guess cpsw(4) may not be able to program some MAC parameters including duplex when established link is not that of the cpsw(4) assumes. So it would be best to manually set link parameters on both link parter and cpsw(4) to use the same link configuration(100Mbps, full-duplex). > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 > options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> > > When connected to another computer running Wireshark no frames are > recorded as having been transmitted over the interface. The cpsw > driver never reports receiving any packets, even when I use a tool > like Ostinato to craft frames addressed to the MAC of the NIC on the > board. > > The network interface works perfectly in Debian Linux: > Fixing the link state change handling as well as promiscuous mode handling seem to need more work.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150309061926.GA975>