Extremely slow Ethernet on A20-OLinuXino-LIME2

[att2]

I have the same issue: Internet speed of 15 kilobytes/sec.
I will try to switch to 100mbit as above and see if that fixes anything.
I use the latest Olimex A20 image via torrent as described on the Olimex homepage.

[LubOlimex]

Hey,

We are preparing new builds and official images that would include a workaround based on the uboot patches made by Michael Haas. The new images should improve the behavior of the Gigabit interface. For the moment, try to replace u-boot with this one (there are instructions inside):

Edit 31.03.2016 - added u-boot v2015.10 (the first one used v2015.10-rc1 is still available in the archive):

https://drive.google.com/file/d/0BwplT87k9SCgSmZEcEJWOUNKbzQ/view?usp=sharing

Refer to the README.txt file inside the archive for more information.

Thanks for the dedication of Michael Haas, Karsten Merker, Joe Hershberger, Hans de Goede and everybody I must have missed but got involved.

Best regards,
Lub/OLIMEX

[imrehg]

Hi, just tried out the new u-boot, and works very well for the short amount of time I've checked, thanks!

Been using ArchLinuxARM, where the default u-boot (2016.01) is non-bootable (can see the forum posts), so this was a doubly good replacement.

[LubOlimex]

@imrehg

The problem with the newest u-boots is related to the LDO3/4 values. We are currently investigating it more thoroughly. There is a discussion still going on.

Unless you know what you are doing, I can't really recommend using the newest u-boots or any suggested workarounds for setting LDO3/4 with values suitable for successful boot.

Read more about that here: https://www.mail-archive.com/[email protected]/msg17049.html

Best regards,
Lub/OLIMEX

[mhaas]

@imrehg

Been using ArchLinuxARM, where the default u-boot (2016.01) is non-bootable (can see the forum posts), so this was a doubly good replacement.

I've had the same problem on Debian Jessie. Does your boot simply hang somewhere shortly before login? I could workaround that by blacklisting the axp20x-i2c.ko module (or rather, mv64xxx.ko, but axp20x-i2c.ko should be the real culprit).


@lubolimex

The problem with the newest u-boots is related to the LDO3/4 values. We are currently investigating it more thoroughly. There is a discussion still going on.

I'd love to hear your input on that matter on the mailing list I'll be preparing a patch with Hans' suggested changes (enabling LDO3/LDO4 im u-boot) shortly.

[chradev]

Hi to All,

