From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5559EC47096 for ; Thu, 3 Jun 2021 13:57:28 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E229600EF for ; Thu, 3 Jun 2021 13:57:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E229600EF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F1AFF82B8D; Thu, 3 Jun 2021 15:57:23 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 2AB4D82EF0; Thu, 3 Jun 2021 15:57:22 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 8771E81E92 for ; Thu, 3 Jun 2021 15:57:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F11B111FB; Thu, 3 Jun 2021 06:57:15 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CECF23F73D; Thu, 3 Jun 2021 06:57:14 -0700 (PDT) Date: Thu, 3 Jun 2021 14:56:47 +0100 From: Andre Przywara To: Andreas Rehn , linux-sunxi Cc: hdegoede@redhat.com, Jagan Teki , icenowy@aosc.io, u-boot@lists.denx.de, Heinrich Schuchardt Subject: Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout Message-ID: <20210603145647.3e0ae706@slackpad.fritz.box> In-Reply-To: References: <20210519194208.515548-1-rehn.andreas86@gmail.com> <20210519194208.515548-7-rehn.andreas86@gmail.com> <20210519224451.18d6ccfd@slackpad.fritz.box> <20210520011804.208c9b5c@slackpad.fritz.box> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.4 at phobos.denx.de X-Virus-Status: Clean On Fri, 21 May 2021 22:14:00 +0200 Andreas Rehn wrote: Hi, > sorry for the late response. same ;-) > I run some test runs and maybe there is something with the phy itself > or something is missing on sun8i_emac_eth_stop/start? > > if you have any patches/ideas to test - let me know! > maybe someone has an idea how I can try to force the Linux mainline driver > in the same situation? > just want to know if there is the same behavior. So... I think there are at least three different problems at play here: 1) EMAC soft reset timeout: as mentioned, I believe the timeout value itself is a red herring, as it is an automatic operation (the bit flips back to 0 once the reset is done). Waiting much longer sounds weird, the MAC should reset immediately, since at this point it doesn't talk to anyone: it just pushes the "reset switch" on its internal state. However there might be more to it, see below. 2) TFTP timeout and resulting slow transfer speed: This is a totally unrelated and somewhat normal behaviour: TFTP uses UDP, so it's not connection oriented. UDP packets might get lost, for instance due to collisions on the wire. TCP handles those loses transparently and swiftly, that's why you don't notice them there. What makes this so annoying is the long timeout value of 5 seconds, which drastically reduces the overall transfer rate. You can tweak this value by changing TIMEOUT at the beginning of net/tftp.c. If you put 100 there, you will probably barely notice them anymore. The 5 seconds seem to come from the TFTP RFC, so it's hard to argue against it. 3) PHY autonegotiation timeout: This is again independent from the others, especially the MAC soft reset timeout. U-Boot's network stack tries to speak to the PHY via the MDIO bus: PHY_ANEG_TIMEOUT is the macro putting a limit here. There is currently the default 4 seconds fallback value in effect for sunxi here: this might be too short for some situations. Grep for that value to find much longer timeouts for some other platforms. You can try to define this for the V3s in include/configs/sunxi-common.h, and see if that improves things. Happy to take a patch to that effect. Regarding 1): Heinrich reported the same problem on a H3 board, and bisected it down to some other patch. This again does not seem to be related, and I start to wonder if we indeed handle the soft reset wrongly, as mentioned in you v2 patch. I will have a closer look later at when exactly we issue the soft reset, maybe we do it too often? We probably should do it only once, and not on every new network request. Or maybe we need some delay after the soft reset returns, because it's doing so prematurely? But just dropping it does not sound right, although it's interesting that Linux doesn't need it. > > test-scenario: > download 10 times zImage and dtb over tftp, > static ip, no reset, timeout = 1000 > 10 duplex half: > soft reset time 0us with 3 tftp timeouts and recover > lowest speed: 369.1 KiB/s > max speed: 779.3 KiB/s > 10 duplex full: > soft reset time 0us with 0 tftp timeouts and recover > lowest speed: 656.3 KiB/s > max speed: 752.9 KiB/s > 100 duplex half: > soft reset time 0us with 1 tftp timeout and recover > lowest speed: 1.6 MiB/s > max speed: 2.7 MiB/s > > 100 duplex full: what are those values before and after the comma below? Cheers, Andre > try1: 0us, 630000 us with 0 tftp timeout and recover > try2: 1001000 us sun8i_emac_eth_start: Timeout > -> 5 times > -> reconnect cable > try3: 382000us, 502000us with 0 tftp timeout and recover > try4: 330000 us, 1001000 us sun8i_emac_eth_start: Timeout > -> 2 times > -> 192000 us > try5: power up with cable pluged in: > 58000 us, 373000 us with 0 tftp timeout and recover > try6: 354000 us, 494000 us with 0 tftp timeout and recover > try7: 1001000 us sun8i_emac_eth_start: Timeout > -> 3 times > -> 1001000 us sun8i_emac_eth_start: Timeout, 626000 us > next tries with fresh startup > try8: 845000 us, 594000 us > try9: 903000 us, 479000 us > try10: 638000 us, 500000 us > try11: 1001000 us sun8i_emac_eth_start: Timeout, 333000 us > try12: 63000 us, 489000 us > lowest speed: 1.6 MiB/s > max speed: 2.7 MiB/s > > when switching from 100 duplex half to full and try to run tftp download > for zImage and dtb > try1: > reset MAC done after: 0 us > ethernet@1c30000 Waiting for PHY auto negotiation to complete......... > TIMEOUT ! > reset MAC done after: 0 us > ethernet@1c30000 Waiting for PHY auto negotiation to complete......... > TIMEOUT ! > try2: > reset MAC done after: 0 us > Using ethernet@1c30000 device > TFTP from server 192.168.5.80; our IP address is 192.168.5.78 > Filename 'zImage'. > Load address: 0x42000000 > Loading: > ################################################################# > ################################################################# > ################################################################# > ################################################################ > 2.4 MiB/s > done > Bytes transferred = 3790520 (39d6b8 hex) > reset MAC done after: 1001000 us > sun8i_emac_eth_start: Timeout > > > Am Do., 20. Mai 2021 um 02:18 Uhr schrieb Andre Przywara < > andre.przywara@arm.com>: > > > On Thu, 20 May 2021 00:10:47 +0200 > > Andreas Rehn wrote: > > > > > hey, > > > > > > sure. I give it a try tomorrow. > > > with 250 ms, for example, I ran into timeouts after the first tftp > > download. > > > after a manual retry, it works fine but retry is not a valid production > > > behavior. > > > > Just read the arch timer after the SOFT_RST write and after the first > > read of 0 again, and I got 17-18 ticks on my OrangePi Zero (H2+). So at > > 24MHz this is less than a *micro*second for the MAC to reset. So the 10 > > ms are already plenty. > > Are you sure that it's this timeout value that is improving things for > > you? > > > > Cheers, > > Andre > > > > > greetings > > > Andreas > > > > > > Am Mi., 19. Mai 2021 um 23:45 Uhr schrieb Andre Przywara < > > > andre.przywara@arm.com>: > > > > > > > On Wed, 19 May 2021 21:42:08 +0200 > > > > Andreas Rehn wrote: > > > > > > > > Hi, > > > > > > > > > v3s emac soft reset tooks quit longer if autonegation is active > > > > > on 100 Mbit full duplex pairs what can result in > > > > > `sun8i_emac_eth_start: Timeout` error > > > > > > > > Mmmh, why the 500ms? Can you figure out how long it typically > > > > takes for you? By open-coding wait_for_bit_le32() and printing the time > > > > it took to flip the bit back? > > > > > > > > Happy to change this then when we have some data. > > > > > > > > Cheers, > > > > Andre > > > > > > > > > wait_for_bit_le32 polls register value each ms. > > > > > Increasing the timeout for setup do not effect current behavior > > > > > but reduces unexpected behaviors (e.g. timeouts on tftp download). > > > > > > > > > > Signed-off-by: Andreas Rehn > > > > > --- > > > > > drivers/net/sun8i_emac.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c > > > > > index 0e7ad3b0d4..23fd35f9e1 100644 > > > > > --- a/drivers/net/sun8i_emac.c > > > > > +++ b/drivers/net/sun8i_emac.c > > > > > @@ -475,7 +475,7 @@ static int sun8i_emac_eth_start(struct udevice > > *dev) > > > > > /* Soft reset MAC */ > > > > > writel(EMAC_CTL1_SOFT_RST, priv->mac_reg + EMAC_CTL1); > > > > > ret = wait_for_bit_le32(priv->mac_reg + EMAC_CTL1, > > > > > - EMAC_CTL1_SOFT_RST, false, 10, true); > > > > > + EMAC_CTL1_SOFT_RST, false, 500, true); > > > > > if (ret) { > > > > > printf("%s: Timeout\n", __func__); > > > > > return ret; > > > > > > > > > > > > > > > >