• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 173 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

AM4378: AM4378 not properly working with the ethernet phy

AM4378: Follow up from AM4378 not properly working with the ethernet phy

Lauren Mayfield
Expert 7635 points
Part Number: AM4378
Other Parts Discussed in Thread: DP83867IR

Hello, this is a follow up from this post: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1030268/am4378-am4378-not-properly-working-with-the-ethernet-phy

They found some time to get back to this and got some new observations:

 

  • Boot ROM vector shows speed=100 detected successfully with a 10/100 ethernet detected
  • Vector still shows a GMII PHY detected
  • No bootme’s present doesn’t seem to work
  • U-Boot can probe the PHY and it reported the correct full duplex, 100 speed on start
  • Cannot seem to ping the host in u-boot, may be a device tree issue
  • Examining the CTRL_GMII_SEL register during the boot ROM shows GMII/MII mode selected for port 1, which matches what they see in the ROM vector
  • The CTRL_CONF for the MII1_TX/RX pins are all muxed as GMII, not RGMII
  • Boot vector dump, any JTAG pause with EMAC1 as the primary boot gives this vector:
    0000302E             00000000             04000000             00000000             00000028             00000000

 

They can’t see why GMII is being detected vs RGMII, but that’s where this is stuck. They'll continue to try and fix the u-boot pings, but the boot ROM still looks like it’s bugging out. Any suggestions on what to try next?

Thanks,

Lauren

  • 0
    TI__Expert 7635 points

    Small update for U-Boot:

     

    • They changed the board.c file to use RGMII_ID instead of the RGMII settings
    • The PHY (DP83867IR) communicates in u-boot once they set the RGMII_TX_CLK_DELAY in register 0x32

     

    Does the Boot ROM require different settings? They don’t see a way of configuring the strapping pins to change this register in the PHY. What would they need to change in the layout in order to get this to work out of the box?

  • 0 in reply to Lauren Mayfield
    TI__Expert 7635 points

    Hi, any update on this?

  • 0 in reply to Lauren Mayfield
    TI__Mastermind 39400 points

    Hi,

    Discussing with a fellow team member GMII PHY detection is not possible, this is a reserved value. This could be indicating an issue with the PHY state during Ethernet boot. What you are reporting seems correct except for the GMII detection. The link speed is being set correctly.

    This is a hard area to get information from the PHY at this point in the boot sequence as there is information needed over the MDIO bus. Would you be able connect up a Linux PC as the link partner and run ethtool for the connected interface? I am looking to see what shows up for capability advertising from your board. For example is the link advertising showing what is expected for the way the PHY is strapped? Is half duplex mode being advertised? I would also like to double check that the link speed is 100Mbps.

    My concern with using u-boot is that I am not sure if the cpsw or mdio is initializing the interface from what the ROM has done. My understanding is that u-boot will only init an interface after a command is used on that interface. 

    Our team doesn't support the DP83867 PHY so I will need to refer the strapping question to them. Since RGMII mode is used the internal delay is required as per the TRM.

    Best Regards,

    Schuyler