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.

AM4376: Ethernet problem in U-Boot

Part Number: AM4376

Hi

I'm having problem with ethernet connection on my custom board. I can't ping any IP address with 100Mbps or gigabit. The software recognizes the link speed so I think the connections (at least the MDIO) are not the problem.

I'm using KSZ9031 with RGMII interface, same as evaluation boards.

Oh and TXCLK (from MAC) is always 2.5MHz, I think it should be 25MHz for 100 and 125MHz for 1000. The RXCLK (from PHY) is ok and it's 125MHz for 1000 and 25MHz when connected to 100Mbps network.

U-Boot results:

100Mbps Ethernet:

# ping 192.168.0.2
link up on port 0, speed 100, full duplex
Using cpsw device

ARP Retry count exceeded; starting again
ping failed; host 192.168.0.2 is not alive

 

Gigabit Ethernet:

# ping 192.168.0.1
link up on port 0, speed 1000, full duplex
Using cpsw device

ARP Retry count exceeded; starting again
ping failed; host 192.168.0.1 is not alive

Regards,

Robert

  • The software team have been notified. Please post U-boot and kernel version. Also follow this guide and post results: processors.wiki.ti.com/.../5x_CPSW
  • U-Boot is 2016.05
    The kernel is latest that TI provided, 4.9.41
  • Hi Robert,

    The software you mention that says it recognizes the link speed, is it the u-boot mii utility that you are using? Is case you are not familiar with the mii tool in u-boot this training has section on it. Could please attach the output of mii dump 0 0 and mii dump 0 1. The first 0 in the command is the PHY address, you may need to change this to match the PHY address on your board.

    training.ti.com/eth_sys_sw_am_devices slides 17 & 18 talk about the mii utility

    You also mentioned this is a custom board, which emac port are you using? Could please attach a snippet of the schematic showing the emac port and phy connection?

    Regards,
    Schuyler
  • Hi

    Thanks for your reply.
    I'm familiar with mii command in u-boot.
    Here is the results:

    # mii dump 0 0
    0. (1140) -- PHY control register --
    (8000:0000) 0.15 = 0 reset
    (4000:0000) 0.14 = 0 loopback
    (2040:0040) 0. 6,13 = b10 speed selection = 1000 Mbps
    (1000:1000) 0.12 = 1 A/N enable
    (0800:0000) 0.11 = 0 power-down
    (0400:0000) 0.10 = 0 isolate
    (0200:0000) 0. 9 = 0 restart A/N
    (0100:0100) 0. 8 = 1 duplex = full
    (0080:0000) 0. 7 = 0 collision test enable
    (003f:0000) 0. 5- 0 = 0 (reserved)

    # mii dump 0 1
    1. (796d) -- PHY status register --
    (8000:0000) 1.15 = 0 100BASE-T4 able
    (4000:4000) 1.14 = 1 100BASE-X full duplex able
    (2000:2000) 1.13 = 1 100BASE-X half duplex able
    (1000:1000) 1.12 = 1 10 Mbps full duplex able
    (0800:0800) 1.11 = 1 10 Mbps half duplex able
    (0400:0000) 1.10 = 0 100BASE-T2 full duplex able
    (0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
    (0100:0100) 1. 8 = 1 extended status
    (0080:0000) 1. 7 = 0 (reserved)
    (0040:0040) 1. 6 = 1 MF preamble suppression
    (0020:0020) 1. 5 = 1 A/N complete
    (0010:0000) 1. 4 = 0 remote fault
    (0008:0008) 1. 3 = 1 A/N able
    (0004:0004) 1. 2 = 1 link status
    (0002:0000) 1. 1 = 0 jabber detect
    (0001:0001) 1. 0 = 1 extended capabilities

    And also schematic is exactly like AM437x GP EVM down to single details. So it's connected to port 0.

    Regards,
    Robrt
  • Robert,
    Thanks for posting the mii results. As you said the PHY is indicating an auto-negotiated link at 1Gbps. Since your design in based on the GP-EVM then the pin mux shipped with the SDK should match your board requirements.

    Are you able to use Wireshark on the link partner to see if any ARP packets are transmitted? We would like to see if anything shows up on the line. Also could you please attach a copy of the console log?

    The interesting point here is that you are seeing a TX CLK that is 2.5MHz which "seems" to indicate the CPSW driver interrogated the PHY over MDIO and sees a PHY at 10Mbps, not the 1Gbps that the mii utility is showing. This kind of looks like a mis-match of PHY addresses perhaps. So a good step would be to verify that the PHY addresses on the board match what is intended. Since this is a new board you might consided removing the un-used PHY from the MDIO bus, hopefully there are some resistors that could be easily de-poplulated.

    Regards,
    Schuyler
  • There aren't any packets transmitted from the board. I tried connecting directly to a computer and via a switch, both have the same result, no packets.

    Yes, 2.5MHz TXCLK is interesting, as you said maybe CPSW didn't configured properly. I checked the CPSW_SL_MACCTRL register and I think it was configured correctly (0x8021 for 100Mbps and 0xa1 for 1000Mbps). But the CPSW_WR_RGMII_CTL register had the 0 value, it means that the link is down and the speed is 10Mbps!

    I checked the PHY address straps and it's all pull-down and so it's 0 as it should be. And there is only one PHY connected to MAC.

    Edit: Oh the CPSW driver knows the configuration, because it prints the "link up on port %d, speed %d, %s duplex" in the cpsw.c file. It seems that it knows the speed and link status and configures the mac_control accordingly.

  • Hi

    Did you see my answer?

    I couldn't find source of the problem, I checked the straps in board and PHY address in software. It seems that they are not causing the problem.

  • Hi Robert,

    Can please attach the console log for u-boot of the dhcp transaction?

    Is the cpsw printing out the expected speed?

    When packets are sent do you see the data lines to the PHY toggling?

    Do you have a AM437 gp-evm? If you have one could you please check the TX clock?
    Are you able to boot to Linux and check if the ethernet interface is working there?

    I will be out of the office next week. I will ask a fellow team member to review the results of the measured clocking.

    Regards,
    Schuyler
  • Hi

    Thank you Schuyler

    1- DHCP log:

    # dhcp
    link up on port 0, speed 100, full duplex
    BOOTP broadcast 1
    BOOTP broadcast 2
    BOOTP broadcast 3
    BOOTP broadcast 4
    BOOTP broadcast 5
    BOOTP broadcast 6
    BOOTP broadcast 7
    BOOTP broadcast 8
    BOOTP broadcast 9
    BOOTP broadcast 10
    BOOTP broadcast 11
    BOOTP broadcast 12
    BOOTP broadcast 13
    BOOTP broadcast 14
    BOOTP broadcast 15
    BOOTP broadcast 16
    BOOTP broadcast 17
    BOOTP broadcast 18
    BOOTP broadcast 19
    BOOTP broadcast 20
    BOOTP broadcast 21
    BOOTP broadcast 22
    BOOTP broadcast 23
    BOOTP broadcast 24
    BOOTP broadcast 25
    BOOTP broadcast 26
    BOOTP broadcast 27
    BOOTP broadcast 28
    BOOTP broadcast 29

    Retry time exceeded; starting again


    2- Yes, CPSW is printing the expected speed as I said before.

    3- No, data line do not change when I'm pinging for example.

    4- No, Unfortunately I don't have the GP-EVM.

    5- I was able to boot Linux but the networking has the same behavior there.

    Regards,
    Robert

  • Hi Robert,
    You mention 100 and 1000Mb operation, but I don't see mention of 10Mb. Does 10Mb work?
  • Hi

    I don't see why it would work. the MAC doesn't send any data on TX line and it seems it's not configured.
    I don't have a 10Mbps network, and I don't know if it's worth it to test it on 10Mbps network.
  • Robert,
    Could you verify your PinMux settings?
  • Yes
    It's exactly like the GP-EVM and IDK board.
    I checked the pinmux in schematic , U-Boot and DTS file with the datasheet.
  • I even changed the boot configuration to boot with EMAC. It has the same problem, TXCLK is 2.5MHz and there are no toggles on data lines.
    Can I assume it's not the software problem, because the ROM Code has the same behavior, and it's in the hardware?

  • I think I found the problem.
    The RCLK signal from the PHY was not connected to the MPU! I changed the RGMII pinmux to gpio and changed the values to check that if they are changing. one singal, the RCLK, was not changing.
    the problem was in the soldering department and so in the next days I'll test the board again after re-soldering.
  • Robert,
    Thanks for the update. Let us know what you find after the connectivity issues is resolved.
  • Ho

    The problem solved, ethernet is working now in Linux but it's not working in U-Boot.

    It crashes U-Boot:

    ping 192.168.0.60
    link up on port 0, speed 1000, full duplex
    Using cpsw device
    data abort
    pc : [<9ffbc9c6>] lr : [<9ffbcc3b>]
    reloc pc : [<808259c6>] lr : [<80825c3b>]
    sp : 9ef92d30 ip : 0000000e fp : 00000002
    r10: 9ef9e698 r9 : 9ef92ee0 r8 : 00000000
    r7 : 00000001 r6 : 00000000 r5 : 0000002a r4 : 9ffd70ce
    r3 : 14000045 r2 : 3200a8c0 r1 : 9ef92d38 r0 : 9ffd70ce
    Flags: nZcv IRQs off FIQs off Mode SVC_32
    Resetting CPU ...

  • Compiler was causing this error. I unintentionally used GCC 7.1 with u-boot 2016.05.
    So now I don't have problems with the gigabit ethernet.