Hello, Thank you for your reply. Confirming the link configuration was a good exercise, but I think I've been able to rule it out as the issue. 100baseTX <half-duplex> appears to be the configuration request by the switch the board was plugged into. I have connected the 335x board directly to two other systems (windows and freebsd) and the correct configuration is negotiated when either or both are set to auto (If I change the configuration on one machine the other updates its configuration accordingly). I have also tested setting the link manually on both systems. I have also confirmed that my two other systems can connect with each other and the switch.
I've connected the 335x board directly to another FreeBSD 10.1 (desktop) system. The desktop uses the fxp-miibus-inphy driver combo. I ifconfig 192.168.0.1 255.255.255.0 and ifconfig 192.168.0.2 255.255.255.0 each system respectively. I also setup default routes between them. When I create traffic (ping) on either machine I see the following incremented on the 335x: dev.cpsw.0.stats.GoodTxFrames: 64 dev.cpsw.0.stats.BroadcastTxFrames: 64 dev.cpsw.0.stats.RxTx65to127OctetFrames: 64 and on the desktop: dev.fxp.0.status.tx.good_frames: 3 All other stats on both the 335x and desktop are zero. I am able to follow similar steps to build a working network between the desktop and a windows laptop. Do you know if atphy(4) has been previously tested to work on the AR8033 or even the AR8031? miidevs only has an entry for AR8021. I've only found limited information about the PHY being used, but its from OpenBSD and the wrong cpu type. These is also a note in the change logs about this hardware "Added atphy(4) to armv7, for the Atheros AR8031 phys in the AM335x starter kit." (http://www.openbsd.org/plus57.html) openbsd-current sys\arch\armv7\imx\imxenet.c: 466: case BOARD_ID_IMX6_WANDBOARD: /* AR8031 */ 467 /* disable SmartEEE */ 468 imxenet_miibus_writereg(dev, phy, 0x0d, 0x0003); ... 472 imxenet_miibus_writereg(dev, phy, 0x0e, reg & ~0x0100); 473 474: /* enable 125MHz clk output for AR8031 */ 475 imxenet_miibus_writereg(dev, phy, 0x0d, 0x0007); 476 imxenet_miibus_writereg(dev, phy, 0x0e, 0x8016); The board vendor emphasises that RGMII must be setup properly: "It is important configure pin mux and work mode to RGMII mode." It seems that some additional driver development will likely be required. Thanks, Matt On 9 March 2015 at 06:19, Yonghyeon PYUN <pyu...@gmail.com> wrote: > 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. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
