GMII Interface with GigE Switch

Hi Brandon,

For the 125MHz clock enable bits, see registers PCIE_PLLCFG1[4] EN_CLK125M and SATA_PLLCFG1[4] EN_CLK125M.

More information how to enable GMII_1 here:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/218011/769312.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/214043/762567.aspx

Best Regards,

Pavel

Hi Brandon,

I'm working on exactly this same thing. How have you made out? I'm having difficulty with the GMII interface as well since the CPSW driver code is so tightly married to phy_device stuff. Not sure how to proceed without having to mangle the CPSW driver. 

Dennis

Dennis,

To  enable the 125Mhz clock you will need to see registers PCIE_PLLCFG1[4] EN_CLK125M and SATA_PLLCFG1[4] EN_CLK125M and enable the bits bolded.

Regards,

-Brandon

I apologize, I should have been more specific. I meant specifically, were you able to interface (and pass traffic) from the AM387x to the 88e6131? Aside from enabling the clocks for the GMII, did you get everything else working? 

We have the following issues thus far: 

- The TI driver for the CPSW insists that its ports be connected to
PHYs, instead of directly over some form of *MII. It'll crash if
you don't pass it IDs of PHYs to attach to, and if you specify
some IDs for PHYs that don't exist, it'll never up its network
interface so that you can't send/receive traffic.

- For some reason, the CPSW driver insisted on being initialized
only very late in the boot process, after the DSA driver init runs,
so that the DSA driver init couldn't find a network interface
attached to the CPSW driver in the device tree and would bomb out.

- The davinci_mdio driver wants to scan all PHY addresses on its
attached bus, which it shouldn't be doing in case there is a switch
chip connected.

- The davinci_mdio driver returns an EIO error if it is asked to probe
a PHY address that does not exist, instead of returning 0xffff like
other drivers do, and an -EIO error return was being thrown back up
the stack as a failure to initialize this MDIO bus, instead of a
normal condition, causing the DSA driver to fail to register its
slave MDIO bus.

We're using PSP04.04.00 and EZSDK dm814x-evm_05_04_00_11 .. 

Any help greatly appreciated! 

Dennis

oh, and another question: 

It is easy to find where the PCIE_PLLCFG regs are set in arch/arm/mach-omap2/devices.c in fxn ti81xx_init_pcie().  I modified the value written to TI814X_CONTROL_PCIE_PLLCFG1 to be 0x00640010 (was 0x00640000). But I can't find where to modifiy the SATA_PLLCFG1[4] bit. Where do I make the change? 

anyone???? 

Hellooooo?? 

Where in the kernel sources is the SATA clock for GMII supposed to get set? 

The example in sprugz7b includes a line like this: 

while ((*CM_DEFAULT_L3_MED_CLKSTCTRL & 0x0F) != 0x102);

That looks a lot like it'll be an infinite loop. (something & 0x0F) will *never* be 0x102. 

Does TI provide premium paid support?? 

Hi Dennis,

Have a look in this file and function:

ti-ezsdk_dm814x-evm_5_05_01_04/board-support/u-boot-2010.06-psp04.04.00.01/board/ti/ti8148/evm.c

static void sata_pll_config()
{
    __raw_writel(0xC12C003C, SATA_PLLCFG1);
    __raw_writel(0x004008E0, SATA_PLLCFG3);
    delay(0xFFFF);

    __raw_writel(0x80000004, SATA_PLLCFG0);
    delay(0xFFFF);

    /* Enable PLL LDO */
    __raw_writel(0x80000014, SATA_PLLCFG0);
    delay(0xFFFF);

    /* Enable DIG LDO, ENBGSC_REF, PLL LDO */
    __raw_writel(0x80000016, SATA_PLLCFG0);
    delay(0xFFFF);

    __raw_writel(0xC0000017, SATA_PLLCFG0);
    delay(0xFFFF);

    /* wait for ADPLL lock */
    while(((__raw_readl(SATA_PLLSTATUS) & 0x01) == 0x0));

}

I hope this will help.

Regards,

Pavel

Thank you very much for your reply. Do you mean to say that setting the SATA_PLLCFG1[4] and PCIE_PLLCFG1[4] are to be done in U-Boot and won't be overwritten or changed by the kernel?  I have not tested this to find out, but I assumed the kernel would have overwritten the values. 

I will give your suggestion a try. 

Thank you again! 

Dennis

Hi Dennis,

Regarding SATA_PLLCFG1 register, the u-boot program it with the value of 0xC12C003C, thus bit 4 is 0x1. And after that, the linux kernel overwrite the SATA_PLLCFG1 register with the value of 0x812C003C, in file ti-ezsdk_dm814x-evm_5_05_01_04/board-support/linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/devices.c :

