[PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout
Andreas Rehn
rehn.andreas86 at gmail.com
Thu Jun 3 17:29:17 CEST 2021
Am Do., 3. Juni 2021 um 16:43 Uhr schrieb Heinrich Schuchardt <
xypron.glpk at gmx.de>:
> On 6/3/21 3:56 PM, Andre Przywara wrote:
> > On Fri, 21 May 2021 22:14:00 +0200
> > Andreas Rehn <rehn.andreas86 at gmail.com> 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.
>
I totally agree. Disabling the soft-reset results not in a timeout at 100
MB/s full-duplex
and the download starts immediately. For me, this looks like a wrong usage
of the softreset too.
Maybe this occurs only if the die supports an internal phy?
> > 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.
>
Agree, I just wanted to give you the exact behaviors/measurements.
> > 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.
I didn't run into this after i disabled the soft-reset for 100 MB/s
full-duplex!
And yes, I expect a timeout if the cable is not connected but when you
connect the cable
until the timeout is reached, the link will be established.
> >
>
> > 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.
>
I was also wondering about the linux driver but i didn't see any wrong
behaviors if i disable it on u-boot too.
>
> Applying
>
> net: sun8i-emac: v3s: fix soft reset timeout
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.201471-1-rehn.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:
>
> => 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-xypron.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 = 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?
>
The first one is the kernel, the second one the device-tree download.
just to give you the numbers which are not deterministic for different tftp
download sizes.
> >
> > 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 at 1c30000 Waiting for PHY auto negotiation to
> complete.........
> >> TIMEOUT !
> >> reset MAC done after: 0 us
> >> ethernet at 1c30000 Waiting for PHY auto negotiation to
> complete.........
> >> TIMEOUT !
> >> try2:
> >> reset MAC done after: 0 us
> >> Using ethernet at 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 at arm.com>:
> >>
> >>> On Thu, 20 May 2021 00:10:47 +0200
> >>> Andreas Rehn <rehn.andreas86 at gmail.com> 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 at arm.com>:
> >>>>
> >>>>> On Wed, 19 May 2021 21:42:08 +0200
> >>>>> Andreas Rehn <rehn.andreas86 at gmail.com> 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 <rehn.andreas86 at gmail.com>
> >>>>>> ---
> >>>>>> 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;
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
--
Mit freundlichen Grüßen / kind regards
Andreas Rehn | Master of Engineering (M.Eng)
More information about the U-Boot
mailing list