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.

How to switch the eXperimenter AM1808 SOM LAN8710A PHY from the MII mode to the RMII?

Other Parts Discussed in Thread: AM1808, OMAP-L138

Hi,

 In our design we plan to use all three available AM1808 UARTs together with the EMAC Ethernet controller.

Due to the fact that on AM1808 the UART0 TXD / RXD lines are multiplexed with MII RXD[2] / MII RXD[3] pins we try to release the MII RXD/TXD lines and  switch the  eXperimenter AM1808 SOM LAN8710A PHY from the MII mode to the RMII mode run time.

As a base for our software reference design we use the uboot-03.20.00.12 version  that comes with the DaVinci-PSP-SDK-03.20.00.12  SDK and it is compiled for the da850evm board.

The u-boot is programmed to the AM1808  together with the ubl_AM1808_SPI_MEM.bin Boot loader via Serial interface.

In order to implement the change we modified the original da850evm PINMUX and EMAC initialization  sequence to the following procedure to switch the AM1808 LAN8710A PHY from the boot strapped MII mode to the run time RMII configuration:

  1.  Configure the PINMUX for the MII mode.
  2. Configure the MII mode in the CFGCHIP3 register.
  3. Initialize the EMAC MDIO interface.
  4. Via MDIO interface operating in the MII mode write the LAN8710A PHY Special Mode Register 18 with value 0x4000 to enable the RMII mode.
  5.  Via MDIO perform PHY soft reset by setting the Soft Reset bit in the PHY Basic Control register. After reset PHY should come in RMII mode.
  6. Disable the EMAC MDIO interface.
  7.  Configure the PINMUX for the RMII mode.
  8. Configure the RMII mode in the CFGHIP3 register.
  9. Initialize the EMAC driver with RMII mode enabled. (CONFIG_DRIVER_TI_EMAC_USE_RMII is defined)
  10. Try to communicate with the host PC via EMAC by sending the ping from the u-boot prompt.

As a result of the algorithm above we can access the PHY registers and see that the PHY correctly recognize the link status and can read other PHY registers. But when we try to communicate with the host by “ping”  the communication fails.

