Bug#911560: A20-OLinuXino-Lime 2 Rev. K Ethernet problem - No connection possible in installer

[Dieter]

Package: debian-installer

Hello maintainer,

i'm currently trying to install debian on a new Olimex A20 Lime 2 Rev. K.

This board uses a new ethernet-PHY, which seems to be unsupported by
current debian images. (I tried stable, as well as the installer daily
build from 2018-10-21).

The hardware-changelog says:
A20-OLinuXino-Lime2_Rev_H
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2. Ethernet PHY changed to commercial variant - KSZ9031RNXCC-TR;

I found bugreport #864562, where it is stated that one could change the
state of GPIO-Pin 17.

That however does not do anything on my board. Ethernet still does not
work.

I'll send syslog / dmesg-output when i get screen to finally save a log.

Thank you and best regards,

Dieter

[Dieter]

Hello,

i have not had a lot of time to look into this today.

However, i found this line in the syslog:
Jan 1 00:00:27 kernel: [ 7.327358] Micrel KSZ9031 Gigabit PHY
stmmac-0:01: attached PHY driver [Micrel KSZ9031 Gigabit PHY]
(mii_bus:phy_addr=stmmac-0:01, irq=POLL)


And the kernel seems to detect the ethernet also:

Jan 1 00:00:27 kernel: [ 7.002010] sun7i-dwmac 1c50000.ethernet: PTP
uses main clock
Jan 1 00:00:27 kernel: [ 7.083443] sun7i-dwmac 1c50000.ethernet: no
reset control found
Jan 1 00:00:27 kernel: [ 7.112287] sun7i-dwmac 1c50000.ethernet: no
regulator found
Jan 1 00:00:27 kernel: [ 7.135027] sun7i-dwmac 1c50000.ethernet:
Version ID not available
Jan 1 00:00:27 kernel: [ 7.147471] sun7i-dwmac 1c50000.ethernet:
DWMAC1000
Jan 1 00:00:27 kernel: [ 7.155074] sun7i-dwmac 1c50000.ethernet: DMA
HW capability register supported
Jan 1 00:00:27 kernel: [ 7.178494] sun7i-dwmac 1c50000.ethernet:
Normal descriptors
Jan 1 00:00:27 kernel: [ 7.184237] sun7i-dwmac 1c50000.ethernet:
Ring mode enabled


And of course, network auto-configuration fails.
It does not work in u-boot either.

Thanks and best regards,
Dieter

[Andreas B. Mundt]

Control: tags -1 patch


Hi all,

I tried to boot a 'Olimex A20 Lime 2 Rev. K' too, and as reported, the
ethernet PHY seems not to be initialized well and fails to work at all.

Following the advice of the sunxi wiki [1], recompiling u-boot with
the proposed patch [2] fixed this: Ethernet works in u-boot as well
as in the installer with the patched u-boot.

No idea if this patch spoils the other revisions.

Best regards,

Andi



[1] https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_u-boot_config

[2]
diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
index 7e48328290..08a7207652 100644
--- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig
+++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
@@ -38,3 +38,4 @@ CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_MUSB_GADGET=y
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_GMAC_TX_DELAY=3

[Jonas Smedegaard]

A workaround for rev. K boards not requiring recompiling code is to
lower transfer speed to 10Mbit/s, e.g. using ethtool or using the
Advertise option in a systemd .link file (see "man systemd.link").

(for Rev. G2 boards it is adequate to lower speed to 100Mbit/s).

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

[Jonas Smedegaard]

Hi Dieter,

Quoting Dieter (2020-08-02 12:29:45)
> I've made some tests with my Rev C A20 OLinuxino Lime 2 board.
> So it uses the RTL8211C Phy.
>
> source used: 2019.01+dfsg-7
>
> The results are somewhat inconclusive i would say.
> The board seems to be able to transfer data with TX_DELAY values up to 3.
> Retry-counts went up when increasing the delay value.
>
> Also attached are tests with a reversed data-flow, as well as test with
> a longer cable.
> Default cable: 1m
> Long cable: 5m.
>
>
> What i did not test: if DHCP would work with TX_DELAY=?, as i used
> static ip addresses
>
>
>
> I did some testing with the RevK board i have at my other place,
> TX_DELAY = 3 was the needed value to get good ethernet speeds with that
> board.
>
> I can do some more testing if needed!

Thanks for the above, and for offering to test more!

I have tried to summarize the kinds of test I imagine relevant, at
https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks

Length of ethernet cable should _not_ be relevant - as long as you stay
within specs of 100 meter:
https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair#Variants

