AM335X: Micrel KSZ9031RNXA on RGMII

>> needs is information regarding configuration of expected signal skew on the RGMII interface due to layout variance, correct?

Yes, correct.
Is there any timing skew on the processor registers for RGMII interface?

Hi,

You can see the RGMII Electrical Data and Timing requirements in section 7.6.1.4 of the AM335X Datasheet Rev. G. See also Advisory 1.0.10 in the AM335X Errata Rev. F.

How is the internal delay set in the Ethernet PHY in order to make the Ethernet functional?

It is understood that AM335X has no internal delay support but the Ethernet PHY has an internal delay mode. How is this set up in UBOOT?

Details The reset state of RGMII1_IDMODE (bit 4) and RGMII2_IDMODE (bit 5) in the
GMII_SEL register enables internal delay mode on the transmit clock of the respective
RGMII port. The AM335x device does not support internal delay mode, so
RGMII1_IDMODE and RGMII2_IDMODE must be set to 1b.
Workarounds Many RGMII Ethernet PHYs provide an internal delay mode that may be enabled to
insert delays required to meet the setup and hold timing requirements of the AM335x
device and attached RGMII PHY. A timing analysis is recommended before the printed
circuit board (PCB) design has been completed, in case it is necessary to insert
additional delays on the RGMII signals connecting the AM335x device and attached
RGMII PHY.
It is necessary to insert PCB delays if the RGMII PHY being connected to the AM335x
device does not support internal delay mode. A complete timing analysis is required to
determine the optimum delay of each PCB signal trace.

 

The first requirement is the RGMII PHY selected must support programmable delays in both transmit and receive data paths.  The delays need to be adjusted such that when combined with PCB delays the signals meet the timing requirements defined in the AM335x data sheet.  The internal PHY delays are normally adjusted by vendor specific registers accessed via the management interface (MDIO).  So the delays are adjusted by software modifying the respective registers via MDIO.  I cannot provide any details how this is done in software.

Regards,
Paul

To close out the issue we are trying to find out the details how this is done in software.
We are trying to find where in the uboot to put these value or how these value can be written into uboot and properly initialized the hardware timing similar to DDR3 timing before accessing to DDR3.
The main question is where in the memory map of the uboot that the processor can fetch these information and write into the register via MDIO.
Any help is appreciated.

The method for setting up the delay on the TI evm is this file of the u-boot source tree. The TI evm I believe are using different PHY but the concept could be modified to support this PHY.  The u-boot source for TI evm uses a method of determining which platform it is on. The code below is a snippet of the sequence used to set the timnig delay for the Gbps PHYs used on the TI evm.

board/ti/am335x/board.c

int board_eth_init(bd_t *bis)

 

        /*
         *
         * CPSW RGMII Internal Delay Mode is not supported in all PVT
         * operating points.  So we must set the TX clock delay feature
         * in the AR8051 PHY.  Since we only support a single ethernet
         * device in U-Boot, we only do this for the first instance.
         */
#define AR8051_PHY_DEBUG_ADDR_REG       0x1d
#define AR8051_PHY_DEBUG_DATA_REG       0x1e
#define AR8051_DEBUG_RGMII_CLK_DLY_REG  0x5
#define AR8051_RGMII_TX_CLK_DLY         0x100

        if (board_is_evm_sk(&header) || board_is_gp_evm(&header)) {
                const char *devname;
                devname = miiphy_get_current_dev();

                miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_ADDR_REG,
                                AR8051_DEBUG_RGMII_CLK_DLY_REG);
                miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_DATA_REG,
                                AR8051_RGMII_TX_CLK_DLY);
        }

 

For more clarity, it was simply that the RGMII interface was not being configured due to the board id being read out of the EEPROM. For the AM335x u-boot, different interfaces are activated based on what is read out of the EEPROM.

Our custom board that is based on the BBB does not use the mii interface found on BBB, instead it uses the RGMII interface. We had to switch the pinmuxxing around to setup the pins for the RGMII interface. We also had to change the phy addressed being used to address it over the MDIO interface. Once this was done the PHY came up, we were also able to make use of the generic mii write and read functions (don't let the name scare you, these are just writes/read over the MDIO interface) to changes the clock skew registers to account for our timings.

It does also appear that the CPSW driver is generic enough to support the Micrel Phy. Having to pull the Micrel Phy driver into u-boot would have made for a much more difficult task.

@ maat minga ,

I am facing the similar problem , my Phy KSz9031 is Up at 1000 mbps , full duplex , at correct phy ID , but problem is using in ping,dhcp and tftp command. It doesnt respond.

Reading this thread informs me that we have to change skew delays for solving this , as i am new to this can you tell me what are the changes required for doing so ?

I am using Dm8148 with Ezsdk , with uboot 4.04.00.01.

BR

Ammar Zafar

Ammar,

Sorry I did not respond sooner. The Micrel FAE described the process of taking slew measurements to the electrical engineer at the company I worked for at the time of this particular project. He provided me with the measurements and I was able to apply those values to the proper registers in the phy during u-boot. When the phy is being initialized I inserted the additional commands.

Regards,

Matt