• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 812 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.

AM3358 CPSW3G RGMII2 TX_CTL Question

Stuart Brown
Prodigy 90 points
Other Parts Discussed in Thread: AM3358

Developing a custom board with the AM3358  connected to a Marvell 88E1310 PHY using the RGMII2 interface. We are using a WINCE700 BSP and the CPSW3GKitl device driver.

We are unable to transmit any frames (EBOOT cannot DHCP an IP address), I can see that RGMII2_TCLK is correct on the scope but RGMII2_TCTL is never asserted. We are configuring in the following way:

1: XLoader is configuring GMII_SEL to 0x3B -> Port 1 not used, Port 2 used for RGMII, not internal delay.

2: EBoot is configuring the pads GPMC_A0:11 to mode 2 -> RGMII2 

3: The CPSW3G initialization is per the CPSW3GKitl device driver, and I've checked this follows the instructions in the spruh73g technical manual.

4: On a transmit frame it seems to be doing the correct thing, but when the packet address is written to the DMAHDP register nothing happens (RGMII2_TCTL stays low)

My questions is have we missed any obvious configuration steps relating to enabling RGMII 2?

Also am I correct in thinking the CPSW_P2 registers are for the RGMII2 interface?

I've logged  the contents of some registers during a SendFrame and copied this below (it does not look like the stats register is logging any activity).

Any guidance would be appreciated,

Stuart

-- Dump of registers during a SendFrame.

+Cpsw3gSendFrame
Packet is at 0x8FEB4FE8 tx_bd=0xAF0C0600
Copying 590 bytes from 0x8FEB4FE8 to 0xAF0C0000
  BuffPtr[0xAF0C0604] set to 0x8F0C0000
  BuffOffsetLength[0xAF0C0608] set to 0x0000024E
  BuffFlagPktLen[0xAF0C060C] set to 0x0000024E
  BuffFlagPktLen[0xAF0C060C] set to 0xE011024E
Writing 0xB0500A00 with 0x8F0C0600 {Physical Address}

CPMAC_A_TX_DMAHDP(KITL_CHANNEL)[0xB0500A00]=0x8F0C0600

RGMII_CTL:
  RGMII_CTL[0xB0501288]=0x00000030
TX_CTL:
  CPDMA_TX_CTRL[0xB0500804]=0x00000001
STATS REG:
  STATS_GOOD_TX_FRAMES[0xB0500934]=0x00000000
  STATS_BCAST_TX_FRAMES[0xB0500938]=0x00000000
  STATS_PAUSE_TX_FRAMES[0xB0500940]=0x00000000
  STATS_DEFERRED_TX_FRAMES[0xB0500944]=0x00000000
  STATS_TX_UNDERRUN[0xB050095C]=0x00000000
  STATS_TX_OCTETS[0xB0500964]=0x00000000
ALE:
  CPALE_VER_ID[0xB0500D00]=0x00290104
  CPALE_CTRL[0xB0500D08]=0x80000000
  CPALE_PRESCALE[0xB0500D10]=0x00000000
  CPALE_UNK_VLAN[0xB0500D18]=0x00000000
  CPALE_PORT_CTRL_0[0xB0500D40]=0x00000003
  CPALE_PORT_CTRL_1[0xB0500D44]=0x00000013
  CPALE_PORT_CTRL_2[0xB0500D48]=0x00000000
  CPALE_PORT_CTRL_3[0xB0500D4C]=0x00000000
  CPALE_PORT_CTRL_4[0xB0500D50]=0x00000000
  CPALE_PORT_CTRL_5[0xB0500D54]=0x00000000
MAC:
  CPMAC_MAC_CTRL(1)[0xB0500D84]=0x00000020
  CPMAC_MAC_STS(1)[0xB0500D88]=0x80000000
  CPMAC_MAC_TX_PAUSE(1)[0xB0500D9C]=0x00000000
PORT:
  CPSW_P0_CONTROL[0xB0500100]=0x00000000
  CPSW_P0_VLAN[0xB0500114]=0x00000000
  CPSW_P1_CONTROL[0xB0500200]=0x00000000
  CPSW_P1_VLAN[0xB0500214]=0x00000000
  CPSW_P2_CONTROL[0xB0500300]=0x00000000
  CPSW_P2_VLAN[0xB0500314]=0x00000000
DMA:
  CPDMA_TX_VER_ID[0xB0500800]=0x00180108
  CPDMA_TX_CTRL[0xB0500804]=0x00000001
  CPDMA_DMA_CTRL[0xB0500820]=0x00000001
  CPDMA_DMA_STS[0xB0500824]=0x80000000
-Cpsw3gSendFrame

  • 0
    TI__Guru**** 393215 points
    Hi Stuart,
     
    I'm not an expert on this, but a customer had a similar problem (TX_CTL not driving). They solved it themselves and didn't report details, but said the problem was caused by incorrect PHY settings. Just an idea...
  • 0 in reply to Biser Gatchev-XID
    Prodigy 90 points

    Hi,

    I've done some further probing by switching to U-Boot. I have two boards, both using RGMII2 to connect to different PHYs - one board uses a Vitesse VSC8601 the other is using a Marvell 88E1310. Both boards exhibit the same behaviour RGMII2_TX_CLK is present but RGMII2_TX_CTL never toggles; I've also probed the receive signals and I can see activity, RGMII2_RX_CTL and data lines are toggling when the PHY sees braodcast/multicast packets.

    It seems as if RGMII2 is not enabled in the CPSW? However I've definitely enabled RGMII mode in CONTROL_MODULE:gmii_sel register - set to 0x3A.

    I can't imagine there is a problem with using RGMII2 without RGMII1, and I have a feeling that there is a bit somewhere I need to toggle and it will just kick into life.

    How does the CPSW know which port - RGMII1 or RGMII2 - to use? or does it duplicate data on both ports?

    -- I have my PHY configured so that it adds the internal delay, is it possible for the PHY to hold RGMII2_TX_CTL and data lines low to stop the processor from sending data? The fact the Rx lines are active suggests this is not the case and it is the processor that is not configured correctly.

  • 0 in reply to Stuart Brown
    Prodigy 90 points

    Some further debug in U-Boot and I have managed to get RGMII2 working.

    By default in arch/arm/cpu/armv7/am33xx/board.c it only supports 1 slave (cpsw_platform_data definition, field slaves). This means it only uses the first set of values defined in the cpsw_slaves[] array. By setting slaves to 2 U-boot initializes both RGMII interfaces - the sliver @ 0xdc0 and the sliver @ 0xd80.

    since we only have 1 PHY and 1 MAC I did not want to initialize both, however in cpsw.c it relies on the function cpsw_get_slave_port for configuring ALE port state (forwarding) and multicast support. The function cpsw_get_slave_port uses the slave_num (based on the number of slaves defined in board.c) to generate the slave_port id.

    The net result was if I tried to use only 1 slave with the definitions for RGMII2 it did not determine the correct slave_port. (It would enable forwarding and multicast for port 1 rather than port 2).

    Hopefully that will make sense to anyone who is having similar problems.

  • 0 in reply to Stuart Brown
    TI__Guru**** 393215 points
    Thanks for updating this Stuart! Glad you solved it, and it will surely be of help to other people.
  • 0 in reply to Stuart Brown
    Prodigy 60 points
    Hi Stuart,

    Thanks for this information, i am having the exact same issue. RGMII2 is connected to a Broadcom PHY and nothing on RGMII1. Can you share what exact changes were done in u-boot to make this work ?

    i did change the mux.c file and am getting MDIO working without issue but not able to get the dhcp ip