DHCP should be irrelevant to test - that's a higher-level protocol on
top of tcp, and the problems are with packet loss at lower levels.

What _is_ relevant is which mode the PHY ends up being in - master or
slave. This can either be forced or auto-negotiated. Beware that some
releases of u-boot has it forced by default, and to fully test all
combinations you will want to rebuild without that constraint.

[Jonas Smedegaard]

Quoting Dieter (2020-08-08 11:37:39)
> as we found out here
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845128#63),
> FORCE_MASTER was disabled in 2019.01+dfsg-7.
>
> I therefore downloaded u-boot-2020.07+dfsg-1 and did some testing.
> System: debian buster
>
>
> Results are attached.

Thanks! Valuable!


> u-boot without FORCE_MASTER and different TX-Delays:
> No difference can be seen i guess. I would have expected this, as the
> FORCE_MASTER switch should only work for realtek-PHYs, and the REV K
> uses the Micrel PHY.

Right. That's why I omitted above test for rev. H-L boards in my list of
TODOs at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks


> However: I was not able to force the other partner (my old lenovo T500)
> of the connection to a certain mode.
> I thought ethtool would allow me to force the T500s, but i could not
> find the option.

Whoa, setting master/slave mode was implemented only since Linux v5.7:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649

Corresponding userspace support was introduced in ethtool v5.8:
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d

Ethtool v5.8 is not yet in Debian - was released upstream only 4 days
ago.

Sorry, I thought master/slave was same as MDI/MDI-X, but those are
independent: The former is which end provides clock source, then latter
is which wires are used:
https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T

According to
https://www.speedguide.net/articles/network-adapter-optimization-3449
when auto-negotiated "multi-port devices such as switches become the
master when connected to a single port device. If both ends are
multi-port devices, the one with higher seed bits becomes the master."

That seems to indicate that you should reliably put the device in slave
mode by simply plugging it into a gigabit switch. Still not sure how to
force master mode (other than at the other end run Linux 5.7 and compile
and use ethtool 5.8), as the above does not tell which end "wins" when
both are single-port devices.


> u-boot with FORCE_MASTER and TX-Delay 4:
> Same as above.
>
>
> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK

Ohhh, good point - I totally missed that detail!

Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.

Would be helpful if you could test...

* CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
* enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
* above, with various values for TX-Delay


> Good performance with TX-Delay = [3,4].
> The results with TX-Delay = 2 could not be reproduced.
>
>
> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
> With TX-delay = 0, no connection was possible at all.

I would expect TX-delay = 0 to behave same as TX-delay not set at all -
is that your experience as well?


> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does?
> Is this possibly only used in u-boot, and therefore irrelevant as soon
> as linux boots?

those switches enable code chunks in u-boot. My (vague!) understanding
is that some but not all such code chunks does some initialization of
hardware chips, and that Linux may or may not do its own
(re)initialization of same bits.

In other words: Possibly - it depends... :-)


> As you mentioned this commit
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
> earlier in this thread, i would guess we should re-tests this with a
> linux-image > 5.2?

Ideally we should test network quality from within u-boot, and if we
identify some u-boot setup that fails from within u-boot but works from
some Linux, then try identify what initialization the Linux code does
and try figure out how that could be done in u-boot as well.

...because ideally we want u-boot to work reliably not only for
initializing what Linux misses, but also for netbooting Linux.


Another test that would be helpful is if you test your board with u-boot
built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do not have
and/or use eMMC): My suspicion is that the added options enabled for
that defconfig is harmless for non-eMMC boards, and knowing if in fact
they are harmless is helpful to figure out how many binaries we really
need to build in Debian, and if e.g. possible to say "use the -eMMC one
for Micrel-based boards regardless of eMMC".

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-08-08 14:48:45)

> Quoting Dieter (2020-08-08 11:37:39)

> > However: I was not able to force the other partner (my old lenovo
> > T500) of the connection to a certain mode.
> > I thought ethtool would allow me to force the T500s, but i could not
> > find the option.
>
> Whoa, setting master/slave mode was implemented only since Linux v5.7:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
>
> Corresponding userspace support was introduced in ethtool v5.8:
> https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
>
> Ethtool v5.8 is not yet in Debian - was released upstream only 4 days
> ago.

Request to upgrade of ethtool in debian: https://bugs.debian.org/968099

[Dieter]

Hi Jonas,

Thanks for the information.
Since ethtool 5.8 is now available, i can install debian unstable on the
laptop and test different combinations.

>> u-boot with FORCE_MASTER and TX-Delay 4:
>> Same as above.
>>
>>
>> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
>
> Ohhh, good point - I totally missed that detail!
>
> Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.
>
> Would be helpful if you could test...
>
> * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
> * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
> * above, with various values for TX-Delay

