svn commit: r362736 - head/sys/arm64/rockchip

[Oleksandr Tymoshenko]

Peter Jeremy (peter at rulingia.com) wrote:
> On 2020-Jul-01 18:57:47 +1000, Peter Jeremy <peter at server.rulingia.com> wrote:
> >On 2020-Jun-28 21:11:10 +0000, Oleksandr Tymoshenko <gonzo at FreeBSD.org> wrote:
> >>Log:
> >>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
> >>  
> >>  For 1000Mb mode to work reliably TX/RX delays need to be configured
> >>  between the TX/RX clock and the respective signals on the PHY
> >>  to compensate for differing trace lengths on the PCB.
> >
> >This breaks (at least) diskless booting on my Rock64.
> 
> I've studied the RK3328 TRM[1] and the RK3328 code following r362736
> matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574
> says the delay line is configured via GRF_SOC_CON3 - which doesn't
> match the documentation on GRF_SOC_CON3 on p175-177).  That suggests
> that the delay values in the FDT are incorrect.  Unfortunately, the
> TRM doesn't include any details on how to configure the delay values
> so it's difficult to adjust the numbers in the FDT.
> 
> One possible explanation I have is that there are (at least) 2
> different Rock64 variants.  Later versions have increased the RGMII
> bus voltage to improve GigE reliability.  I initially had problems
> with GigE reliability and mod'd my Rock64[3] to use the higher RGMII
> bus voltage - which made it rock solid at GigE.  It's possible that
> different variants need different delay values, due to different track
> skew or different driver behaviour at different bus voltages.
> 
> [1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
> [2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of
>     RK3328_GRF_MAC_CON0_RX_MASK but the values are the same).
> [3] Move 1 resistor to change a pull-up to a pull-down

Hi Peter,

Could you try kernel with this patch? It's mostly debug output,
with one possible clock-related fix.

https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch

I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so
my tests are not reliable. I'll try to get another RK3328 board for tests,
but it may take some time. If the clock fix doesn't help, I'll make
delays configuration run-time configurable with off by default until
more hardware is tested.

-- 
gonzo