- Package:
- u-boot-sunxi
- Source:
- u-boot
- Submitter:
- Bastien Rocheron
- Date:
- 2021-08-26 18:27:05 UTC
- Severity:
- normal
- Tags:
Dear Maintainer,
* What led up to the situation?
I have plugged my Olimex Lime2 Rev C in a gigabit ethernet port.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I tried to access it through the network.
* What was the outcome of this action?
Ping was barely responding, ssh was not always possible (time out) and
the download speed of the system was not able to go above 15kbs.
* What outcome did you expect instead?
I was expecting normal gigabit ethernet performances.
This model is known to have an issue with the gigabit ethernet. When
used in gigabit mode, the performances are terrible, you can barely
connect via SSH...
A workaround is to connect to a 100 mbs port or manually set the speed
of eth to 100 mbs.
In order to solve it I followed the steps found on the Olimex Github
(https://github.com/OLIMEX/OLINUXINO/issues/31) to patch u-boot.
Specifically I applied the patch found here:
https://drive.google.com/file/d/0BwplT87k9SCgSmZEcEJWOUNKbzQ/view?usp=sharing,
named mainline u-boot 2015.10-rc1.
Control: reassign 845128 u-boot-sunxi ... Could you please retry with u-boot 2016.09+dfsg1-2 in testing, and 2016.11+dfsg1-1 in unstable? There were some issues with ethernet on older versions that I thought were resolved in recent versions. live well, vagrant
Control: tags 845128 moreinfo Control: found 845128 u-boot-sunxi/2016.03+dfsg1-6
I'm not sure how to do that, sorry :/ I found u-boot pre-installed on the image I have booted (freedombox). And then I replaced it with a patched version by overwriting the blocks on the SD-card with a pre-compiled u-boot. If you have a precise procedure to follow I can try. cheers, bastien
The following steps on the Lime2 should provide you with a current u-boot version from unstable: $ wget https://d-i.debian.org/daily-images/armhf/daily/u-boot/A20-OLinuXino-Lime2/u-boot-sunxi-with-spl.bin.gz $ gunzip u-boot-sunxi-with-spl.bin.gz $ sudo dd if=u-boot-sunxi-with-spl.bin bs=1k seek=8 of=/dev/mmcblk0 HTH, Karsten
The issue seems to continue on recent versions of u-boot. However, this problem does not seem to be present in Rev.G2 of the board (which has problem with transmit performance as reported in #927397). I have recently noticed that the receive performance on my Rev.C board is very poor and that I was using old version of u-boot (U-Boot SPL 2016.03+dfsg1-4). So, I updated to u-boot 2019.01+dfsg-4 available in unstable. The problem could still be reproduced. Here are the results of my tests: root@freedombox:~# iperf3 -c 10.42.1.1 -R Connecting to host 10.42.1.1, port 5201 Reverse mode, remote host 10.42.1.1 is sending [ 5] local 10.42.1.139 port 48228 connected to 10.42.1.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 281 KBytes 2.30 Mbits/sec [ 5] 1.00-2.00 sec 60.8 KBytes 498 Kbits/sec [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 3.00-4.00 sec 158 KBytes 1.30 Mbits/sec [ 5] 4.00-5.00 sec 235 KBytes 1.92 Mbits/sec [ 5] 5.00-6.00 sec 110 KBytes 903 Kbits/sec [ 5] 6.00-7.00 sec 228 KBytes 1.86 Mbits/sec [ 5] 7.00-8.00 sec 109 KBytes 892 Kbits/sec [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 9.00-10.00 sec 112 KBytes 916 Kbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 1.38 MBytes 1.15 Mbits/sec 188 sender [ 5] 0.00-10.00 sec 1.26 MBytes 1.06 Mbits/sec receiver iperf Done. root@freedombox:~# iperf3 -c 10.42.1.1 Connecting to host 10.42.1.1, port 5201 [ 5] local 10.42.1.139 port 48232 connected to 10.42.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.01 sec 65.8 MBytes 545 Mbits/sec 0 468 KBytes [ 5] 1.01-2.01 sec 67.5 MBytes 567 Mbits/sec 0 468 KBytes [ 5] 2.01-3.01 sec 66.5 MBytes 556 Mbits/sec 0 673 KBytes [ 5] 3.01-4.00 sec 67.2 MBytes 570 Mbits/sec 0 841 KBytes [ 5] 4.00-5.01 sec 53.8 MBytes 450 Mbits/sec 0 841 KBytes [ 5] 5.01-6.01 sec 65.0 MBytes 545 Mbits/sec 0 841 KBytes [ 5] 6.01-7.02 sec 46.2 MBytes 384 Mbits/sec 0 841 KBytes [ 5] 7.02-8.02 sec 66.2 MBytes 556 Mbits/sec 0 884 KBytes [ 5] 8.02-9.00 sec 68.6 MBytes 583 Mbits/sec 0 884 KBytes [ 5] 9.00-10.01 sec 63.1 MBytes 525 Mbits/sec 0 1.09 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 630 MBytes 528 Mbits/sec 0 sender [ 5] 0.00-10.05 sec 630 MBytes 526 Mbits/sec receiver iperf Done. root@freedombox:~# mii-tool eth0 -A 100BaseTx-FD restarting autonegotiation... root@freedombox:~# iperf3 -c 10.42.1.1 Connecting to host 10.42.1.1, port 5201 [ 5] local 10.42.1.139 port 48236 connected to 10.42.1.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 11.5 MBytes 96.0 Mbits/sec 0 119 KBytes [ 5] 1.00-2.00 sec 11.2 MBytes 94.4 Mbits/sec 0 124 KBytes [ 5] 2.00-3.00 sec 11.1 MBytes 92.7 Mbits/sec 0 139 KBytes [ 5] 3.00-4.00 sec 11.2 MBytes 94.3 Mbits/sec 0 139 KBytes [ 5] 4.00-5.00 sec 11.2 MBytes 94.4 Mbits/sec 0 139 KBytes [ 5] 5.00-6.00 sec 11.2 MBytes 93.9 Mbits/sec 0 139 KBytes [ 5] 6.00-7.00 sec 11.3 MBytes 94.9 Mbits/sec 0 139 KBytes [ 5] 7.00-8.00 sec 11.2 MBytes 93.8 Mbits/sec 0 139 KBytes [ 5] 8.00-9.00 sec 11.2 MBytes 93.8 Mbits/sec 0 139 KBytes [ 5] 9.00-10.00 sec 11.2 MBytes 93.8 Mbits/sec 0 139 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec 0 sender [ 5] 0.00-10.04 sec 112 MBytes 93.6 Mbits/sec receiver iperf Done. root@freedombox:~# iperf3 -c 10.42.1.1 -R Connecting to host 10.42.1.1, port 5201 Reverse mode, remote host 10.42.1.1 is sending [ 5] local 10.42.1.139 port 48240 connected to 10.42.1.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 11.2 MBytes 94.3 Mbits/sec [ 5] 1.00-2.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 2.00-3.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 3.00-4.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 4.00-5.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 5.00-6.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 6.00-7.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 7.00-8.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 8.00-9.00 sec 11.2 MBytes 93.7 Mbits/sec [ 5] 9.00-10.00 sec 11.2 MBytes 93.7 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 113 MBytes 94.6 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 112 MBytes 93.7 Mbits/sec receiver iperf Done.
I noticed that a "force master" workaround[1] was introduced into u-boot in 2016 after some discussion[2] for fixing poor Ethernet performance on RTL8211C found in Lime2 Rev.C. Later, perhaps inadvertently, this seems to be removed[3]. Links: 1) https://lists.denx.de/pipermail/u-boot/2016-March/249629.html 2) https://lists.denx.de/pipermail/u-boot/2016-March/248498.html 3) https://git.denx.de/?p=u-boot.git;a=blobdiff;f=configs/A20-OLinuXino-Lime2_defconfig;h=a4ade72d4a3a8029d6417e7658655d5e91aaa20f;hp=0d38f65c50e91493f6eb9c483fc816a18469e9c9;hb=8728c97eff5bd95f58320f886ae305f17931a374;hpb=c9592e3c5c97981787c0d82f768a6971deb4837d
Sunil Mohan wrote: Your link [3] apparently no longer works¹ - a currently working link to the commit where LIME2 rev.C workaround got dropped is this: https://gitlab.denx.de/u-boot/u-boot/-/commit/8728c97eff5bd95f58320f886ae305f17931a374#df39e52b3ea1557b1fb508755955c9ad86f92c38 That change happened prior to release v2017.03 and was reverted prior to release v2020.04: https://gitlab.denx.de/u-boot/u-boot/-/commit/8728c97eff5bd95f58320f886ae305f17931a374#df39e52b3ea1557b1fb508755955c9ad86f92c38 - Jonas ¹ Seems the reason is that U-boot switched to use Gitlab, without adding redirections.
Hello all! As i did some testing with my RevK and RevC and various values for GMAC_TX_DELAY, I logged into the RevC Lime2 today to check if CONFIG_RTL8211X_PHY_FORCE_MASTER=y was set in the u-boot config. As i did not change this setting from the debian-default, i figured i would only have to test the "other" value. However, i can not find it in the .config in the u-boot-src. Which seems fine, as the config can not be found in upstream u-boot: https://gitlab.denx.de/u-boot/u-boot/-/blob/v2019.01/configs/A20-OLinuXino-Lime2_defconfig But this configuration then re-appeared in release 2020.07: https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.07/configs/A20-OLinuXino-Lime2_defconfig Now i do not know how to check if FORCE_MASTER was set or not. see the results for RevC with u-boot-sunxi (2019.01+dfsg-7) here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911560#126 Best regards, Dieter
Quoting Jonas Smedegaard (2020-08-07 11:45:32) See https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks for the proper URLs, and more related information and tests that seems relevant to conduct. - Jonas
Quoting Dieter (2020-08-07 13:09:42) It seems that FORCE_MASTER was disabled in 2019.01+dfsg-7. Few minutes ago I updated https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks with my newest findings from upstream u-boot. I also looked at Debian packaging where I did not locate any patches related to this issue, so it seems Debian packaging is aligned with upstream on this. - Jonas
Control: retitle -1 u-boot: Olimex Lime2 Rev C Gigabit Ethernet severe packet loss Control: clone -1 -2 Control: retitle -2 u-boot: Olimex Lime2 Rev C Gigabit Ethernet no slave mode Control: fixed -1 2016.05~rc3+dfsg1-1 Control: found -2 2016.05~rc3+dfsg1-1 Control: found -1 2017.05~rc1+dfsg1-1 Control: fixed -2 2017.05~rc1+dfsg1-1 Control: fixed -1 2020.07~rc2+dfsg-1 Control: found -2 2020.07~rc2+dfsg-1 Quoting Jonas Smedegaard (2020-08-07 11:45:32) https://gitlab.denx.de/u-boot/u-boot/-/commit/525d187 and https://gitlab.denx.de/u-boot/u-boot/-/commit/53866b6 Above commit was applied ater release v2017.03-rc3. yet another correction: workaround of forcing master mode in gigabit for rev. A-E boards was re-introduced _later_ release v2020.04. ...and here is the correct URL, for the record: https://gitlab.denx.de/u-boot/u-boot/-/commit/b897306 Limiting this issue to be severe packet loss, and consider it solved where u-boot has applied the workaround of forcing master mode. Beare that the workaround has a known side-effect of causing a related but different issue: Rev. A-E boards now completely fail to work in gigabit when the remote end cannot operate in slave mode - e.g. with two LIME2 boxes directly connected without a switch in-between. Please discuss that related issue in newly cloned separate bugreport. - Jonas
For some time now, u-boot forces this board into master mode, based on an assumption that the PHY chip simply cannot work in slave mode. Later, some drivers and boards has had success in tuning RX/TX internal delays either in MAC or in PHY. If someone wants to try test if perhaps the Lime2 Rev C board _can_ work in slave mode, if differently calibrated, then here's how to get started: * Build u-boot _without_ option RTL8211X_PHY_FORCE_MASTER=y * Install ethtool 5.8 or newer to probe or set master/slave mode To try calibrate delays at MAC: * Build u-boot with option CONFIG_GMAC_TX_DELAY=N at various values To try calibrate delays at PHY: * compile device-tree file with option phy-mode = "rgmii-id" * try set RX/TX values using ethtool 5.8 or newer * alternatively set RX/TX values in device-tree More information about this at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks - Jonas