Broadcom BCM5464 Quad Phy integration

Hi,

I don't understand where will you connect the 4 MAC interfaces. The AM335X has only 2 MAC ports.

Thank you for the reply/question.

The 4 MAC interfaces are connected to the FPGA that function as a switch/router internally.

The purpose for accessing the Broadcom phys via MDIO is to configure and manage those phys.

Thanks,

Hay

Hello Hay,

all the technical information about how to configure the ethernet driver could be found in the following link

http://processors.wiki.ti.com/index.php/AM335x_CPSW_(Ethernet)_Driver's_Guide

Regards,

Antony

Hi Antony,

Thank you for the link.  As I remember, I went through that once before, it appears to support only two interfaces - eth0 and 1. I'll review it again and see if my observation still hold.  If so, would you recommend that I expand the CPSW to incorporate the additional 4 phys from the BCM5464?

Thanks,

Hay

Hi Hay,

for clarification you have the configuration represented in the image below and you are triying to manage the 4 PHYs connected to the BCOM chipset.

Regards,

Antony

Hi Antony,

I modified the diagram a little bit, see below. 

The FPGA is connected to the Broadcom phys via SGMII bus for data frame exchanges. We have this working already.  What we need is access to the management/control plane from CPU via MDIO bus.

Thanks

Hay

Hello Hay

you have the right hardware connection. When CPSW is configure to operate in switch mode instead of Dual MAC mode the MDIO will send a package and detect if the PHYs are compatible and then it will assign a MAC address to each of them up to 32.

I am looping some help to assist you on adjusting the interfaces on the PHYs.

In the meantime, please look at the following two post that might help you.

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259711.aspx

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/251498/880974.aspx#880974

Best regards,

Antony C.

Hi Antony,

Thanks for the link, I will review them to see if it contains information I need. Meanwhile, I would like to point out that  during boot, all 5 phys (4 broadcom and 1 micrel phy) are detected by the davinci MDIO probe function as shown in the trace log below. Obviously, the Micrel phy (7) eventually came up and I was able to ping it.

[    1.159820] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[    1.167388] davinci_mdio davinci_mdio.0: detected phy mask ffffff70
[    1.178497] davinci_mdio.0: probed
[    1.182647] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver Broadcom BCM5464
[    1.192230] davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver Broadcom BCM5464
[    1.201812] davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver Broadcom BCM5464
[    1.211364] davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver Broadcom BCM5464
[    1.220916] davinci_mdio davinci_mdio.0: phy[7]: device 0:07, driver Micrel KSZ9021 Gigabit PHY

[    1.808715] net eth1: CPSW phy found : id is : 0x221611
[    1.823394] ADDRCONF(NETDEV_UP): eth1: link is not ready
[    6.806823] PHY: 0:07 - Link is Up - 1000/Full
[    6.812377] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[    6.824066] IP-Config: Complete:
[    6.828033]      device=eth1, addr=10.219.101.204, mask=255.255.254.0, gw=10.219.100.1,
[    6.837677]      host=10.219.101.204, domain=, nis-domain=(none),
[    6.845123]      bootserver=10.219.100.79, rootserver=10.219.100.79, rootpath=

Thanks

Hay

Per Biser's comment above the AM335x only supports up to 2 MACs.

I am not sure by looking at the connection what you are trying to do though. Are both MAC ports being hooked up the FPGA? Could you go into more detail what functionality the FPGA is doing? Is it doing anything to the packets? Is it switching between ports on the FPGA? Could you describe more about how the network traffic is expected to flow between the ports?

Hi Schuyler,

I understand that the AM335x supports only 2 MACs.  We use one MAC as management port, and this port is NOT connected to the FPGA.  This port is connected to an external Micrel phy, and is working correctly.

The Broadcom Quad phys is totally independent from the AM335x supported MACs.  The only thing it shares is that the Broadcom device is controlled via the MDIO bus (which is shared-bus with the Micrel phy we discussed above).

To answer your question about what the FPGA is doing, it is switching data between those Broadcom quad phys, and NEVER exchange data with the AM335x supported MAC.  The only thing we wanted to do is to configure/manage the Broadcom devices via MDIO bus (which is shared bus with the Micrel phy).  We're looking for help in writing user space application to access MDIO bus to configure/manage the Broadcom phys.

