From owner-freebsd-net@FreeBSD.ORG Mon Mar 9 06:19:36 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EED1B11 for ; Mon, 9 Mar 2015 06:19:36 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6816E310 for ; Mon, 9 Mar 2015 06:19:36 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so55400100pdb.7 for ; Sun, 08 Mar 2015 23:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nrcR63QqncDaQDrF72I0sIl6n8vDX0lPPRT7S9iB2GQ=; b=LCA2VzgPI/13KJ96fictxDpgYqT20G9zCazKBwOlQPiFULVGUbAZo5z+kdjYbaQZf7 nhW9X6ZtZqIOnPXRJDEzD8zNU1Q1kfZehne62Slq2PmjV0wTr0B2zVeLCfYGp//bRPaF QpKsehQQSch69KRUeilG9dEosi2JNfZa5rprExvt4t5vCYC9y4defxpRIl4EWiAUgQ5k mBUTZ4Oxu5Go/2+rEABmQ+oygMyYXP/IbrQ7uZefy5UeFakz+fSEvf+WLCTSQ6Tibq1d D5CmzKlKuS79KzYtBJFXZYaF0Qa46PNIfti3QxWRPwMwkHGvBY1pGsTk06RG3i78WOS6 i2lw== X-Received: by 10.66.233.74 with SMTP id tu10mr50061213pac.135.1425881975700; Sun, 08 Mar 2015 23:19:35 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id pu9sm3242282pdb.49.2015.03.08.23.19.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Mar 2015 23:19:34 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 09 Mar 2015 15:19:26 +0900 Date: Mon, 9 Mar 2015 15:19:26 +0900 To: Matt Dooner Subject: Re: cpsw/atphy network drivers Message-ID: <20150309061926.GA975@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, matt@doonerconsulting.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 06:19:36 -0000 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 metric > 0 mtu 1500 > options=8000b > 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 ) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > > 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.