AM335x 网口芯片从 AR8035 改为 LAN8710， 无法ping通

大家好，

         参照EBEST的DEVKIT8600和BeagleBone的设计， 将DEVKIT8600上的PHY由AR8035更改为LAN8710，不知软件哪些地方要做修改。

谢谢！

Jian Zhou：

我们TI发布的SDK软件包里面包含了对beaglebone支持，包含了LAN8710的driver。

kedacom：

用的什么接口 rmii还是mii  gmii_sel改没改 mac_control改没改 pinmux做没做 phy_id改没改

Jian Zhou：

回复 kedacom:

beaglebone上的8710是MII模式的，你的硬件是参考beaglebone做的吗？

Gary Wu：

由于TI的SDK包中使用的general PHY driver，所以修改很简单，更明确地说，是确认配置。

使用LAN8710，可以在u-boot中配置板子类型的使用调用beaglebone的配置，前提是MII接口。如果换成RMII，则需要修改PINMUX.

妥当一些的话，就照着如下部分进行检查：

如u-boot下主要确认三点：

1）Program GMII_SEL in control module with 0x5 for RMII Interface

2）Pinmux configuration to support rmii interface

3）Phy ID setting in Platform data（由PHY的硬件电路决定，通过在PHY_ID的三个管脚上下拉来决定）

Linux下调试也是确认以上三点

jinfei wang：

回复 Gary Wu:

我也是使用LAN8710 RMII。可是uboot就是打印phy not found ，我调试打印信息，mdio扫描，phy没有应答。可以提供一份lan8710 RMII的应用实例吗？

Richard.T：

回复 Gary Wu:

我采用RMII连接方式，把lan8710a的3个phy id引脚全下拉，那软件上在哪里改id，内核为3.14.43？现在内核打印id号为net eth0: phy found : id is : 0x7c0f1

