• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 3190 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

using a Broadcom phy with AM335x on Linux

Adri G
Intellectual 450 points
Other Parts Discussed in Thread: AM3356

We have a new board design using AM3356 CPU. We have two Broadcom BCM54612E Phy chips connected to the CPU the same as on the EVM board. Its driver is detected by Linux during boot-up at the correct address, but any traffic to the network interface (eth0) just doesn't go anywhere. We seem to be able to talk to the phy over RGMII, read and write registers. We've probed AM335x's reset pin and it should be resetting the phy correctly too at boot-up, as per the phy requirement.

We are using kernel version 3.2, and the TI AM335x SDK 6.0 U-Boot (u-boot-2013.01.01-psp06.00.00.00) and have the same issue on both.
The specific Phy address is detected during boot-up, both in the U-Boot and kernel boot-up messages, i.e. the phy is being recognised as the Broadcom device (I had to modify the am33xx_cpsw_slaves[] structure).


U-Boot

Net:   My note -- Broadcom chip initialised
<ethaddr> not set. Validating first E-fuse MAC
My note -- Found phy ID = 0x3625xx
cpsw:02 is connected to cpsw.  Reconnecting to cpsw
cpsw
Hit any key to stop autoboot:  0

Kernel


[    1.187415] davinci_mdio davinci_mdio.0: phy[01]: device 0:01, driver Broadcom BCM54612E
[    1.196046] davinci_mdio davinci_mdio.0: phy[02]: device 0:02, driver Broadcom BCM54612E

Once booted, I try to enable the ethernet port, and either get a DHCP address or set static IP:
ifconfig eth0 up
udhcpc

The dhcp gets nothing though and times out:

# udhcpc
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...

 and pinging with static IP address does nothing either:
ifconfig eth0 10.10.10.200 netmask 255.255.255.0

# ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
    ^C
--- 10.10.10.1 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

When the ethernet cable is plugged in, I can see the messages that it has recognised the connection and auto-negotiated the connection type, we've tried switches with 10/Half and 100/Half and now got a router to test 100/Full.

[  187.106181] CPSW phy found : id is : 0x3625xx
# [  190.049131] PHY: 0:01 - Link is Up - 100/Full

We've set sniffing at its MAC address, but got nothing out.

It seems to me that CPSW is doing all the handling of data going to any external ports, so just wondering if its configuration could be rather particular.

Any suggestions for how such an issue could be debugged? Is there something that needs to be done to configure CPSW correctly?

Any help would be greatly appreciated. I'm really really stuck...

  • 0
    Expert 2985 points

    I am not expert in this area but just to help you in debugging i am writing this,

    are you able to ping  from uboot ?

    If you are able to ping from uboot then some kernel configuration is missing,

  • 0
    TI__Mastermind 44306 points

    Adriana,

    so far your data only indicates that the MDIO interface and the phys are working. The critical part for data transfer however is the RGMII interface between processor and phys. And that includes layout issues I assume. So did you get Broadcom to review schematics and layout?

    I assume you will need to setup test software that is for example constantly sending test packets. That should allow to measure RGMII signals on that board and see if anything is going on. Once you are sure TX is working you can got to RX as a next step (sending test packets from external device).

    From the software side I am not an expert on the Linux CPSW driver. But I know that CPSW needs to be configured for the correct HW interface. You may also find other forum entries related to RGMII here on the forum.

    Regards,

  • 0 in reply to Frank Walzer
    Intellectual 450 points

    Ankur, no we can't ping from U-Boot. The setup looks pretty similar in both U-Boot and Linux.

    Frank,

    Thank you for the suggestion, I didn't realise the RGMII layout could be so critical. I'll check with the HW team, but I don't think Broadcom has yet reviewed any of our design docs - schematics or layout.

    There's activity on the Tx pin, but doesn't look like valid packets. It may very well then be an RGMII config issue.

    The CPSW options we configured were the MAC, RGMII_MODE_ENABLE, and phy ID. I didn't see see anything else being set there. I'll try to have a look for other RGMII info. Thank you!

  • 0 in reply to Adri G
    Intellectual 450 points

    We've found probing around that the RGMII1_tclk is different frequency from the rclk. The Rclk is 25MHz, but Tclk seems to be 10MHz.

    What configures the frequency of the tclk? I thought it was automatically generated depending on the negotiated connection speed. I don't think we changed anything in the am335x EVM code other than point it to the Broadcom driver instead of the Atheros.

  • 0 in reply to Adri G
    Intellectual 450 points

    We finally have it resolved. In u-boot we had cleaned up AM335x EVM code using the eeprom as well as the PMIC, as we had neither on our board. Turned out that commenting out the calls to am33xx_spl_board_init(), meant that we didn't set-up one of the critical CPU clocks.

    Firmware engineer tracked the problem to the single line in that function:

    core_pll_config(OPP_100);

    After that we just got some correct settings for the compatible BCM54616 kernel driver (Phy register values) and it's finally working.