Ethernet – RGMII or only RMII?

[Julien Goodwin]

I’m working on a design to prototype using the OSD335x-SM for a future project, and in starting to draw up the Ethernet PHY I’ve noticed that the OSD335x-SM is set up for RMII, but I was planning on using the TI DP83867CR PHY which is only RGMII, a quick dig into the AM335x datasheet didn’t make it clear if the RGMII control pins are the same as those used for RMII.

Is it actually possible to use RGMII PHYs with the OSD335x-SM, or should I switch to the larger IR PHY and RMII?

[Eshtaartha Basu]

Hello jgoodwin,

The OSD335x-SM does support RGMII. The OSD3358-SM-RED board uses the MII1 interface (in RGMII mode) of OSD335x-SM to communicate with AR8035 Gigabit Ethernet PHY.

The OSD3358-SM-RED design files are available on our website.

RED product page: https://octavosystems.com/octavo_products/osd3358-sm-red/

RED schematics: https://octavosystems.com/docs/osd3358-sm-red-schematics-pdf/

RED design files: https://octavosystems.com/files/osd3358-sm-red-eagle-files/

You can use the RED design as a reference to build your design.

NOTE: On the RED schematics, the signal names of MII1 interface match the pin names but the MII1 interface is being used in Mode 2 (RGMII). You can go through the Pin Attributes section of AM335x datasheet (http://www.ti.com/lit/ds/symlink/am3352.pdf) to know more about GPIO pin modes.

[Julien Goodwin]

Ah thanks, I’d looked at the reference design a while back, which must be why I was pretty sure that RGMII was possible.

Will dig back into it.

[Eshtaartha Basu]

You’re welcome. Please let us know if you need any other information as you proceed with the design.

[Julien Goodwin]

I got the test boards back in August, but it was only last month that I got around to trying the Ethernet bringup.

I’ve run out of ideas as to what’s going wrong, and would appreciate any ideas.

The PHY is detected, as is link (at least at 100Mbit, & 1g, I did a quick test at 10Mb, but didn’t have results logged), and I can see packets travelling in both directions across the RGMII link, however packet counters at each end never show receive packets.

This occurs both in Linux & U-Boot.

Although I didn’t explicitly length-match traces (which I should have), all the MAC->PHY lines are within 4mm, and all the PHY->MAC lines within 5mm. Given the data rates, while this is suboptimal, this seems like it should work. Also despite the straps set for 0 PHY delay I removed those on a test board and the default 2ns delay gives the same result. I note you don’t have any details about length-matched traces like the MII lines in your layout guide, are traces length-matched inside the package?

On the Linux side I also patched up a reset gpio, and confirmed it caused the expected reset, but this didn’t change behaviour.

Relevant subset of schematic:
https://julien.studio442.com.au/images/sip-ethernet-schematic.png

The devicetree chunk:
https://julien.studio442.com.au/sip-ethernet-devicetree.dts

[Julien Goodwin]

After reading TI’s RGMII timing doc (SNLA243) I took at look at the TX/RX enable/error lines, and there I was further out. Still under 10mm, which seems low for causing an issue, given expected signal propegation time, but it was easy enough to re-layout that section and have all match to within 0.5mm.

[Eshtaartha Basu]

Hello Julien,

We’ll need a little more information to debug the problem further:

1. Which utility are you using to observe the packets? Wireshark can be helpful in finding out if the packets are corrupted.
2. Which Debian version are you using?
3. Please share the boot log.

[Julien Goodwin]

“1. Which utility are you using to observe the packets? Wireshark can be helpful in finding out if the packets are corrupted.”

Nothing, the raw interface counters on the switch (Have tested multiple, mainly a Juniper SRX I already had on my desk) confirm no packets are getting to that point. Juniper are pretty good with error counters too, and those aren’t incrementing either.

” 2. Which Debian version are you using?”
Tried both:
bone-debian-9.3-iot-armhf-2018-03-05-4gb.img
bone-debian-9.5-iot-armhf-2018-10-07-4gb.img

For uBoot it’s git head from a few weeks back.

” 3. Please share the boot log.”
There’s nothing useful in the log.

[Eshtaartha Basu]

Hello Julien,

We have never used Juniper SRX so we’re not fully familiar with its operation.

You can do low level software debugging by building on the Starterware code from TI. This will allow you to directly determine the state of the PHY and Ethernet MAC. “cpsw.c” and “mdio.c” under “drivers” directory of TI Starterware software package are useful. The package includes all the necessary include files also. You can build your own C code on top of it to determine the state of PHY and Eth MAC. You can also loop back your connection and examine your packets using python socket programming. If that succeeds, we’d suggest connecting to an actual PC and examining traffic using Wireshark.

[Julien Goodwin]

The Juniper kit is carrier network equipment, I trust its interface counters.

Again, wireshark will say nothing, as packets never reach a level where they could be captured.

I’ll look into the TI Starterware software.

[Eshtaartha Basu]

Hello Julien,

We went back and looked at your schematic again. It looks like your TX_CTRL and RX_CTRL are flipped. According to TI DP83867CR datasheet, TX_CTRL should be pin 37 and RX_CTRL should be pin 38. Please correct the pin hookup and it should solve your problem.

[Julien Goodwin]

Sorry for not replying when I first saw this, but that error would cause exactly the behaviour I was seeing. I fixed that, and length matched within 1mm.

The new boards arrived back from the CM today.

I’ve not yet done a full test, but at least at 100Mbit it’s passing packets enough for uboot to be able to DHCP and try a netboot.

Thank you very much for finding that pin error.

[Eshtaartha Basu]

That’s good news! We’re glad to know that the issue is resolved.

Please let us know if you need anything else.

[Author]

Posts