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.

am437x u-boot mii能够找到两个以太网Phy

Other Parts Discussed in Thread: AM4372, TPS65218

Ti的技术支持:你好!

我在调试am4372的定制板,在u-boot(版本号是2013.10)的mux.c中将以太网rmii接口的PinMux引脚配置如下:

static struct module_pin_mux henry_rmii1_pin_mux[] = {

       {OFFSET(mii1_txd1), MODE(1)},                 /* RMII1_TD1 */

       {OFFSET(mii1_txd0), MODE(1)},                 /* RMII1_TD0 */

       {OFFSET(mii1_rxd1), MODE(1) | RXACTIVE},      /* RMII1_RD1 */

       {OFFSET(mii1_rxd0), MODE(1) | RXACTIVE},      /* RMII1_RD0 */

       {OFFSET(mii1_crs), MODE(1) | RXACTIVE},        /* RMII1_CRS_DV */

       {OFFSET(mii1_txen), MODE(1)},                 /* RMII1_TXEN */

       {OFFSET(mii1_rxerr), MODE(1) | RXACTIVE},      /* RMII1_RXERR */

       {OFFSET(rmii1_refclk), MODE(0) | RXACTIVE},    /* RMII1_refclk */

       {-1},

};

MDIO引脚配置如下:

static struct module_pin_mux mdio_pin_mux[] = {

       {OFFSET(mdio_data), MODE(0) | RXACTIVE | PULLUP_EN},/* MDIO_DATA */

       {OFFSET(mdio_clk), MODE(0) | PULLUP_EN},     /* MDIO_CLK */

       {-1},

};

u-boot运行起来,在u-boot中,通过mii命令,在MDIO总线上,能够扫描到两个以太网Phy,而实际只有Phy地址为3的那个以太网,命令如下所示:

在Linux系统,版本为4.19.94,将rmii的设备树配置如下:

