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

[Peter Jeremy]

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

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20200701/4fbb8789/attachment.sig>