Could you please, review our procedure may be we missed something?

 Thank you beforehand,

 Evgeny

  •  

    Evgeny,

    Can you run a quick sanity check to see if you can receive a response from the device when it is configured with the MII interface?

    If this works, this will rule out any network issues.

    Next step would be to see if you are getting any pin signaling on the RMII pins after your configuration to RMII. Can you check these two things?

    Alternatively, you might be able to set up your emulator to see if the EMAC registers change when you ping the device, so you know the PHY is operating as configured post a PHY reset.

     

     

  • Hi Drew,

    I checked the network configuration with the MII mode and everything worked fine. Than to verify that I communicate with PHY over the RMII lines  I disabled the  MII and set the MII pins to be GPIO  with PINMUX registers.  My pinmux configuration in the RMII mode is as following:

    const struct pinmux_config emac_pins_rmii[] = {
            { pinmux[2], 4, 1 }, // MII_TXEN  -> GP1[14]
            { pinmux[2], 4, 2 }, // MII_TXCLK -> GP1[13]
            { pinmux[2], 4, 3 }, // MII_COL   -> GP1[12]
            { pinmux[2], 4, 4 }, // MII_TXD[3]-> GP1[11] : Must be set to 0 (Vss) See the PHY Data Sheet "8710a.pdf" Table 3.2 Note 3.1
            { pinmux[2], 4, 5 }, // MII_TXD[2]-> GP1[10] : Must be set to 0 (Vss)
            { pinmux[2], 4, 6 }, // MII_TXD[1]-> GP1[9]
            { pinmux[2], 4, 7 }, // MII_TXD[0]-> GP8[7]
            { pinmux[3], 4, 0 }, // MII_RXCLK -> GP1[8]
            { pinmux[3], 0, 1 }, // MII_RXDV  -> pin is 3-stated
            { pinmux[3], 4, 2 }, // MII_RXER  -> GP8[6]
            { pinmux[3], 4, 3 }, // MII_CRS   -> GP8[5]
            { pinmux[3], 2, 4 }, // MII_RXD[3]-> UART0_RXD
            { pinmux[3], 2, 5 }, // MII_RXD[2]-> UART0_TXD
            { pinmux[3], 4, 6 }, // MII_RXD[1]-> GP8[2]
            { pinmux[3], 4, 7 }, // MII_RXD[0]-> GP8[1]
            { pinmux[14], 8, 2 },   // RMII_TXD[1]
            { pinmux[14], 8, 3 },   // RMII_TXD[0]
            { pinmux[14], 8, 4 },   // RMII_TXEN
            { pinmux[14], 8, 5 },   // RMII_RXD[1]
            { pinmux[14], 8, 6 },   // RMII_RXD[0]
            { pinmux[14], 8, 7 },   // RMII_RXER

            { pinmux[15], 8, 0 },   // RMII_MHZ_50_CLK use internal RMII clock from PLL0_SYSCLK7       

           { pinmux[15], 8, 1 },   // RMII_CRS_DV
            { pinmux[4],  8, 0 },   // MDIO_CLK
            { pinmux[4],  8, 1 }    // MDIO_D
    };

    Additional change was that I configured the PHY TXD[3] and TXD[2] pins (GP1[10] and GP1[11]) to be general outputs and set them to 0 (Vss) accordingly to the requirement from the LAN8710A PHY Spec. (8710a.pdf  Table 3.2 Note 3.1).

    After I verified the RMII configuration and verified that the RMII clock (PLL0_SYSCLK7) is exactly 50 MHz I found the main problem:

    For some reason the PHY cannot maintain the link if it is in RMII mode. The polling of the PHY Status Register 1 shows that the link is periodically going UP and Down, so the EMAC cannot send the packets when the link is down.

    -Evgeny

  • Hi, Evgeny:

     

    there is a small line in reference guide describing:

    NOTE: The SYSCLK7 output clock does not meet the RMII reference clock specification of 50MHz

    +/-50ppm.

     

    hope this could explain what you met.

     

    regards,

    Power Pan

  • Hi Power Pan,

    Thank you for the input,

     

    Just to be sure, since the answer can affect our final HW design.

    Does it mean that due to the AM1808-SOM LAN8710A PHY does not have the external 50 MHz clock we would not be able to operate it in RMII mode?

    If the answer is yes, is there any other way we can fix it?

    -Evgeny

  • Hi Evgeny,

     

    sorry for the late reply cause busy with customer board layout for days.

    1.AM1808 I saw sb. made RMII work. check www.aldtech.com for their M1 board's brief.

    2.no, AM1808 is not recommended to output 50MHz clock, my design is to use an external 50MHz to provide clock to PHY and AM1808 like AIC's MCK.

     

    hope this could help.

    Regards,

    Power Pan

     

  • Hi Power Pan,

    We are going to check the possibility for adding the external 50 MHz clock to our design. That issue popped up at the final stage of our board design so we had to be sure that there were no other firmware work around available.

    Thank you so much for the support!,

    Evgeny

  • Hi, Evgeny,

    another suggestion for your design if you use SATA, if you don't use SATA, please ignore this reply.

     

    TI's recommendation for the SATA clock reference is provided by PLL and internal is another PLL, PLL pollutes the output clock, i found my evb works abnormal for the SATA portion, and check the schematic found out the capacitors are not enough to keep a clean power supply to the sata part that needs strictly clock source, don't know how they think but I suggest to use a 75M LVDS crystal source instead of the PLL chip or a normal crystal with LVDS driver to clock the SATA(for cost down)

     

    Power Pan

     

  • Power Pan,

    Thanks for the recommendation!

    In our design we use the SD card instead of the SATA drive.

    -Evgeny

  • Hi, Evgeny, 

    you made RMII working now, could you please send me a reference like u-boot modification and kernel modification, also with the EMAC schematic to me to have a look? my board is coming back I wanna make it run ASAP, thanks a lot. powerpan@21cn.com

    also, if you are using DDR2, please tell me how to modify the kernel to make it start. thanks a lot.

    Best regards

    Power Pan

  • Hi Power Pan,

    After the review with Logic PD support, we decided to implement the external UART instead of AM1808 internal UART0 and leave the EMAC as is in the MII mode.

    So we did not change the SW or HW around the EMAC.

    As the DDR  we use the Mobile DDR (mDDR) that comes with the SOM so we had no reasons to modify the original initialization code.

    Normally, the  DDR initialization is done in the AIS boot script or in the UBL (User Boot Loader) code.

    The good references for the DDR initialization are: the AM1808.gel initialization script (function DEVICE_mDDRConfig)  from the CCS AM1808 BSL library  or function DEVICE_ExternalMemInit from the Serial Flash and Boot Utility (the source file is OMAP-L138_FlashAndBootUtils_2_29/OMAP-L138/Common/src/device.c).

    You can download the Serial Flash and Boot Utility sources from the link: http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/

    There is also a reference document for the DDR configuration: http://focus.ti.com/lit/ug/sprufu3b/sprufu3b.pdf.

     

    Regards,

    Evgeny

  • Hi, Evgeny:

    thanks for you detail reply. the reason I choose DDR2 cause DDR2 is a lot cheaper then mDDR and mDDR is fading out of the market.

    Best regards,

    Power Pan

  • Power Pan,

    No Problem.

    Good idea about the DDR2.

    Regards,

    Evgeny

  • The RMII port is routed to a connector that goes to a LAN8720 on a daughter card.  If you are configuring the pinmux for RMII you need to have the daughter card on and plug the Ethernet cable into the RJ45 jack on the daughter card.

  • thanks James, I downloaded the UI board, and saw it.

    regards,

    Power Pan