Yes, i can test that!

>> Good performance with TX-Delay = [3,4].
>> The results with TX-Delay = 2 could not be reproduced.
>>
>>
>> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
>> With TX-delay = 0, no connection was possible at all.
>
> I would expect TX-delay = 0 to behave same as TX-delay not set at all -
> is that your experience as well?

To be honest, i did not disable the configuration, as i always started
from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by default.

But i just checked, if the line with GMAC_TX_DELAY is commented out in
the config, make will ask for a value, 0 being the default.
-> Yes, TX-Delay 0 is equal to this config not being set at all.

>> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does?
>> Is this possibly only used in u-boot, and therefore irrelevant as soon
>> as linux boots?
>
> those switches enable code chunks in u-boot. My (vague!) understanding
> is that some but not all such code chunks does some initialization of
> hardware chips, and that Linux may or may not do its own
> (re)initialization of same bits.
>
> In other words: Possibly - it depends... :-)

I see, in that case i would suppose that network functionality in u-boot
might depend on the compiled in drivers.
Likely independent of network functionality when the OS is brought up.
I arrived at this conclusion, as u-boot without the MICREL Phy has
working ethernet in Linux with the TX-Delay being set.

>> As you mentioned this commit
>> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
>> earlier in this thread, i would guess we should re-tests this with a
>> linux-image > 5.2?
>
> Ideally we should test network quality from within u-boot, and if we
> identify some u-boot setup that fails from within u-boot but works from
> some Linux, then try identify what initialization the Linux code does
> and try figure out how that could be done in u-boot as well.
>
> ...because ideally we want u-boot to work reliably not only for
> initializing what Linux misses, but also for netbooting Linux.

I agree, i would propose to test the values for TX_DELAY from within
Linux, as there measuring upload / download performance is easier.
As soon as we find a good configuration there, we can test the
netbooting from u-boot.

-> Configuring a tftp-server on the laptop to serve the netboot images
to the OLinuXino should help here.

> Another test that would be helpful is if you test your board with u-boot
> built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do not have
> and/or use eMMC): My suspicion is that the added options enabled for
> that defconfig is harmless for non-eMMC boards, and knowing if in fact
> they are harmless is helpful to figure out how many binaries we really
> need to build in Debian, and if e.g. possible to say "use the -eMMC one
> for Micrel-based boards regardless of eMMC".
>
>
> - Jonas
>

You were right, the -eMMC boots find, one just needs to:
- either symlink the non-eMMC.dtb to the *-eMMC.dtb in /boot/dtbs...
- install the real -eMMC.dtb to /boot/dtbs...

Booting the device works fine in both cases, and i did not encounter any
error as of yet.
I wonder if flash-kernel will take care of updated the dtb in /boot upon
a kernel update.



Best regards,
Dieter

[Jonas Smedegaard]

Quoting Dieter (2020-08-14 09:03:22)

Yes - I was excited too seeing that package update appear today

I filed a bugreport requesting an update which possibly helped speed
this up, but maybe it would have been done by now regardless.

> >> u-boot with FORCE_MASTER and TX-Delay 4:
> >> Same as above.
> >>
> >>
> >> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
> >
> > Ohhh, good point - I totally missed that detail!
> >
> > Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.
> >
> > Would be helpful if you could test...
> >
> > * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
> > * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
> > * above, with various values for TX-Delay
>
> Yes, i can test that!

Thanks!

To be honest, I could test this myself as well - I do have those boards
lying around, but some of them are in active use, and I keep finding
other things more important/exciting, so really appreciate your help
here!

Another benefit of this being done between the two of us is that we get
the details more carefully laid out and documented. At least for me it
has been an eye-opener in just how complex a seemingly simple "LIME2 is
flaky at high speeds" turns out to be, if we wanna do better than "then
just avoid those flaky modes".

> >> Good performance with TX-Delay = [3,4].
> >> The results with TX-Delay = 2 could not be reproduced.
> >>
> >>
> >> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
> >> With TX-delay = 0, no connection was possible at all.
> >
> > I would expect TX-delay = 0 to behave same as TX-delay not set at
> > all - is that your experience as well?
>
> To be honest, i did not disable the configuration, as i always started
> from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by
> default.
>
> But i just checked, if the line with GMAC_TX_DELAY is commented out in
> the config, make will ask for a value, 0 being the default.
> -> Yes, TX-Delay 0 is equal to this config not being set at all.

Thanks for confirming!

