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=-12.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 A9366C47096 for ; Thu, 3 Jun 2021 14:43:49 +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 7501A613D8 for ; Thu, 3 Jun 2021 14:43:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7501A613D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de 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 084FF82F47; Thu, 3 Jun 2021 16:43:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="JEQAN/EF"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5B51582FAC; Thu, 3 Jun 2021 16:43:44 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E79A382F3C for ; Thu, 3 Jun 2021 16:43:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622731404; bh=yrPs837wm2HUZ3WsRlx67STB4nXnosacq91dxL0EYf4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=JEQAN/EFv1O5s2tl97ubJlcadAh4/rp41NCbGWZ6zYHCkj30hce6S8dTwtWQd8NN9 QGQZD1rA/10C/yNh/t3rc8V3KfORuMYqto+SmrcXHVh5zGVxuLjyx21osmntDdxyZx RryqCIdiTGY8sD8O81Sl0OOryXmARFDv3nezeDaY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.35] ([62.143.247.63]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MfHEJ-1l9iBk3knT-00gtHZ; Thu, 03 Jun 2021 16:43:23 +0200 Subject: Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout To: Andre Przywara , Andreas Rehn , linux-sunxi Cc: hdegoede@redhat.com, Jagan Teki , icenowy@aosc.io, u-boot@lists.denx.de, Joe Hershberger , Ramon Fried 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> <20210603145647.3e0ae706@slackpad.fritz.box> From: Heinrich Schuchardt Message-ID: <3d2ced18-adc8-f5b0-5867-1373dd82693b@gmx.de> Date: Thu, 3 Jun 2021 16:43:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210603145647.3e0ae706@slackpad.fritz.box> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ppoMKVFsolg5J2aTeyOPl76yd4AogIRCaKIDRnhPL/ZncVvG9+Z pFmLGUcFPojEKWwOWSYcIdkrN4dpzuoxYy0UsoJFcNT1sntBeZuNf9AuBDoTVmK6WTO6t/K qbyFYKcREUNksKkeaZjO43qsKkxyeg9GmXNTj+M1s7gyayIcLJBr7WzHW9Av6eFA3TRJ9A+ ZhN9m2ptqAGbwwpD/DeDA== X-UI-Out-Filterresults: notjunk:1;V03:K0:+lF9ZVLh+ow=:rRrN0Ffbz0UpgRQe4pAWxF eqyBF1Ex07V3t990U1t7fNXokE/WbPS6Oa/0dWCEyQgOOwlDEn/xhJUjRhVCr57MK2o2ln0IT TOQKOJZ0YeRhtm9I4zOsc6xYFNpQDHJrhDSsIpB/Y7ZiE+NLjm8Zciejdb+kUZVCgUiFoAf8T 8jqqvSf7nI3LV5wyFGgsPh2GZ7N1sh8Bvi7DYlKk5ScGF52puqkG1ikhbh4Utg0Ch8UjFcebY Uix1nqlh62xBTTeXNj0igvRIb3ofnClZb6rFIir9xbLaW0Gk5TgC+RAFoaBSUeaKZr8S5WO3K eRep8DbfKsp6KJKP4LkOCa/Y+cq533yEeHlgiQ7RAdHZe7P2EAJh7pC4Ga4HSEik3U3gnqgFd zgrPeqUsSYtntO5TTX7dAw96AG5TvxcjpjzuJoQzO1FcWH7MjPXjOzShWT5Jz7qkEXqzqDUqD Q12GTzJeYiHn/3jcusbi6DKndhdtiHy0BNZLqlmUCngK2o6HS6subf3EFVQNWi9ZZhEVvACgI b/79p/abglgOLTL/Ua1HeqBwflUDoiDOGWelpsnLChb2BuMvADaoEgRQt5yqDZQxirvB5dw7u RWXLegY+lsg7detdWBKyjz0JH61UpRTpqjBxhJzTwo+I24NsTmyjq91l1xSw0gI3Z+tU1FRTs gRWttsomp2HGh4irrYHLtamDqvttZIStYCOeXmwiqUgxQoSxdg7E0QXsQjxrt8zkFvO+i9qLv /ZV3F/RIYb1fn9+3bXqm6Ll3NVohi5gNMSb22uOBBYnWTiTQewjxlg/hExbDyRIUZ3xRdI7Id zauINAWjjNeUcIODO+rlyji5rgRyNaao20NTTrhFkC1UVHBTmQeo0RkO4uviubVtIxLsJv5C6 samP01U9c9XXW/V26utgpGzM7CAHB6l4Fp0pFYLYS8SsM5nQ9tJYmreTFnLedqX/jk9CF6CLV B9WiCqNbwr7N8iWHoW9eviRvNx/kJ3evQgJvebsx6+KVzSW4DHIaQItrTRW4HTTGPfzEYS8/b gZ3fmXeHdHP332jzmFPmojGHDdU1avW0gO7qvE5Xe+vyhULajlkfYymiSvQCSMG1GMNQJlUWe Tf/qVn5E4HAkFZNDY/q1cLjzykSNmuFkVPf 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 6/3/21 3:56 PM, Andre Przywara wrote: > 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 dri= ver >> 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. Applying net: sun8i-emac: v3s: fix soft reset timeout https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.201471-1-r= ehn.andreas86@gmail.com/ and /* Soft reset MAC */ - if (!IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) { + if (1 || !IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) { does not solve the problem I see on the OrangePi PC: =3D> dhcp sun8i_emac_eth_start: Timeout So it seems we are talking about different issues. Applying "net: sun8i-emac: v3s: fix soft reset timeout" on top of "net: sun8i-emac: fix MDIO frequency" https://patchwork.ozlabs.org/project/uboot/patch/20210603075242.96527-1-xy= pron.glpk@gmx.de/ does not do any harm nor does it show any benefit for tFTP transfer on the OrangePi PC. Best regards Heinrich > >> >> test-scenario: >> download 10 times zImage and dtb over tftp, >> static ip, no reset, timeout =3D 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: Timeou= t >> -> 2 times >> -> 192000 us >> try5: power up with cable pluged in: >> 58000 us, 373000 us with 0 tftp timeout and recove= r >> try6: 354000 us, 494000 us with 0 tftp timeout and recov= er >> try7: 1001000 us sun8i_emac_eth_start: Timeout >> -> 3 times >> -> 1001000 us sun8i_emac_eth_start: Timeout, 62600= 0 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 u= s >> 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 downloa= d >> 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 =3D 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 producti= on >>>> 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 a= t >>> 24MHz this is less than a *micro*second for the MAC to reset. So the 1= 0 >>> 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 t= ime >>>>> 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 =3D 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; >>>>> >>>>> >>>> >>> >>> >> >