Re: RGMII timing calibration (on 12nm Amlogic SoCs) - integration into dwmac-meson8b

[Martin Blumenstingl <martin.blumenstingl@googlemail.com>]

Hi Andrew,

On Sat, Sep 26, 2020 at 4:45 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > 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
>
> So that suggest there is nothing on the PCB. It is all down to MAC and
> PHY adding delays.
u-boot with it's 2ns RX delay is the non-working case
only if I manually turn off the 2ns RX delay generated by the PHY in
u-boot (phyreg w 0x1f 0xd08; phyreg w 0x11 0x9; phyreg w 0x15 0x11;
phyreg w 0x1f 0x0; phyreg w 0x0 0x9200) I can get ping/tftpboot to
work

the Android kernel disables the 2ns RX delay on the PHY side (and as
far as I can tell does NOT enable it on the MAC side). with that
Ethernet is working

> > 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?
>
> Yes, seems like it. Which of these four does it end up using? I'm
> guessing the 3rd?
I need to double-check but if I remember correctly was close between
the first and last one (and I think the first case won)

> So i would forget about configuration clock inversion. Hard code it to
> whatever works. It is not something you see other MAC/PHY combinations
> allow to configure.
we have inversion hard-coded to "off". I'm not planning to take this
into consideration unless there's a good reason to do so

> I think you said a value of 0x2 works. I wonder if that corresponds to
> something slightly larger than 0ns if option 3 is being used?
I have tested 0x0, 0x3, 0x4 and 0xf
the first three values are working, but 0xf isn't.

I'll try to reach someone at Amlogic to clarify the meaning of these
new register bits.
I guess Florian's patch is a good starting point for what I need -
thanks again for the suggestion Vladimir.


Thank you all!
Best regards,
Martin