> >> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK
> >> does?
> >> Is this possibly only used in u-boot, and therefore irrelevant as
> >> soon as linux boots?
> >
> > those switches enable code chunks in u-boot. My (vague!)
> > understanding is that some but not all such code chunks does some
> > initialization of hardware chips, and that Linux may or may not do
> > its own (re)initialization of same bits.
> >
> > In other words: Possibly - it depends... :-)
>
> I see, in that case i would suppose that network functionality in
> u-boot might depend on the compiled in drivers.

Yeah - except it is not really "drivers" in u-boot.

> Likely independent of network functionality when the OS is brought up.

Cold-booting u-boot is certainly independent of Linux.

But Warm-booting u-boot after rebooting from a loaded Linux is *not*
independent of Linux.

Neither is Linux loaded from u-boot independent of u-boot.

> I arrived at this conclusion, as u-boot without the MICREL Phy has
> working ethernet in Linux with the TX-Delay being set.

Imagine Micrel PHY needs pins X and Y enabled to work well, and u-boot
sets X and flips Y, and Linux flips X and sets Y.

Cold-booting u-boot would fail, but then loading Linux would work.

Rebooting into u-boot from working linux would fail.

Rebooting into u-boot from failing u-boot would work.

Cold-booting u-boot, rebooting u-boot, then loading Linux would fail.

If however neither u-boot nor linux flips anything, only sets flags
without probing first, then... (but they _need_ to probe _something_
e.g. to decide that the board has a Micrel chip at all, and we are in
this mess because some of the probing and/or settings are undocumented).

In short: Possibly - It depends... :-)

> >> As you mentioned this commit
> >> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
> >> earlier in this thread, i would guess we should re-tests this with
> >> a linux-image > 5.2?
> >
> > Ideally we should test network quality from within u-boot, and if we
> > identify some u-boot setup that fails from within u-boot but works
> > from some Linux, then try identify what initialization the Linux
> > code does and try figure out how that could be done in u-boot as
> > well.
> >
> > ...because ideally we want u-boot to work reliably not only for
> > initializing what Linux misses, but also for netbooting Linux.
>
> I agree, i would propose to test the values for TX_DELAY from within
> Linux, as there measuring upload / download performance is easier.
> As soon as we find a good configuration there, we can test the
> netbooting from u-boot.

Makes some sense, especially if you hope to "cut through" to a working
setting without sifting through all possible combinations of options.

On the other hand, if the combinations to test is large it is more
tedious to load both u-boot and linux.

> -> Configuring a tftp-server on the laptop to serve the netboot images
> to the OLinuXino should help here.

Yes.

Simplest least reliable u-boot test seems to be to ping something.

Possibly slightly better might be to issue dhcp requests repeatedly, as
I imagine that would send larger packets.

Most reliable (using only generally available u-boot commands) seems to
be fetching something over tftp and then sending it back over tftp
again, as that should measure actual transfer speed in either direction.

> > Another test that would be helpful is if you test your board with
> > u-boot built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do
> > not have and/or use eMMC): My suspicion is that the added options
> > enabled for that defconfig is harmless for non-eMMC boards, and
> > knowing if in fact they are harmless is helpful to figure out how
> > many binaries we really need to build in Debian, and if e.g.
> > possible to say "use the -eMMC one for Micrel-based boards
> > regardless of eMMC".
> >
> >
> > - Jonas
> >
>
> You were right, the -eMMC boots find, one just needs to:
> - either symlink the non-eMMC.dtb to the *-eMMC.dtb in /boot/dtbs...
> - install the real -eMMC.dtb to /boot/dtbs...

This trick should work:

sudo FK_MACHINE='Olimex A20-OLinuXino-LIME2-eMMC' flash-kernel

...and then reboot (and cross your fingers and knock on wood)

> Booting the device works fine in both cases, and i did not encounter
> any error as of yet.

Thanks for confirming.

I have thought some more on this, and adjusted my logic: In the past I
thought "use the -eMMC if your board has eMMC soldered on" but now
realize that the better way to look at it is this:

Use the -eMMC dtb for modern boards that *optionally* can hold an eMMC -
i.e. the optimal dtb to use is the -eMMC one for rev. F and newer -
regardless if your specific board has eMMC soldered on and regardless if
you intend on using eMMC - the "eMMC" in the dtb name is simply a
distinguishing trait of the board design.

By that new (to me) logic, it makes sense to include the force-master
workaround only for the non-eMMC dtb: It is irrelevant for any of the
two PHYs used in more modern boards. Until now I was considering that
to be an oversight.

> I wonder if flash-kernel will take care of updated the dtb in /boot
> upon a kernel update.

