Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jul 2020 13:54:38 -0700
From:      Oleksandr Tymoshenko <gonzo@freebsd.org>
To:        Peter Jeremy <peter@rulingia.com>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r362736 - head/sys/arm64/rockchip
Message-ID:  <20200706205438.GA94576@bluezbox.com>
In-Reply-To: <20200705000739.GE30039@server.rulingia.com>
References:  <202006282111.05SLBAAq025544@repo.freebsd.org> <20200701085747.GA23928@server.rulingia.com> <20200701124738.GA30133@server.rulingia.com> <20200703002623.GA18584@bluezbox.com> <20200705000739.GE30039@server.rulingia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy (peter@rulingia.com) wrote:
> On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko <gonzo@freebsd.org> wrote:
> >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
> 
> It's still not working for me.  I get the following:
> dwc0: <Rockchip Gigabit Ethernet Controller> mem 0xff540000-0xff54ffff irq 44 on ofwbus0
> setting RK3328 RX/TX delays:  24/36
> >>> RK3328_GRF_MAC_CON1 (00000413):
> >>>     gmac2io_gmii_clk_sel: 0x0
> >>>     gmac2io_rmii_extclk_sel: 0x1
> >>>     gmac2io_rmii_mode: 0x0
> >>>     gmac2io_rmii_clk_sel: 0x0
> >>>     gmac2io_phy_intf_sel: 0x1
> >>>     gmac2io_flowctrl: 0x0
> >>>     gmac2io_rxclk_dly_ena: 0x1
> >>>     gmac2io_txclk_dly_ena: 0x1
> >>> RK3328_GRF_MAC_CON0 (00000c24):
> miibus0: <MII bus> on dwc0
> rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0
> rgephy0: OUI 0x00e04c, model 0x0011, rev. 6
> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto

Thanks for running the test. Register values seem OK :(
 
> >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.
> 
> I've asked on -arm if anyone else has tried this on a Rock64 v2 or v3.
> 
> >If the clock fix doesn't help, I'll make
> >delays configuration run-time configurable with off by default until
> >more hardware is tested.
> 
> That sounds like a good way forward - maybe boot and run-time configurable.
> It's a pity that there doesn't seem to be any documentation on what the
> numbers represent (or what the "default" value is) - which means that
> actually adjusting the delay numbers would be very time consuming.

There are no "default" values AFAIK. They depend on the board schematics.
I was told that Rockhip partners use some kind of proprietary tool
which they feed with values based on the scematics (like trace lengths)
and tool calculates delays.

With boot-time or run-time configuration I think it's possible to
automate the search for good value. Something like this:
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test

but with loader.conf modifications instead of DTB

-- 
gonzo



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