From owner-svn-src-all@freebsd.org Fri Jul 3 00:26:31 2020 Return-Path: Delivered-To: svn-src-all@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 711B0363A55; Fri, 3 Jul 2020 00:26:31 +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 49ybP30z2Lz4Sk4; Fri, 3 Jul 2020 00:26:30 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92 (FreeBSD)) (envelope-from ) id 1jr9X6-0004v1-2I; Thu, 02 Jul 2020 17:26:24 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id 0630QNEe018910; Thu, 2 Jul 2020 17:26:23 -0700 (PDT) (envelope-from gonzo@freebsd.org) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@freebsd.org using -f Date: Thu, 2 Jul 2020 17:26:23 -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: <20200703002623.GA18584@bluezbox.com> References: <202006282111.05SLBAAq025544@repo.freebsd.org> <20200701085747.GA23928@server.rulingia.com> <20200701124738.GA30133@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200701124738.GA30133@server.rulingia.com> X-Operating-System: FreeBSD/11.2-RELEASE-p10 (amd64) User-Agent: Mutt/1.12.1 (2019-06-15) 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-01 18:57:47 +1000, Peter Jeremy wrote: > >On 2020-Jun-28 21:11:10 +0000, Oleksandr Tymoshenko wro [...] 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: 49ybP30z2Lz4Sk4 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-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 00:26:31 -0000 Peter Jeremy (peter@rulingia.com) wrote: > On 2020-Jul-01 18:57:47 +1000, Peter Jeremy wrote: > >On 2020-Jun-28 21:11:10 +0000, Oleksandr Tymoshenko wrote: > >>Log: > >> Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC > >> > >> For 1000Mb mode to work reliably TX/RX delays need to be configured > >> between the TX/RX clock and the respective signals on the PHY > >> to compensate for differing trace lengths on the PCB. > > > >This breaks (at least) diskless booting on my Rock64. > > I've studied the RK3328 TRM[1] and the RK3328 code following r362736 > matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574 > says the delay line is configured via GRF_SOC_CON3 - which doesn't > match the documentation on GRF_SOC_CON3 on p175-177). That suggests > that the delay values in the FDT are incorrect. Unfortunately, the > TRM doesn't include any details on how to configure the delay values > so it's difficult to adjust the numbers in the FDT. > > One possible explanation I have is that there are (at least) 2 > different Rock64 variants. Later versions have increased the RGMII > bus voltage to improve GigE reliability. I initially had problems > with GigE reliability and mod'd my Rock64[3] to use the higher RGMII > bus voltage - which made it rock solid at GigE. It's possible that > different variants need different delay values, due to different track > skew or different driver behaviour at different bus voltages. > > [1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf > [2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of > RK3328_GRF_MAC_CON0_RX_MASK but the values are the same). > [3] Move 1 resistor to change a pull-up to a pull-down Hi Peter, 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 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. If the clock fix doesn't help, I'll make delays configuration run-time configurable with off by default until more hardware is tested. -- gonzo