From owner-svn-src-head@freebsd.org Mon Jul 6 20:54:40 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1EC5D348A17; Mon, 6 Jul 2020 20:54:40 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B0yVl6zPPz4Y7W; Mon, 6 Jul 2020 20:54:39 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from ) id 1jsY8M-000Ogj-BH; Mon, 06 Jul 2020 13:54:38 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 066KschI094904; Mon, 6 Jul 2020 13:54:38 -0700 (PDT) (envelope-from gonzo@freebsd.org) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@freebsd.org using -f Date: Mon, 6 Jul 2020 13:54:38 -0700 From: Oleksandr Tymoshenko To: Peter Jeremy 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> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200705000739.GE30039@server.rulingia.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Peter Jeremy (peter@rulingia.com) wrote: > On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko wrote: > >Could you try kernel with this patch? It's mostly debug output, > >with one [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Rspamd-Queue-Id: 4B0yVl6zPPz4Y7W X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:14061, ipnet:45.55.0.0/19, country:US] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:54:40 -0000 Peter Jeremy (peter@rulingia.com) wrote: > On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko 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: 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: on dwc0 > rgephy0: 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