Thanks

Hay

Your description does seem to match the block diagram from a previous post.

Here is what I understand from your last post.  The Micrel PHY is connected to one of the AM335x MII/RMII/RGMII ports. The FPGA has four SGMII ports connected to the Broadcom quad PHY.  The AM335x MDIO port is connected to all 5 PHYs.

I'm still not sure if the other AM335x MII/RMII/RGMII port is connected to the FPGA. Your last reply seems to indicate the FPGA is not connected to the AM335x.

Your question sound more like a software question rather than a hardware question.  Are you asking how software can be used to control PHYs that are not associated with the AM335x?

Regards,
Paul

Hi Paul,

The FPGA is connected to the AM335x via SPI bus. We use this only for the purpose of controlling/managing the FPGA (not for Ethernet frame data exchange). Other than that your understanding is correct.

And, yes, my question is all about SOFTWARE.  How to implement user space application to access the Broadcom device via MDIO bus (the only connection to the AM335x).  I'm sorry if this wasn't clear before.

Thanks

Hay

Normally ethtool is used to acces MDIO registers of the PHY which though reguires a MAC interface to access the corresponding PHY. Reading your post that sounds like what you are trying to do.  Looking through the MDIO driver it expects to couple with an Ethernet MAC driver. I don't see a way to do what you are tring to do other than writing a MAC driver that interfaces with the Davinci MDIO driver.

Were you expecting to use ethtool?

Hi Schuyler,

We're getting close to what I need now.  Our kernel is configured for dual MAC (CONFIG_TI_CPSW_DUAL_EMAC=y). Obviously, the Broadcom Quad phy device does not couple with any Ethernet MAC driver, therefore I will not be able to access it via MDIO bus.  However, I should be able to (and was able to) access the MDIO bus via the Micrel Ethernet MAC driver (using socket/ioctl with SIOCGMIIREG).  But, when it gets to the actual ioctl function (snipped code below) there is no switch case for SIOCGMIIREG. So, just for my experiment, I added the handling for SIOCGMIIREG which directly call the mdiobus_read() with the Broadcom MDIO bus address and was able to read the Broadcom register correctly.  I verified it with the reading of phy ID register of the Broadcom device.

So, my question is: why don't we have the handling if SIOCGMIIREG.  Am I in the wrong function?

Thanks,

Hay

static int cpsw_ndo_do_ioctl(struct net_device *ndev, struct ifreq *ifrq,
        int cmd)
{
    struct cpsw_priv  *priv = netdev_priv(ndev);
    struct phy_device *phy;
    struct mii_bus    *bus;
    struct mii_ioctl_data mii;

    unsigned short val;

    if (!(netif_running(ndev)))
        return -EINVAL;

    switch (cmd) {

    case SIOCSWITCHCONFIG:
        return cpsw_switch_config_ioctl(ndev, ifrq, cmd);

#ifdef CONFIG_TI_CPTS
    case SIOCSHWTSTAMP:
        return cpsw_hwtstamp_ioctl(ndev, ifrq);
#endif

Hi Hay,

I am not sure adding the ioctl in the cpsw is the best approach. To answer your question about why the iotcl that you asked about is not supported, best guess is that the developer chose to use a different path to access and set MDIO data. Looking through the cpsw driver there is an ethtool interface defined and one of the functions is for accessing the phy, however I have not been able to prove this interface gets called. But ethtool does work and it is calling the mdio read function you mentioned.  

drivers/network/phy/phy.c has the ioctl structure you have mentioned, though the phy does not have /dev node so it could not be accessed using these ioctl.

Are able to address all the phys with your iotcl?

Hi Schuyler,

I have followed the ethtool ioctl but got lost due to its complexity. I also noticed the call to MDIO read function I used in my experiment. I'll give anther pass to the code later.  

And, yes, with my experimental code I was able to access all 4 phys MDIO address of 0, 1, 2, 3 (Broadcom Quad device) and also the Micrel phy at address 7.

Thanks

Hay