DRA821U: Not working 1Gbps Auto negotiation using DP83867

Hi Junichi,

Can you provide the following details:

• Which ethernet controller are you using? Ethfw or Native Linux driver?
• Are you working on a custom board or on EVM?
• Which phy mode are you using? RMII/RGMII?
• Which SDK are you based on?

Regards,
Tanmay

Hello Tanmay,

I'll answer your questions inline blue letters.

• Which ethernet controller are you using? Ethfw or Native Linux driver?
  - Ethfw.
  
  
• Are you working on a custom board or on EVM?  

           - A custom board.

• Which phy mode are you using? RMII/RGMII?

           - RGMII.

• Which SDK are you based on?

            - ti-sdk-processor-rtos-j7200-evm-08_04_04_01.tar.gz

Best regards,

Junichi

Hi Junichi,

What are the RGMII delay settings (both Tx and Rx) used on the phy?

Can you try setting only Rx delay from the phy and no Tx delay.

Regards,
Tanmay

Hello Tanmay,

Thank you for your proposal.

I'll try your advice.

There was an error in my previous reply.
Phy mode I’m using is SGMII, not RMII/RGMII.

Best regards,
Junichi

Hello Tanmay,

We tried the setting of RGMII Control register (RGMII_TX_CLK_DELAY, RGMII_RX_CLK_DELAY)

 and RGMII Delay Control register (RGMII_TX_DELAY_CTRL, RGMII_RX_DELAY_CTRL), but 1Gbps link was not established.

Do you have any other advice?

Best regards,
Junichi

Hi Junichi,

suzuki.jnch said:

Phy mode I’m using is SGMII, not RMII/RGMII.

As you are using SGMII, delay won't be applicable in this case.

Is the phy mode, auto-negotiation or a forced link kind of setup?

Can you provide the changes you did in Ethfw for this.

Regards,
Tanmay

Hello Tanmay,

Thank you for your quick response.

We're developing the original ethernet driver.

So we don't use Ethfw.

Now I cannot confirm the auto negotiation.

The initialization procedure of our eth driver is following:

 - boot strap

   auto nego disable is 0 (RX_CTRL MODE 3)
   sgmii enable (LED_0) 0/1 
 

-. initialization in driver.
    soft reset.(BMCR  #15)
    sgmii enable.(PHYCR #11)
    speed opt, sgmii autoneg enable.(CFG2 #6,7,8,9)
    autoneg enable.(BMCR #12)
    100 base-tx,txfd enable.(ANAR #7,8)
    1000 base-t hd,fd enable.(CFG1 #8,9)
    restart autoneg.(BMCR #9)

Best regards,
Junichi

Hi Junichi-san,

suzuki.jnch said:

We're developing the original ethernet driver.

So we don't use Ethfw.

Are you developing your own phy driver or the driver for entire CPSW IP?

If you are developing your own CPSW driver, what is the sequence being followed for initialising the MAC?

Can you also check the value of the following registers:

1. 0x0c000110 + (i * 0x100) where "i" is the MAC port number
2. 0x0c000114 + (i * 0x100) where "i" is the MAC port number
3. 0x0c000118 + (i * 0x100) where "i" is the MAC port number

Regards,
Tanmay

Dear Tanmay-san,

We're developing our own phy driver.

The sequence being followed for initializing the MAC is following:

-.CPSW0_CONTROL registers.
    # for each port.
    command idle.(CPSW_PN_MAC_CONTROL_REG_k #11)
    soft reset.(CPSW_PN_MAC_SOFT_RESET_REG_k #0)
    set portN mtu, mac address, etc...
    set portN control.(CPSW_PN_MAC_CONTROL_REG_k #5,18)

    # once in the core.
    set port0 crc, padding, etc..
    enable port0. (CPSW_CONTROL_REG #2)

-. Set STATS related.

-. Set ALE related.

-. Set device configurations.
    # for  each  port.
    select port mode.(CTRLMMR_ENETx_CTRL #0,1 = SGMII)

-. Enable SERDES0. (we use a chip support library.)
    # for  each  port.
    CSL_serdesConfigStatus()
    CSL_serdesPorReset()
    CSL_serdesIPSelect(sgmii lane 1-4)
    CSL_serdesRefclkSel()
    CSL_serdesDisablePllAndLanes()
    CSL_serdesEthernetInit()
    CSL_serdesLaneEnable()

    # CSL_SerdesLaneEnableParams are set as follows.
    serdesInstance = CSL_TORRENT_SERDES0
    baseAddr  = CSL_SERDES_10G1_BASE
    refClock  = CSL_SERDES_REF_CLOCK_100M
    refClkSrc = CSL_SERDES_REF_CLOCK_INT
    numLanes  = 4
    laneMask  = 0xF
    SSC_mode  = CSL_SERDES_NO_SSC
    operatingMode = CSL_SERDES_FUNCTIONAL_MODE
    phyInstanceNum = 0
    laneCtrlRate[0:1] = CSL_SERDES_LANE_FULL_RATE
    loopbackMode[0:1] = CSL_SERDES_LOOPBACK_DISABLED
    phyType   = CSL_SERDES_PHY_TYPE_SGMII
    pcieGenType = CSL_SERDES_PCIE_GEN3
    linkRate  = CSL_SERDES_LINK_RATE_1p25G

-. Set SGMII registers.
    # for  each port.
    soft reset.(CPSW_SGMII_SOFT_RESET_REG_j #1)
    set advertise ability.(CPSW_SGMII_MR_ADV_ABILITY_REG_j #0-15 0x9801)
    enable autonego.(CPSW_SGMII_CONTROL_REG_j #0)

-. Set MDIO registers.
    set divider.(CPSW_MDIO_CONTROL_REG #0-15 CPPI_ICLK/MDC_FREQ-1)
    enable control.(CPSW_MDIO_CONTROL_REG #30)
    (make sure the phy is alive.(CPSW_MDIO_ALIVE_REG))

-. Set DP83867 registers(mentioned in previous reply)

The value of the SGMII registers (only MAC port 1 is enabled) is here:


Best regards, 
Junichi

Hi Junichi-san,

From the register dump, the link is up for the MAC port (Bit 0 of CPSW_SGMII_STATUS_REG_j).

Can you check the link status from BMSR register in Phy?

Are you able to send any data across the link?

Do you have any HLOS running on A72? If the HLOS running on A72 is also configuring the serdes (configuration differing from what you have done on R5), then serdes might also cause some issues for data transfer.

Regards,
Tanmay

Hello, Tanmay-san.

> Can you check the link status from BMSR register in Phy?

> Are you able to send any data across the link?

BMSR register shows a link-up and 100Mbps communication works well.

Our issue is that 1Gbps communication is not selected in auto-negotiation.

Attached you can find the register dump for reference.

> Do you have any HLOS running on A72? If the HLOS running on A72 is also configuring the serdes (configuration differing from what you have done on R5), then serdes might also cause some issues for data transfer.

A72 never accesses the SERDES.

Best regards,

Junichi

Hello, Tanmay-san,

I would like to remind you that I still have not received your response about the above post.

Is there anything else I should check?

Best regards,

Junichi

Hi Junichi-san,

Very sorry for the delayed response.

Is this issue still being observed?

Regards,
Tanmay

Hello, Tanmay-san,

No, thank you.

Best regards, 

Junichi