这正常吗？正在能ping能，但是测试丢包率很大。在u-boot下tftp也会卡住，无法传文件。

 iperf -s -u -i 2————————————————————Server listening on UDP port 5001Receiving 1470 byte datagramsUDP buffer size:  208 KByte (default)————————————————————[  3] local 192.168.1.72 port 5001 connected with 192.168.1.235 port 43667[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams[  3]  0.0- 2.0 sec  22.5 MBytes  94.5 Mbits/sec   0.255 ms  197/16276 (1.2%)[  3]  2.0- 4.0 sec  22.0 MBytes  92.1 Mbits/sec   0.166 ms  616/16277 (3.8%)[  3]  4.0- 6.0 sec  22.8 MBytes  95.7 Mbits/sec   0.077 ms    2/16276 (0.012%)[  3]  6.0- 8.0 sec  22.8 MBytes  95.7 Mbits/sec   0.113 ms    1/16275 (0.0061%)[  3]  8.0-10.0 sec  22.8 MBytes  95.7 Mbits/sec   0.093 ms    4/16278 (0.025%)[  3] 10.0-12.0 sec  22.8 MBytes  95.7 Mbits/sec   0.209 ms    2/16276 (0.012%)[  3] 12.0-14.0 sec  22.8 MBytes  95.6 Mbits/sec   0.088 ms    6/16272 (0.037%)[  3] 14.0-16.0 sec  22.2 MBytes  92.9 Mbits/sec   0.090 ms  479/16279 (2.9%)[  3] 16.0-18.0 sec  22.8 MBytes  95.7 Mbits/sec   0.140 ms    6/16274 (0.037%)[  3] 18.0-20.0 sec  22.8 MBytes  95.6 Mbits/sec   0.347 ms   16/16277 (0.098%)[  3] 20.0-22.0 sec  21.9 MBytes  92.0 Mbits/sec   0.087 ms  627/16281 (3.9%)[  3] 22.0-24.0 sec  22.5 MBytes  94.4 Mbits/sec   0.156 ms  227/16276 (1.4%)[  3] 24.0-26.0 sec  22.8 MBytes  95.6 Mbits/sec   0.069 ms   14/16276 (0.086%)[  3] 26.0-28.0 sec  22.8 MBytes  95.5 Mbits/sec   0.189 ms   29/16277 (0.18%)[  3] 28.0-30.0 sec  21.6 MBytes  90.5 Mbits/sec   0.078 ms  891/16276 (5.5%)[  3] 30.0-32.0 sec  21.3 MBytes  89.4 Mbits/sec   0.101 ms 1064/16276 (6.5%)[  3] 32.0-34.0 sec  21.9 MBytes  91.7 Mbits/sec   0.251 ms  681/16277 (4.2%)[  3] 34.0-36.0 sec  22.5 MBytes  94.5 Mbits/sec   0.191 ms  204/16277 (1.3%)[  3] 36.0-38.0 sec  21.7 MBytes  91.1 Mbits/sec   0.085 ms  786/16276 (4.8%)[  3] 38.0-40.0 sec  22.2 MBytes  93.0 Mbits/sec   0.136 ms  460/16276 (2.8%)[  3] 40.0-42.0 sec  22.1 MBytes  92.9 Mbits/sec   0.168 ms  480/16277 (2.9%)[  3] 42.0-44.0 sec  22.8 MBytes  95.6 Mbits/sec   0.075 ms    9/16276 (0.055%)[  3] 44.0-46.0 sec  22.2 MBytes  92.9 Mbits/sec   0.106 ms  473/16277 (2.9%)[  3] 46.0-48.0 sec  22.8 MBytes  95.6 Mbits/sec   0.263 ms    9/16276 (0.055%)[  3] 48.0-50.0 sec  22.8 MBytes  95.7 Mbits/sec   0.129 ms    4/16277 (0.025%)[  3] 50.0-52.0 sec  22.5 MBytes  94.3 Mbits/sec   0.072 ms  247/16276 (1.5%)[  3] 52.0-54.0 sec  22.8 MBytes  95.7 Mbits/sec   0.187 ms    4/16277 (0.025%)[  3] 54.0-56.0 sec  22.8 MBytes  95.6 Mbits/sec   0.226 ms    6/16262 (0.037%)[  3] 56.0-58.0 sec  22.6 MBytes  94.7 Mbits/sec   0.143 ms  184/16290 (1.1%)[  3] 58.0-60.0 sec  22.8 MBytes  95.7 Mbits/sec   0.126 ms    2/16276 (0.012%)[  3]  0.0-60.0 sec   674 MBytes  94.2 Mbits/sec   0.380 ms 7729/488357 (1.6%)

[  3]  0.0-60.0 sec  1 datagrams received out-of-order

Steven Liu1：

回复 Richard.T:

我们驱动中，SKEVM板上默认的PHY_ID就是设置为0的，在RGMII1上。RGMII2的PHY_ID是2，如果没有第二个网口就没所谓了。

你的情况不像是PHY_ID设置错误，如果是PHY_ID设置错误的话，你应该是通讯不上的。现在丢包率比较高，但是能ping通的话。

我建议先确认硬件山上的几个设计：一个是时钟是否使用的外部，一个是布线是否遵循的上面提到的一些规则。软件上能做的测试话，可以尝试把自协商固定为10M来通讯，如果这样丢包率明显小了，或者能TFTP了，能从一定程度上说明这个板子目前的通路和驱动是好的，但是可能由于信号完整性等问题导致通讯失败，需从硬件上进行改善。

Richard.T：

回复 Steven Liu1:

嗯，原来phy_ID是多网卡用的啊。我们也猜测是硬件问题，有关于phy布线要求的相关资料吗？谢谢。另外如何强制10M通讯，我在u-boot中添加代码：

    const char *devname;    u32 reg;    devname = miiphy_get_current_dev();    miiphy_read(devname,0,LAN8710_PHY_Special_Modes_ADDR_REG,&reg);    reg &= ~(0x7 << 5);    reg |= (0x1 << 5);// 10M    miiphy_write(devname,0,LAN8710_PHY_Special_Modes_ADDR_REG,reg);    printf("lan8710 mode =  0x%x \n", reg);

但是，ping的时候仍然显示 使用100M传输。

link up on port 0, speed 100, full duplexUsing cpsw devicehost 192.168.1.72 is alive

Steven Liu1：

回复 Richard.T:

关于PHY这块的布线设计的话，一般是根据PHY芯片厂商提供的手册来进行。

像TI的DP83848，可以参考这个链接里面的介绍：http://www.deyisupport.com/question_answer/dsp_arm/sitara_arm/f/25/t/45981.aspx

还有一个参考就是DATASHEET手册。

强制改10M的话，印象中是用MDIO write的方式来写PHY侧的寄存器，来指定他工作的方式。

以DP83848为例，在BMCR的12 bit就可以把这个关掉，在13 bit进行设置。