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.

AM4372: What's reason it can find the address 0 PHY?

Genius 13655 points
Part Number: AM4372

Hello,

Customer used his own am4372 board, u-boot 2013.10,  below is the PinMUX for rmii in mux.c:

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 pinmux:

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},

};

In u-boot, use mii command, it can find two PHY, but in fact there is only one ethernet with PHY address: 3. 

Linux version is 4.19.94,mii configuration in dts:

In kernel, MDIO find two PHY too. 

What's reason it can find the address 0 PHY?

Thanks.
Rgds

Shine

  • Hi, 

    Which SDK or Linux kernel is being used for the custom board?

    This does appear odd since only one PHY is on the board but both u-boot and the kernel are reporting seeing two phys. Is the cpsw intended to be in switch mode? Is communication working in this condition?

    Please attach the results from this link on Ethernet triage.

    Best Regards,

    Schuyler

  • Hi Schuyler,

    Thanks for your support. 

    The SDK is ti-processor-sdk-linux-rt-am437x-evm-06.03.00.106-Linux-x86-Install.bin, the version of Linux kernel is 4.19.94.

    Customer doesn't want to set cpsw in switch mode. He configured the dts according to am437x-gp-evm.dts, the PHY address is set to 3 by hardware.

    It is abnormal when setting the phy address to 0, it is able to ping the target of the PC, but a lot of packets are lost; When setting
    the phy address to 3, it is also able to ping the target of the PC, a lot of packets are also lost.

    Thanks.
    Rgds
    Shine

  • Hi,

    I agree that is not correct to see two PHYs listed if there in one PHY on the board. This could be a board issue. In the link in the previous post is a request to provide the results of the statistics of the MAC. Typically this would ethtool -S eth0. This can be used to see what kind of errors are happening that could be causing the packet loss. 

    Please provide the information requested in the previous post.

    Best Regards,

    Schuyler

  • Hi Schuyler,

    Below is the 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]#

  • Hi,

    The errors that are highlighted in the grep command are indicating a HW problem with the board or the PHY. Is this the first time Linux is running on this board?

    These errors reported by the MAC statistics could indicate a PHY not in a proper operating state, a cabling issue or a board layout issue. 

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

    I would recommend contacting the PHY manufacturer for debug support on the PHY.

    Best Regards,

    Schuyler

  • Hi Schuyler,

    It is the first time Linux is running on this board. uboot can boot file via TFTP, there is no missing data.

    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#

    Thanks.
    Rgds
    Shine

  • Hi Schuyler,

    Customer has contacted Realtek FAE to confirm that the PHY RTL8201FI-VC-CG circuit and layout are correct. 

    Besides, he found below 2 posts which are similar to his problem, but they have not been resolved yet. 

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

    The PHY address is 1, but found 2 addresses: 0 and 1. 

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

    The PHY addresses are  1 and 5, but found 3 addresses: 0, 1 and 5. 

    He used to use KSZ9031 PHY on older version SDK and it works correctly. But when he used RTL8201F on the same older version SDK, it can't work correctly. 

    Customer wanted to confirm if the SDK doesn't support RMII and MII PHY? If it doesn't support, he has to use the RGMII PHY(KSZ9031) design.

    Thanks.
    Rgds
    Shine