Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout
44 views
Skip to first unread message
Andre Przywara
Jun 3, 2021, 9:57:19 AM6/3/21
to Andreas Rehn, linux-sunxi, hdeg...@redhat.com, Jagan Teki, ice...@aosc.io, u-b...@lists.denx.de, Heinrich Schuchardt
On Fri, 21 May 2021 22:14:00 +0200
Andreas Rehn <rehn.an...@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.
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.p...@arm.com>:
>
> > On Thu, 20 May 2021 00:10:47 +0200
> > Andreas Rehn <rehn.an...@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.p...@arm.com>:
> > >
> > > > On Wed, 19 May 2021 21:42:08 +0200
> > > > Andreas Rehn <rehn.an...@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.an...@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;
> > > >
> > > >
> > >
> >
> >
>
Andreas Rehn <rehn.an...@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.
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.p...@arm.com>:
>
> > On Thu, 20 May 2021 00:10:47 +0200
> > Andreas Rehn <rehn.an...@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.p...@arm.com>:
> > >
> > > > On Wed, 19 May 2021 21:42:08 +0200
> > > > Andreas Rehn <rehn.an...@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.an...@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;
> > > >
> > > >
> > >
> >
> >
>
Heinrich Schuchardt
Jun 3, 2021, 10:43:30 AM6/3/21
to Andre Przywara, Andreas Rehn, linux-sunxi, hdeg...@redhat.com, Jagan Teki, ice...@aosc.io, u-b...@lists.denx.de, Joe Hershberger, Ramon Fried
net: sun8i-emac: v3s: fix soft reset timeout
https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.2014...@gmail.com/
and
/* Soft reset MAC */
+ 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.96...@gmx.de/
does not do any harm nor does it show any benefit for tFTP transfer on
the OrangePi PC.
Best regards
Heinrich
Reply all
Reply to author
Forward
0 new messages