I have started a new thread (https://www.olimex.com/forum/index.php?topic=5180.0) about A20-OLinuXino-LIME2-eMMC with new HW rev. E.

The main differences in new HW rev D and E are:

• Completely re-routed the Ethernet and the EEPROM in order to reduce noise
• Added eMMC option (can be used instead of NAND). By default everything is set to NAND

As told me from Olimex the slow GB Ethernet problem is solved thanks to SW patch only (probably one from  Igor Pecovnik).

Unfortunately, my observations are that most probably re-routed Ethernet part in new HW rev. D and E is the main reason (see pointed above thread).

Best regarsd
Chris

[mhaas]

Unfortunately, my observations are that most probably re-routed Ethernet part in new HW rev. D and E is the main reason (see pointed above thread).

Best regarsd
Chris

Hi Chris,

So, you disabled the ldo3/ldo4 patch to find out if GBit is still working? In that case, you disabled the wrong patch. You are looking for drivers/net/phy/realtek.c.

@lubolimex
Does the rerouted Ethernet require a different value for the GMAC clock delays?

[chradev]

@mhaas,
I do not disable anything. I simply use Armbian 5.07 "as-is" as a patch set and note that the ldo3/ldo4 patch is present but disabled.
I find that old Lime 2 rev. C is not working with Armbian 5.07 "as-is" while new Lime 2 rev. E is working without any modifications.

Did you have Lime 2 HW rev. E for testing and is there any difference around patches?

@lubolimex
Could you share is there SW changes (and what if any) at migration to new Lime 2 HW rev. E?
What is the SW solution (if any) for old Lime 2 HW rev. C to become usable as GBit Ethernet?
Could you share how to switch from default NAND to eMMC option on Lime 2 HW rev. E as well?

[mhaas]

@chradev,

Sorry for my confusion there

I do not have a rev E and can't really comnment on the effect of the re-routing changes. Please be aware that the GBit ethernet bug only happens sporadically. It depends on the auto-negotiation of the link, i.e. which device becomes master and which device becomes slave.

I tried looking up Armbian 5.07 to check the versions of affected packages, but couldn't find it. Must be my weak google-fu.

[fradav]

Hey,

We are preparing new builds and official images that would include a workaround based on the uboot patches made by Michael Haas. The new images should improve the behavior of the Gigabit interface. For the moment, try to replace u-boot with this one (there are instructions inside):

Edit 31.03.2016 - added u-boot v2015.10 (the first one used v2015.10-rc1 is still available in the archive):

https://drive.google.com/file/d/0BwplT87k9SCgSmZEcEJWOUNKbzQ/view?usp=sharing

Refer to the README.txt file inside the archive for more information.

Thanks for the dedication of Michael Haas, Karsten Merker, Joe Hershberger, Hans de Goede and everybody I must have missed but got involved.

Best regards,
Lub/OLIMEX

It should be noted than your provided uboot, which is completely functionnal and somewhat "solves" the aforementioned  problems (crash during boot and/or gigabit rx slow), isn't optimal : I got < 500Mb/s speed on rx/tx.
To get 900Mb/s speed class you really need latest uboot. Alas, latest uboot git broke something related to the usb phy and sank the uboot in a bootloop (pardon the pun).
So for a complete functional and full speed Gbit uboot, here is the recipe :
the official v2016.03 (tag) from the git.
And the cherry picked following commits :
525d187afb418a4deef8916844f5f7744da402a8
7e4e7e4618c67311fac0d4f8af6bedbbbfe68c9b
53866b6fc54142a2e7ab79d1c2b0f4313c29a2ec
affa020559bca31d6531e19cb1f009c22705a73d
563d8d93585035fa2a0b20190c1008eb625432c4

And you're set.
On a side note, congrats to olimex for designing a board with native and *real* Gbit (an by real I mean 900Mb/s with TCP), it's really astonishing to achieve this for an sbc in this budget class.

Regards,

[JohnS]

Did you let the u-boot maintainer know?

John

[fradav]

Did you let the u-boot maintainer know?

John

They have been aware: in fact, the commiter who caused the bug already patched in master branch (I'm running it on my lime2 right now).

Regards,

[JohnS]

Great news.

John

[chradev]

Hi Guys,

Hey,

We are preparing new builds and official images that would include a workaround based on the uboot patches made by Michael Haas. The new images should improve the behavior of the Gigabit interface. For the moment, try to replace u-boot with this one (there are instructions inside):

Edit 31.03.2016 - added u-boot v2015.10 (the first one used v2015.10-rc1 is still available in the archive):

https://drive.google.com/file/d/0BwplT87k9SCgSmZEcEJWOUNKbzQ/view?usp=sharing

Refer to the README.txt file inside the archive for more information.

Thanks for the dedication of Michael Haas, Karsten Merker, Joe Hershberger, Hans de Goede and everybody I must have missed but got involved.

Best regards,
Lub/OLIMEX

It should be noted than your provided uboot, which is completely functionnal and somewhat "solves" the aforementioned  problems (crash during boot and/or gigabit rx slow), isn't optimal : I got < 500Mb/s speed on rx/tx.
To get 900Mb/s speed class you really need latest uboot. Alas, latest uboot git broke something related to the usb phy and sank the uboot in a bootloop (pardon the pun).
So for a complete functional and full speed Gbit uboot, here is the recipe :
the official v2016.03 (tag) from the git.
And the cherry picked following commits :
525d187afb418a4deef8916844f5f7744da402a8
7e4e7e4618c67311fac0d4f8af6bedbbbfe68c9b
53866b6fc54142a2e7ab79d1c2b0f4313c29a2ec
affa020559bca31d6531e19cb1f009c22705a73d
563d8d93585035fa2a0b20190c1008eb625432c4

And you're set.
On a side note, congrats to olimex for designing a board with native and *real* Gbit (an by real I mean 900Mb/s with TCP), it's really astonishing to achieve this for an sbc in this budget class.

Regards,

As a part of Armbian customization I use U-Boot ver. 2015.10 (because ver. 2016.03 does not boot on Lime2-eMMC boards used by me) and Olimex solution to fix slow GBit Ethernet published in their latest image.

Some time ago I have made a series of tests including Ethernet performance which summary results can be found on: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7762. There I have measured (with iperf) speeds up to 980Mbps over GBit LAN.

These days after finishing some work around eMMC support I try to migrate to newer U-Boot and make some coarse assessment for last versions published here: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry7971.

For my surprise results from first and last measurements are too different without ability to explain why. One reason can be that I have 2 boards A20-Olimexino-Lime2-eMMC (HW ver. E) and tests can be done on the other board. The second board is not in my hand at the moment to check it but according to Olimex' statement provided solution has to work on any board even on old HW rev. C.

Other strange fact is that the fix does not work for U-Boot ver. 2016.01 at all.

Unfortunately, I did not check if all mentioned by fradav staff is applied to U-Boot (most probably not or at leas not as a whole). I use U-Boot as it is integrated into Armbian and the only patches I add are for eMMC support and slow Ethernet fix.

Can somebody confirm that?

Best regards
Chris