Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Jul 2020 13:35:32 -0700
From:      Oleksandr Tymoshenko <gonzo@bluezbox.com>
To:        Peter Jeremy <peter@rulingia.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: RK3328/Rock64 GigE testers needed.
Message-ID:  <20200709203532.GA9738@bluezbox.com>
In-Reply-To: <20200705000643.GA63127@server.rulingia.com>
References:  <20200705000643.GA63127@server.rulingia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy (peter@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.

-- 
gonzo



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200709203532.GA9738>