RK3328/Rock64 GigE testers needed.

[Charles]

Hi gonzo, Mark,

If this patch and tuning settings are not help, do I have to solder like 
mentioned in 
https://sanisimov.com/2019/08/fixing-rock64-v2-gigabit-ethernet/ ?

Just for the case, I bought some resistors.

I would like to know why the interface works stable with linux.

Best,
C.

Am 09.07.20 um 22:35 schrieb Oleksandr Tymoshenko:
> Peter Jeremy (peter at rulingia.com) wrote:
>> Head r362736 has enabled the internal RGMII delay lines in the RK3328
>> (and RK3399) and this breaks networking on my Rock64 v2.0 (that I've
>> modded to use the higher RGMII bus voltage, as per the v3.0).
>>
>> gonzo@ and I would be interested in other people's experiences with
>> this revision - particularly other people with Rock64 v2 or Rock64 v3
>> boards.
> 
> Thanks to everyone for tests, it looks like only Peter's device
> networking was completely broken by the commit. As a possible workaround
> I consider adding a tunable/sysctl that can be used to override the delay
> in DTB.  The change is available in this patch:
> https://people.freebsd.org/~gonzo/patches/rockchip-gmac-202007009.patch
> 
> This is WIP on improving if_dwc_rk and contains following changes
> 
> - Enable and dump gmac clocks frequencies. RK3328 does not have ethernet
>    clocks implemented yet so this part fails on the SoC.
> 
> - Configure clock according to the sensed media. I was able to switch
>    between 100 and 1000 switches on both Rock64 and on Firefly-RK3399
> 
> - Introduces tunable and sysctl dev.dwc.X.delays (where X is a unit
>    number, e.g. 0, 1... etc. The value is (rx_delay << 8) | tx_delay,
>    so adding dev.dwc.0.delays=0x4533 to loader.conf would set rx delay to 69
>    and tx delay to 51. It's possible to change delays run-time using
>    sysctl too so people can experiment with values fast.
> 
> - Print delay values and enable flags when changing delays. This should
>    be useful to get the delay values set by U-Boot and that worked before
>    the r362736.
> 
> The patch does not have any performance improvements, so there is no
> need to re-run tests.
>