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

DM8148 Intermittent Ethernet

Jason Chapman
Prodigy 140 points

We have a custom board that connects the DM8148's EMAC1 to a Marvell switch (88E6350R).

To save space and cost we removed the PHYs and connected to one of the switch's MAC-only ports.

We disabled the RGMII delays in the DM8148 and enabled them instead on the switch.

 

U-boot works fine with some minor modifications to the PHY initialization / detection.

The kernel has been configured to use a fixed PHY and convinced the link is always present.

The kernel loads via Ethernet, but won't boot into the file system via NFS. (Appears to be a dropped TCP packet)

If we boot from flash I can ping small packets and telnet in to run a few commands.

Any commands that require a larger packet to be sent from the DM8148 usually fail. (>256MB)

Strictly pinging with 64Bytes we see 1-2% loss or 75% loss if 512Byte packets are sent.

The hw_stats for the CPSW driver show some CRC errors too.

 

It appears that we were having similar issues as in this post:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/241392/857273.aspx#857273

But not luck after implementing the patch.

We are using PSP_04.04.00.01.

 

Any help would be appreciated!

  • 0
    Prodigy 140 points

    Hopefully no one else runs into this issue. We narrowed down the problem to the clock source being used for the RGMII block. After configuring the clock registers to use the 20MHz system clock instead of the SATA SERDES clock, the interface works fine. The downside to this is certain advanced features on the SATA / PCIe interfaces can't be used.

    This is fine for our design, so we won't investigate this further.

  • 0 in reply to Jason Chapman
    Prodigy 210 points

    We have basically the same hardware configuration and I have seen a similar issue, the difference being it seems to clear up with a reboot after the board has been up for a bit.  So it may be something different.

     

    Can you provide a little more detail on the setting change you made?

    Thanks

    Ken

  • 0 in reply to Ken Eppinett
    Prodigy 140 points

    Hi Ken,

    I had to change the reference clock in the SATA PLL configuration funciton, sata_pllcfg(void), in devices.c.

    Specifically bit 30 of the SATA_PLLCFG1 register (offset 0x724) changed from 0 to 1.

    This forces the use of the 20MHz clock instead of the 100MHz one.

    Jason