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>