On 6/3/21 3:56 PM, Andre Przywara wrote:
On Fri, 21 May 2021 22:14:00 +0200
Andreas Rehn <rehn.andrea...@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.
Applying
net: sun8i-emac: v3s: fix soft reset timeout
https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.201471-1-rehn.andrea...@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.g...@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?
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.przyw...@arm.com>:
On Thu, 20 May 2021 00:10:47 +0200
Andreas Rehn <rehn.andrea...@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.przyw...@arm.com>:
On Wed, 19 May 2021 21:42:08 +0200
Andreas Rehn <rehn.andrea...@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.andrea...@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;
