Hi Andrew, On Sat, Sep 26, 2020 at 2:41 AM Andrew Lunn <and...@lunn.ch> wrote: > > > The reference code I linked tries to detect the RGMII interface mode. > > However, for each board we know the phy-mode as well as the RX and TX > > delay - so I'm not trying to port the RGMII interface detection part > > to the mainline driver. > > > > on X96 Air (which I'm using for testing) Amlogic configures phy-mode > > "rgmii" with a 2ns TX delay provided by the MAC and 0ns RX delay > > anywhere (so I'm assuming that the board adds the 2ns RX delay) > > Hi Martin > > It would be unusual to have an asymmetric design in the PCB. So i > would try to prove that assumption. It could be the PHY driver is > broken, and although it is configured to use RGMII, it is actually > inserting a delay on RX. Also check if the PHY has any strapping. I checked this again for the vendor u-boot (where Ethernet is NOT working) as well as the Android kernel which this board was shipped with (where Ethernet is working) - in u-boot the MAC side adds a 2ns TX delay and the PHY side adds a 2ns RX delay - in Linux the MAC side adds a 2ns TX delay and the RX delay is turned off (for both, MAC and PHY)
> > I am aware that the recommendation is to let the PHY generate the delay. > > For now I'm trying to get the same configuration working which is used > > by Amlogic's vendor kernel and u-boot. > > > > > Is there any documentation as to what the calibration values mean? I > > > would just hard code it to whatever means 0uS delay, and be done. The > > > only time the MAC needs to add delays is when the PHY is not capable > > > of doing it, and generally, they all are. > > > This calibration is not the RGMII RX or TX delay - we have other > > registers for that and already know how to program these. > > O.K. so maybe this is just fine tuning. Some PHYs also allow this. > > > What I can say is that u-boot programs calibration value 0xf (the > > maximum value) on my X96 Air board. With this I cannot get Ethernet > > working - regardless of how I change the RX or TX delays. > > If I leave everything as-is (2ns TX delay generated by the MAC, 0ns RX > > delay, ...) and change the calibration value to 0x0 or 0x3 (the latter > > is set by the vendor kernel) then Ethernet starts working. > > So there is just one calibration value? So it assumes the calibration > is symmetric for both RX and TX. yes, there's only one calibration value the reference code is calculating the calibration setting for four configuration variants: - 2ns TX delay on the MAC side, no RX or TX delay on the PHY side, RGMII RX_CLK not inverted - 2ns TX delay on the MAC side, no RX or TX delay on the PHY side, RGMII RX_CLK inverted - 2ns TX delay on the MAC side, 2ns RX delay on the PHY side, RGMII RX_CLK not inverted - 2ns TX delay on the MAC side, 2ns RX delay on the PHY side, RGMII RX_CLK inverted now that I'm writing this, could it be a calibration of the RX_CLK signal? The TX delay is fixed in all cases but the RX delay and RX_CLK signal inversion are variable. > What PHY is it using? > > https://dpaste.com/2WJF9EN suggests it is a RTL8211F. indeed, it's a RTL8211F > This device does have stripping to set the default delay. Can you > check if there are pull ups on pins 24 and 25? I checked it in software (see above) to let you sanity-check this: in vendor u-boot I read: reg 0x11=0x9 and reg 0x15=0x19 in the Android kernel shipped with the board I have: reg 0x11=0x9 and reg 0x15=0x11 note: I haven't found a way to "fix" Ethernet in u-boot so far. I cannot get the exact u-boot copy that's used on my board (since there's no vendor to contact). so I'm careful with interpreting what I'm seeing in u-boot if you really want me to I can check the pull-ups but I prefer not to since I managed to short and break tiny solder joints in the past - and I only have one of these boards for testing > What i find interesting is in the driver is: > > ret = phy_modify_paged_changed(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, > val_txdly); > > ret = phy_modify_paged_changed(phydev, 0xd08, 0x15, RTL8211F_RX_DELAY, > val_rxdly); > > Different registers, 0x11 vs 0x15. In the datasheets i found with > google, none describe any of these bits, but at least register 0x15 is > mentioned, where as register 0x11 is not. > > Git blame shows you added this! Are you sure about this? It seems odd > they are in different registers. I asked Realtek about it back then and they were kind enough to reply - so I got this information from Realtek double-checking with my old mails (I have to type what's shown in the screenshot as I'm allowed to share the info but not the screenshot that I received): Function Name: Manually Enable TXDLY Function Description: Enable TXDLY by registers (default by hardware pin configuration) RTL8211F series: Page: 0xd08, Reg 17, bit[8] = 1 Function Name: Manually Enable RXDLY Function Description: Enable RXDLY by registers (default by hardware pin configuration) RTL8211F series: Page: 0xd08, Reg 21, bit[3] = 1 In the meantime Amlogic's "hacked" PHY driver is also using these registers: [0] So I assume that I'm doing the right thing in the Realtek PHY driver Best regards, Martin [0] https://github.com/khadas/linux/blob/d140398907da5a3f4f7dba2acd336e2ef469bac2/drivers/net/phy/realtek.c#L174
