• 状态
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 16 订户
  • 视图 8076 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Gong Huang
Expert 1020 points


大家好，

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

谢谢！

  • 0
    TI__Mastermind 45260 points

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

  • 0
    Prodigy 250 points

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

  • 0 回复 kedacom
    TI__Mastermind 45260 points

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

  • 0
    TI__Genius 10941 points

    由于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下调试也是确认以上三点

  • 0 回复 Gary Wu
    Prodigy 120 points

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

  • 0 回复 Gary Wu
    Intellectual 916 points

    我采用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 5001
    Receiving 1470 byte datagrams
    UDP 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

  • 0 回复 Richard.T
    TI__Mastermind 25020 points

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

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

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

  • 0 回复 Steven Liu1
    Intellectual 916 points

    嗯，原来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 duplex
    Using cpsw device
    host 192.168.1.72 is alive

  • 0 回复 Richard.T
    TI__Mastermind 25020 points

    关于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进行设置。