static inline void ti814x_sata_pllcfg(void)
{
    if (!cpu_is_ti814x())
        return;

    if ((cpu_is_ti814x()) && (!cpu_is_dm385())) {
        /* Configure 100Mhz clock source on DM814x */

        /* Configure SATA0 PLL -applies for TI814x*/
        omap_ctrl_writel(0x00000004, TI814X_CONTROL_SATA_PLLCFG0);
        udelay(100);
        /* cfgpll1  (for 100 MHz Operation) */
        omap_ctrl_writel(0x812C003C, TI814X_CONTROL_SATA_PLLCFG1);
        udelay(2000);
        omap_ctrl_writel(0x004008E0, TI814X_CONTROL_SATA_PLLCFG3);
        udelay(2000);
        /* wait for bias to be stable */
        omap_ctrl_writel(0x00000014, TI814X_CONTROL_SATA_PLLCFG0);
        udelay(850);
        omap_ctrl_writel(0x00000016, TI814X_CONTROL_SATA_PLLCFG0);
        udelay(60);
        /* cfgpll0 Replaced 0xC00000016 to 0x40000016 for 100MHz
        * Usage instead of 20MHz
        */
        omap_ctrl_writel(0x40000016, TI814X_CONTROL_SATA_PLLCFG0);
        udelay(2000);

        /* cfgpll0 Replaced 0xC0007077 with 0x40007077 for
        * 100MHz Usage instead of 20MHz
        */
        omap_ctrl_writel(0x40007077, TI814X_CONTROL_SATA_PLLCFG0);

        while (!(omap_ctrl_readl(TI814X_CONTROL_SATA_PLLSTATUS) & 0x1))
            cpu_relax();
    } else {
        /* Configure 20Mhz clock source on ti813x */
    }

}

At the end, when the kernel is booted and the system is up, the value of bit 4 is still 0x1 (125MHz clock is enabled).

I will further check for the PCIE_PLLCFG1[4] and let you know.

Regards,

Pavel

Regarding PCIE_PLLCFG1 regiser:

1. In u-boot, there is no programming of this register, the function static void pcie_pll_config() in file ti-ezsdk_dm814x-evm_5_05_01_04/board-support/u-boot-2010.06-psp04.04.00.01/board/ti/ti8148/evm.c is commented out.

2. In linux kernel, this register is programmed with the value of 0x00640000 in file ti-ezsdk_dm814x-evm_5_05_01_04/board-support/linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/devices.c :

static inline void ti814x_pcie_pllcfg(void)
{

    if (cpu_is_ti814x()) {
        /* TODO: Add bitfield macros for following */

        omap_ctrl_writel(0x00000002, TI814X_SERDES_REFCLK_CTL);
        omap_ctrl_writel(0x00000000, TI814X_CONTROL_PCIE_PLLCFG0);
        omap_ctrl_writel(0x00640000, TI814X_CONTROL_PCIE_PLLCFG1);
        omap_ctrl_writel(0x00000000, TI814X_CONTROL_PCIE_PLLCFG2);
        omap_ctrl_writel(0x004008E0, TI814X_CONTROL_PCIE_PLLCFG3);
        omap_ctrl_writel(0x0000609C, TI814X_CONTROL_PCIE_PLLCFG4);

        /* Configure SERDES misc bits - values as is from h/w */
        if (!cpu_is_dm385()) {
            /*
             * TODO: MISCCFG write is not needed for PG2.x devices,
             * to be tested with if{} part removed
             */
            if (omap_rev() > TI8148_REV_ES1_0)
                omap_ctrl_writel(0x0000039E,
                        TI814X_CONTROL_PCIE_MISCCFG);
            else
                omap_ctrl_writel(0x00000E7B,
                        TI814X_CONTROL_SMA0);
        }

        udelay(50);
        omap_ctrl_writel(0x00000004, TI814X_CONTROL_PCIE_PLLCFG0);

        udelay(50);
        omap_ctrl_writel(0x00000014, TI814X_CONTROL_PCIE_PLLCFG0);

        udelay(50);
        omap_ctrl_writel(0x00000016, TI814X_CONTROL_PCIE_PLLCFG0);

        udelay(50);
        omap_ctrl_writel(0x30000016, TI814X_CONTROL_PCIE_PLLCFG0);

        udelay(50);
        omap_ctrl_writel(0x70007016, TI814X_CONTROL_PCIE_PLLCFG0);

        udelay(200);
        omap_ctrl_writel(0x70007017, TI814X_CONTROL_PCIE_PLLCFG0);

        while (!(omap_ctrl_readl(TI814X_CONTROL_PCIE_PLLSTATUS) & 0x1))
            cpu_relax();

    }

}

To set bit 4 to 0x1 (enable 125MHz clock), you can modify the 0x00640000 value accordingly, build new kernel image and load it.

Regards,

Pavel

I have psp04.04.00.01 but I do not have the sata function you mentioned. I don't see a static inline void ti814x_sata_pllcfg(void) function in devices.c.  But, I see you're referring to EZSDK  ti-ezsdk_dm814x-evm_5_05_01_04  where I have  ti-ezsdk_dm814x-evm_5_04_00_11. Is that maybe something that has been added since? 

I did find and modify that bit for the PCIE, it was only the SATA bit I was unable to find. 

Thank you very much for your help!

 "But, I see you're referring to EZSDK  ti-ezsdk_dm814x-evm_5_05_01_04  where I have  ti-ezsdk_dm814x-evm_5_04_00_11. Is that maybe something that has been added since?"

Yes, the ti814x_sata_pllcfg function is added in EZSDK 5.05. Please use this one, we have many improvements and bugs fixed compared with the old one (EZSDK 5.04)

Regards,

Pavel

update:  I found some other threads talking about some dependencies on both cpsw ports being enabled if port 2 is to work. We don't have port 1 routed at all, the pins are used for other things. So I added the cpsw_slave struct back in, and changed .slaves back to 2. I inverted the cpsw_slaves elements, changed cpsw_slaves[0].phy_id = "0:01", and modified the cpsw_get_slave_port() fxn to always return 2, the pinmux registers are set to enable emac[1], the GMII_SEL register is all zeroes, I set the PLL bits for SATA_PLLCFG[1] and PCIE_PLLCFG[1],..  

Both eth0 and eth1 appear in `ifconfig -a` as expected. The DSA driver code reports that it detected a Marvell 88E6131, as expected. 

I am not sure what to try next.