• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 2049 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.

AM335x MII Issues

Russell Robinson74
Prodigy 60 points

Hello,

Since the RMII interface requires an additional oscillator due to REFCLK issues, we are attempting to make GMII1 operate in MII mode on our hardware. Currently we are running into issues with TXEN not being asserted, even though the TXCLK and RXCLK look good. The signals seem to operate correctly when attempting to boot from MII1. That said, in both U-boot and Linux, the PHY links correctly at 100Mbit/s.

Mounting debugfs and taking a look at the omap_mux signals, I found that the MII1_TXCLK/RXCLK/RXD3/RXD2 signals are being muxed into MODE(3) which are the respective mmc0_dat4-7 signals. These signals are correctly being muxed as MII1 (mux mode 0) in both the U-boot and Linux src code, and I have not seen one bit of code that would mux them into MODE(3). All other MII-related signals are correctly in MODE(0). Is this an unforeseen issue with booting from MMC0, or does anyone have any other insight to offer?

Thanks,
Russell 

  • 0
    TI__Guru 64305 points

    What boot mode are you selecting with the SYSBOOT inputs?  Have you read the Booting section of the AM335x TRM?  Please read the following note take from this section of the TRM.

    Note: For any SYSBOOT value that is selected, please be aware of the pin muxing implications. For example, if the boot mode selected is EMAC1, NAND, SPI0, NANDI2C, the device will drive EMAC, GPMC, SPI and I2C pins, in that order, depending on which boot device finally succeeds. Ensure that if a specific boot mode in the sequence chosen is not used that the components using those particular signals do not conflict with the ROM driving those signals (or external components are not in contention with the ROM using these signals). For specific details of the pins driven by each device, please refer the description of that boot device later in this chapter.

    Regards,
    Paul

  • 0 in reply to peaves
    Prodigy 60 points

    Yes, I have read and referenced the TRM.

    SYSBOOT[4:0] = 10011b
    Sequence: NAND -> NANDI2C -> MMC0 -> UART0

    We are currently booting with MMC0.

    Pins used for MMC0 boot, according to TRM:  mmc0_clk, mmc0_cmd, mmc0_dat0, mmc0_dat1, mmc0_dat2, mmc0_dat3

    This should not conflict, and u-boot/linux mii1_pin_mux structs and init functions should modify the pins I mentioned in my original post regardless. Are mmc0_dat4-7 (mux mode 3 of certain mii1 pins) being controlled by the boot process even though they shouldn't be? Is there additional information I am missing?

    Thanks,
    Russell

  • 0 in reply to Russell Robinson74
    TI__Guru 64305 points

    Let me summarize my understanding of the issue then ask a few questions to clarify a few things.

    After booting, some of the terminals connected to a MII PHY are configured in mode 3 when they should be in mode 0.  You have looked through the U-boot and Linix source code and can not find where these are being configured to mode 3.

    Your original post seemed to indicate you are currently trying to use MII rather than RMII because AM335x can not source the RMII reference clock to the PHY.  Most RMII PHYs can be configured to source the 50MHz reference similar to the MII PHY sourcing the TXCLK and RXCLK.  So you should still be able to use RMII if you do not need to boot from Ethernet.  Booting from Ethernet is a problem when using RMII because the ROM code does not disable the un-useable AM335x RMII1_REFCLK output which would conflict with the external reference clock source.

    Do you need to boot from Ethernet?  If not, you may still be able to use an RMII.

    Let's assume we still need to understand what is happening with MII.  You mentioned this interface seemed to work as expected when you tried to boot from MII1.  The SYSBOOT configuration mentioned in your previous post does not support Ethernet boot.  Did you temporarily change the SYSBOOT configuration to test that mode of operation?

    Since the ROM is booting from MMC0, it may be configuring the MII terminals to mode 3.  I do not have an explanation why the MII terminals would be configured for mode 3 based on you comment related to U-boot and Linux code which is executed after the ROM code has booted AM335x.  I can only assume the U-boot or Linux code that configures these terminals back to mode 0 is not being executed.

    This appears to be a software issue.

    Regards,
    Paul

  • 0 in reply to peaves
    Prodigy 85 points

    Hi,


    I'm currently facing the same issue on our board. It doesn't seem that the txen signal is getting asserted. I checked the pin muxing through debugfs but GMII1 is set to mode 0 therefore it should be correct.


    Thank you for your support,


    Ivan