Page MenuHomeFreeBSD

rgephy: Fix gigabit on some pine64+

Authored by kevans on Dec 22 2017, 9:59 PM.
Referenced Files
Unknown Object (File)
May 3 2023, 5:12 PM
Unknown Object (File)
Apr 11 2023, 4:16 AM
Unknown Object (File)
Mar 4 2023, 8:23 AM
Unknown Object (File)
Feb 15 2023, 5:58 PM
Unknown Object (File)
Feb 14 2023, 9:12 AM
Unknown Object (File)
Feb 10 2023, 12:30 AM
Unknown Object (File)
Feb 1 2023, 5:08 PM
Unknown Object (File)
Dec 16 2022, 2:22 PM



Some pine64 models have a problem with the Gigabit ethernet dropping packets frequently. The Pine64 engineering team's supplied fix is to reconfigure the RTL8211E used to force off TXD/RXD (RXD is defaulting to on, in my checks) and turn on some bits in the configuration register for this PHY that are undocumented.

See: this dual BSD/GPL licensed driver change:

As an aside- I wasn't sure how to handle the specifics of when to apply it, so I opted for doing an FDT check in rgephy_attach and simply enabling a 'quirk' if we're on an affected model and configured for RGMII (uses RTL8211E specifically). I don't know if this 'quirks' flag is overkill since this will probably be our only quirk.

Diff Detail

rS FreeBSD src repository - subversion
Lint Skipped
Tests Skipped
Build Status
Buildable 13899

Event Timeline

I should probably add: Before this, awg0 on my pine64 was previously dropping 3/5 packets, and is now back to 0% packet loss.

1273 ↗(On Diff #36920)

Typo in comment.

This seems like it is too specific to the Realtek PHY used on Pine64 to apply to all A64 boards.

This revision now requires changes to proceed.Dec 22 2017, 10:15 PM
kevans retitled this revision from if_awg: Fix gigabit on some pine64 models to rgephy: Fix gigabit on some pine64+.
kevans edited the summary of this revision. (Show Details)
kevans added a reviewer: ian.
kevans added inline comments.

Only bits 0-9 of the configuration reg are documented; I have no idea what 0xb400 corresponds to, and from the sounds of it the Pine64 team either doesn't know or can't reveal that. They have claimed that it comes from discussion with Realtek engineers, though.

Previously submitted diff was an intermediate where I was testing breakdown of initial magic value; confreg breakdown is actuallly:

8:6 = PHY Address
5:4 = Auto-Negotiation
3 = Mode
2 = RXD
1 = TXD

so we ensure bits 1/2 are off and set 0xb400 lying beyond documented space.

Should we use your u-boot patches instead ?

These patches have made it upstream in 2018.05.