flash-kernel will by default use the device-tree of the running kernel
(but the "by default" might no longer apply, depending on how exactly
you mess with symlinks or configfile contents).

So I recommend trying above trick.

[Nicolas Dufresne]

As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.

- 2, 3, and 4 was good enough to succeed a DHCP handshake.

- 0 and 1 made the request to never be seen over the network.

An obvious next step would be to test again with large file transfer,
perhaps a kernel image. I will report back.

regards,
Nicolas

[Nicolas Dufresne]

Follow up:

I've tested download rate with a 125MB file over tftp. Even though tftp
code (or tftp itself?) is inefficient I could repeat the following:

Delay | 2 | 3 | 4 | 5 |
-------------------------------
Mb/s | 2.0 | 2.1 | 2.7 | 2.1 |
Timeouts| 5 | 4 | 1 | 4 |

The timeouts are the number of time u-boot pinted a T during the
transfer. I've also attempted some test form Linux side, and notice
some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with
the same file with scp.

I've then set the RX delay too, to 4, and could notice a very minimal
improvement, 8.5 MB/s upload. Now the issue is that these are all
terrible results for a gigabit ethernet. There must be other issues
around. But a delay of 4 at least makes it usable (at around 100Mb/s).

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)

> I've then set the RX delay too, to 4, and could notice a very minimal
> improvement, 8.5 MB/s upload. Now the issue is that these are all
> terrible results for a gigabit ethernet. There must be other issues
> around. But a delay of 4 at least makes it usable (at around 100Mb/s).

Did you try setting RX delay to _other_ values?

Seems from adjustments of other hardware that don't need not be equal.

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)

Thanks a lot for these tests. Really helpful!

There _are_ other limiting factors than ethernet speed involved - I do
not know what maximum to expect on this kind of board, however.

[Jonas Smedegaard]

Control: retitle -1 A20-OLinuXino-Lime2-eMMC Rev. K: very poor ethernet performance

Quoting Jonas Smedegaard (2020-08-08 15:46:15)

> Quoting Jonas Smedegaard (2020-08-08 14:48:45)
> > Quoting Dieter (2020-08-08 11:37:39)
> > > However: I was not able to force the other partner (my old lenovo
> > > T500) of the connection to a certain mode. I thought ethtool would
> > > allow me to force the T500s, but i could not find the option.
> >
> > Whoa, setting master/slave mode was implemented only since Linux
> > v5.7:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
> >
> > Corresponding userspace support was introduced in ethtool v5.8:
> > https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
> >
> > Ethtool v5.8 is not yet in Debian - was released upstream only 4
> > days ago.
>
> Request to upgrade of ethtool in debian:
> https://bugs.debian.org/968099

ethtool 5.8 is in Debian testing since late August.

With that version, simply running "ethtool eth0" shows if the card is
currently running in master or slave mode - which is helpful to mention
when doing calibration tests, as that possibly matters and it can change
each time connection is negotiated.


Changing title of this bugreport to disambiguate from bug#916822.

[Andreas B. Mundt]

Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no ethernet performance


Hi all,

the last days, I tried upgrading two A20-OLinuXino-Lime2 boards to bullseye.
After booting the bullseye kernel, 5.10.46-4 (2021-08-03), the network did
not work anymore: The interface shows up (IIRC, even a link is detected),
but any attempts to connect (DHCP) fail.

After playing with different delays following [1], I succeeded with
CONFIG_GMAC_TX_DELAY=4, where both boards seem to work fine. I also played a
bit with iperf3: At higher bitrates (> approx. 200Mbits/s) more and more
retries seem to be needed. So the issue this bug is about seems to affect
also the G2 revision boards that worked fine so far.

Best regards,

Andi


[1] https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K.3B_rev._G2_and_bullseye_kernel

[Jonas Smedegaard]

Control: retitle -1 A20-OLinuXino-Lime2-eMMC Rev. K: very poor ethernet performance

Hi Andreas,

Quoting Andreas B. Mundt (2021-08-26 20:01:16)

> Control: retitle -1 A20-OLinuXino-Lime2-(eMMC): Rev. K, G2: very poor/no ethernet performance

Please re-post your info about rev.G board to bug#927397 - thanks!

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2022-06-09 12:23:53)
> Version: 2022.04+dfsg-1
>
> This bug was fixed since u-boot 2022.04 - specifically in git commit
> f11513d9: https://source.denx.de/u-boot/u-boot/-/commit/f11513d

Correction - the actual fix was the later git commit 85da5587:
https://source.denx.de/u-boot/u-boot/-/commit/85da558