Linux的启动日志中,也通过MDIO总线扫描到了两个Phy,日志信息如下:

     请技术支持看看这个具体是什么原因造成,为什么会扫描到Phy地址0的设备?

  • 图片显示不出来,请点击右下角的“使用高级编辑器编辑文本”插入图片,谢谢!
  • Ti技术支持:你好!由于图片没有上传,我重新编辑一次

    我在调试am4372的定制板,在u-boot(版本号是2013.10)的mux.c中将以太网rmii接口的PinMux引脚配置如下:

    static struct module_pin_mux henry_rmii1_pin_mux[] = {

           {OFFSET(mii1_txd1), MODE(1)},                 /* RMII1_TD1 */

           {OFFSET(mii1_txd0), MODE(1)},                 /* RMII1_TD0 */

           {OFFSET(mii1_rxd1), MODE(1) | RXACTIVE},      /* RMII1_RD1 */

           {OFFSET(mii1_rxd0), MODE(1) | RXACTIVE},      /* RMII1_RD0 */

           {OFFSET(mii1_crs), MODE(1) | RXACTIVE},        /* RMII1_CRS_DV */

           {OFFSET(mii1_txen), MODE(1)},                 /* RMII1_TXEN */

           {OFFSET(mii1_rxerr), MODE(1) | RXACTIVE},      /* RMII1_RXERR */

           {OFFSET(rmii1_refclk), MODE(0) | RXACTIVE},    /* RMII1_refclk */

           {-1},

    };

    MDIO引脚配置如下:

    static struct module_pin_mux mdio_pin_mux[] = {

           {OFFSET(mdio_data), MODE(0) | RXACTIVE | PULLUP_EN},/* MDIO_DATA */

           {OFFSET(mdio_clk), MODE(0) | PULLUP_EN},     /* MDIO_CLK */

           {-1},

    };

    u-boot运行起来,在u-boot中,通过mii命令,在MDIO总线上,能够扫描到两个以太网Phy,而实际只有Phy地址为3的那个以太网,命令如下所示:

     

    在Linux系统,版本为4.19.94,将rmii的设备树配置如下:

    Linux的启动日志中,也通过MDIO总线扫描到了两个Phy,日志信息如下:

    请技术支持看看这个具体是什么原因造成,为什么会扫描到Phy地址0的设备?

  • 请看一下下面e2e帖子的回复。
    e2e.ti.com/.../3516749
  • My SDK is from ti-processor-sdk-linux-rt-am437x-evm-06.03.00.106-Linux-x86-Install.bin, the version of Linux kernel is 4.19.94.
    I don't want to set cpsw in switch mode, I config the dts accroding to am437x-gp-evm.dts, the PHY address is set to 3 by hardware.

    It is abnormal, when set the phy address to 0, it is able to ping the target of my PC, but a lot of packets are lost; when set
    the phy address to 3, it is also able to ping the target of my PC, a lot of packets are also lost.
  • 请看一下下面e2e帖子的回复。
    e2e.ti.com/.../3516749

    建议用下面wiki网站上的方法ethtool -S eth0看一下网口的状态来判断是什么错误。
    processors.wiki.ti.com/.../5x_CPSW
  • The following is my log when ping the local target:
    [root@nud bin]# ping 192.168.1.222
    PING 192.168.1.222 (192.168.1.222): 56 data bytes
    64 bytes from 192.168.1.222: seq=0 ttl=128 time=0.982 ms
    64 bytes from 192.168.1.222: seq=1 ttl=128 time=0.840 ms
    64 bytes from 192.168.1.222: seq=3 ttl=128 time=1.002 ms
    64 bytes from 192.168.1.222: seq=5 ttl=128 time=1.257 ms
    64 bytes from 192.168.1.222: seq=7 ttl=128 time=0.828 ms
    64 bytes from 192.168.1.222: seq=9 ttl=128 time=0.713 ms
    64 bytes from 192.168.1.222: seq=11 ttl=128 time=0.917 ms
    64 bytes from 192.168.1.222: seq=14 ttl=128 time=0.804 ms
    ^C
    --- 192.168.1.222 ping statistics ---
    16 packets transmitted, 8 packets received, 50% packet loss
    round-trip min/avg/max = 0.713/0.917/1.257 ms
    [root@nudt bin]# ./ethtool -S eth0
    NIC statistics:
    Good Rx Frames: 70
    Broadcast Rx Frames: 21
    Multicast Rx Frames: 32
    Pause Rx Frames: 0
    Rx CRC Errors: 18
    Rx Align/Code Errors: 31
    Oversize Rx Frames: 0
    Rx Jabbers: 0
    Undersize (Short) Rx Frames: 0
    Rx Fragments: 22
    Rx Octets: 11644
    Good Tx Frames: 52
    Broadcast Tx Frames: 3
    Multicast Tx Frames: 12
    Pause Tx Frames: 0
    Deferred Tx Frames: 0
    Collisions: 0
    Single Collision Tx Frames: 0
    Multiple Collision Tx Frames: 0
    Excessive Collisions: 0
    Late Collisions: 0
    Tx Underrun: 0
    Carrier Sense Errors: 0
    Tx Octets: 4758
    Rx + Tx 64 Octet Frames: 19
    Rx + Tx 65-127 Octet Frames: 113
    Rx + Tx 128-255 Octet Frames: 12
    Rx + Tx 256-511 Octet Frames: 2
    Rx + Tx 512-1023 Octet Frames: 25
    Rx + Tx 1024-Up Octet Frames: 0
    Net Octets: 32729
    Rx Start of Frame Overruns: 0
    Rx Middle of Frame Overruns: 0
    Rx DMA Overruns: 0
    Rx DMA chan 0: head_enqueue: 1
    Rx DMA chan 0: tail_enqueue: 165
    Rx DMA chan 0: pad_enqueue: 0
    Rx DMA chan 0: misqueued: 0
    Rx DMA chan 0: desc_alloc_fail: 0
    Rx DMA chan 0: pad_alloc_fail: 0
    Rx DMA chan 0: runt_receive_buf: 0
    Rx DMA chan 0: runt_transmit_bu: 0
    Rx DMA chan 0: empty_dequeue: 0
    Rx DMA chan 0: busy_dequeue: 32
    Rx DMA chan 0: good_dequeue: 38
    Rx DMA chan 0: requeue: 0
    Rx DMA chan 0: teardown_dequeue: 0
    Tx DMA chan 0: head_enqueue: 50
    Tx DMA chan 0: tail_enqueue: 2
    Tx DMA chan 0: pad_enqueue: 0
    Tx DMA chan 0: misqueued: 2
    Tx DMA chan 0: desc_alloc_fail: 0
    Tx DMA chan 0: pad_alloc_fail: 0
    Tx DMA chan 0: runt_receive_buf: 0
    Tx DMA chan 0: runt_transmit_bu: 9
    Tx DMA chan 0: empty_dequeue: 50
    Tx DMA chan 0: busy_dequeue: 0
    Tx DMA chan 0: good_dequeue: 52
    Tx DMA chan 0: requeue: 0
    Tx DMA chan 0: teardown_dequeue: 0
    [root@nud bin]#
  • [root@nud bin]# ./ethtool eth0
    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Link partner advertised pause frame use: Symmetric Receive-only
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 3
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000000 (0)

    Link detected: yes
    [root@nud bin]#
  • [root@nud bin]# ./ethtool eth0 | egrep 'Speed|Duplex'
    Speed: 100Mb/s
    Duplex: Full
    [root@nud bin]#
    [root@nud bin]#
    [root@nud bin]# ./ethtool -S eth0 | grep CRC
    Rx CRC Errors: 57
    [root@nud bin]#
    [root@nud bin]#
    [root@nud bin]# ./ethtool -S eth0| grep Errors
    Rx CRC Errors: 57
    Rx Align/Code Errors: 85
    Carrier Sense Errors: 0
    [root@nud bin]#
    [root@nud bin]# ./ethtool -g eth0
    Ring parameters for eth0:
    Pre-set maximums:
    RX: 248
    RX Mini: 0
    RX Jumbo: 0
    TX: 248
    Current hardware settings:
    RX: 128
    RX Mini: 0
    RX Jumbo: 0
    TX: 128

    [root@nud bin]#
  • 这些MAC statistics提示的error表示PHY没有正常工作,是板子的硬件问题如PCB layout或者是PHY的问题。这块板子是第一次跑Linux吗?

    Rx CRC Errors: 57
    Rx Align/Code Errors: 85

    建议联系PHY厂家看看是不是PHY的问题。
  • 这个板子是第一个调试。但是在u-boot下能够通过TFTP下载文件,没有发现丢包,日志如下:

    probe PMIC tps65218 failed!
    tps65218_init failed!
    Not found the LCD header IC
    Net: <ethaddr> not set. Validating first E-fuse MAC
    cpsw
    Hit any key to stop autoboot: 0
    U-Boot#
    U-Boot#
    U-Boot#
    U-Boot#
    U-Boot# setenv ipaddr 192.168.1.100
    U-Boot# setenv netmask 255.255.255.0
    U-Boot# setenv serverip 192.168.1.222
    U-Boot#
    U-Boot#
    U-Boot# tftp ${loadaddr} zImage
    link up on port 0, speed 100, full duplex
    Using cpsw device
    TFTP from server 192.168.1.222; our IP address is 192.168.1.100
    Filename 'zImage'.
    Load address: 0x80200000
    Loading: #################################################################
    #################################################################
    #################################################################
    #################################################################
    ##########################################
    445.3 KiB/s
    done
    Bytes transferred = 4424192 (438200 hex)
    U-Boot#
    U-Boot#
    U-Boot# ping 192.168.1.222
    link up on port 0, speed 100, full duplex
    Using cpsw device
    host 192.168.1.222 is alive
    U-Boot#

  • Hi Shine,

    Realtek的FAE检查过我PHY芯片RTL8201FI-VC-CG的原理图和layout设计,确认过没有问题的。

    另外,在论坛里我发现了两篇文章,都是使用了RMII或MII接口的PHY,才出现问题的且问题和我的基本类似,但问题最终都没有得到解决,如下链接:

    1、https://e2e.ti.com/support/processors/f/791/t/686789?tisearch=e2e-sitesearch&keymatch=am437x%252525252520rmii

    这个硬件地址为1,但扫描出来2个地址,0和1;

    2、https://e2e.ti.com/support/processors/f/791/t/881788?tisearch=e2e-sitesearch&keymatch=am437x%25252525252525252520rmii

    这个硬件地址为1和5,但扫描出来3个地址,0、1和5;

    我司出货几年的老产品上是使用了两个RGMII接口PHY(KSZ9031),当时的Linux SDK版本比较低,我用这个低版本SDK包也试过RTL8201F,问题还是一样的。我想确认的是,AM437X的SDK包是不是不支持RMII和MII接口的PHY芯片?如果是的话,我只能改回以前RGMII接口PHY的设计了。

  • 我把您的问题发到e2e上咨询产品工程师,请关注下面的帖子。
    e2e.ti.com/.../3545719