Hi everyone,
I'm trying to add support for D-Link DAP-2360 A1, which is based on AR7242
using an external AR8021
10/100/1000 phy.
However, it would only work flawlessly for 100M, but lots of weird things happen when trying to use 1000M; the connection is very sporadic, lots of TCP timeouts, retransmissions, duplicate acks, packets arrive out of order etc. (resulting in much worse overall performance than 100M).
I currently have:
// edit: please skip to Post #2 for a more sophisticated attempt of solving this, including explanation of pll-regs
meaning
&mdio0 {
status = "okay";
phy-mask = <0x1>;
phy0: ethernet-phy@0 {
reg = <0>;
phy-mode = "rgmii";
};
};
ð0 {
status = "okay";
phy-mode = "rgmii";
phy-handle = <&phy0>;
pll-data = <0x0804081e 0x00000101 0x040800c0>;
};
Even when setting
fixed-link {
speed = <100>;
full-duplex;
};
there is no auto-negotiation, i.e. it would only work when using a 100M switch or by manually setting the computer's network card to 100M.
In 1000M mode, the link state is reported correctly as 1000M on both ends, but not stable.
I see that ar7242.dtsi
overwrites the pll settings for eth0:
pll-data = <0x16000000 0x00000101 0x00001616>;
pll-reg = <0x4 0x2c 17>;
pll-handle = <&pll>;
It's curious though that 17 / 0x11 is not 32bit-aligned, also there is no corresponding register in the AR7242 datasheet (besides DDR_PLL_CONFIG
and ETH_XMII
, which seem plausible), but when dumping the regs via uboot i get this:
ar7240> md 18050004 1
18050004: 0804081e ....
ar7240> md 1805002c 1
1805002c: 00000101 ....
ar7240> md 18050010 1
18050010: 00040800 ....
ar7240> md 18050014 1
18050014: c00a0000 ....
ar7240>
which I initially attempted to interpret as
pll-data = <0x0804081e 0x00000101 0x040800c0>;
The phy is using an external 25 MHz crystal, so all the pll stuff should probably just be related to the SoC clock when communicating with the phy...
So, what exactly does pll-data do, will it overwrite the SoC PLL registers starting at 0x18050000
with those values, or will it just use them to calculate stuff for the phy timing?
The only register using the address 0x11
would be PHY_STATUS
that can be accessed via MDIO, but that one is read-only (the contents being 0x7c52
after uboot initialisation). So, what exactly is the third cell for?
I could not find much about phy pll in the devicetree bindings Documentation, however I stumbled on this (not sure if eee is even relevant for such an old phy):
From source/Documentation/devicetree/bindings/net/phy.txt
:
- eee-broken-100tx:
- eee-broken-1000t:
- eee-broken-10gt:
- eee-broken-1000kx:
- eee-broken-10gkx4:
- eee-broken-10gkr:
Mark the corresponding energy efficient ethernet mode as broken and
request the ethernet to stop advertising it.
Also I see there are modes that change the configuration of additional timing used with other ath79 devices; the AR8021 databrief states
RGMII timing modes: support both internal delay and external delay on both Rx and Tx paths
but trying rgmii-id
or rdmii-rxid
did not change anything either.
I only found a driver for ar8031, so ar8021 should probably work with a generic one (I guess also ar8031 would just include additional functionality besides the IEEE compliant gmii interface!?)
So at this moment, I'm not sure what could be the next thing to try...
Any help or documentation regarding the pll-data
dt-binding is appreciated