Hello,
I have been working on a project using the A20-OLinuXino-Lime2 board. I am upgrading the software by building u-boot (2018-09) and a Linux kernel 4.19, all from sources because I need to integrate some modifications on both parts. The root file system is also built from sources using Buildroot.
All the system was working fine with boards up to the Rev.G2. Suddenly, when new Rev.K boards arrived, I realized that the network is no longer working.
I have modified the kernel to provide support for both the Realtek and Micrel PHYs. When it boots (from an SD card) on a Rev.G2 board, it detects and uses the RTL8211E and the network works properly. When it boots on a Rev.K board, it detects a KSZ9031, but I cannot even "ping" the board from outside. Plugging and unplugging the RJ45 cable triggers the link-up / link-down messages from the kernel on both configurations.
Any idea on what changes to apply to the configuration to make it work? A config file for a kernel ( > 4.1X) or Device Tree modifications would help a lot.
Thank you very much for the support.
Tomeu.
Maybe try the linux-sunxi list unless using Armbian in which case try its forum.
John
Try to extract it from our mainline Armbian-based images:
Desktop: https://www.olimex.com/wiki/File:Armbian_5.52_Olinuxino-a20_Ubuntu_xenial_next_4.17.19_desktop.img.torrent
Server: https://www.olimex.com/wiki/File:Armbian_5.52_Olinuxino-a20_Debian_stretch_next_4.17.19.img.torrent
Hello LubOlimex,
i'm having the same problem as tgarau, however i'm using a non-modified debian stretch.
What can i do to make the micrel phy work with the deiban image? Is a new kernel needed? Or a changed u-boot?
Thank you!
Dieter
Quote from: LubOlimex on October 25, 2018, 11:17:55 PM
Try to extract it from our mainline Armbian-based images:
Desktop: https://www.olimex.com/wiki/File:Armbian_5.52_Olinuxino-a20_Ubuntu_xenial_next_4.17.19_desktop.img.torrent
Server: https://www.olimex.com/wiki/File:Armbian_5.52_Olinuxino-a20_Debian_stretch_next_4.17.19.img.torrent
I successfully tested a downloaded Armbian image, which gave me hope in that at least the hardware can work properly.
I checked in the Armbian repository and it seemed they are pointing to the linux-sunxi repositories. Therefore, I have been digging into sunxi-related kernel and u-boot sources, where I saw in different places different approaches to tune up the TX delay on the GMAC for the sun7i.
I rebuilt the bootloader, setting CONFIG_GMAC_TX_DELAY=4 on a u-boot 2018.09. The result is being tested on three different boards, A20 OLinuXino LIME2 rev.G2, A20 OLinuXino LIME2 rev.K and even on the T2 OLinuXino LIME2 IND rev.K. So far, I can ping the boards, SSH into them and transfer files through scp. I did not test enough to evaluate performance, but so far it seems to be working properly.
Quote from: tgarau on November 05, 2018, 06:08:57 PM
I successfully tested a downloaded Armbian image, which gave me hope in that at least the hardware can work properly.
I checked in the Armbian repository and it seemed they are pointing to the linux-sunxi repositories. Therefore, I have been digging into sunxi-related kernel and u-boot sources, where I saw in different places different approaches to tune up the TX delay on the GMAC for the sun7i.
I rebuilt the bootloader, setting CONFIG_GMAC_TX_DELAY=4 on a u-boot 2018.09. The result is being tested on three different boards, A20 OLinuXino LIME2 rev.G2, A20 OLinuXino LIME2 rev.K and even on the T2 OLinuXino LIME2 IND rev.K. So far, I can ping the boards, SSH into them and transfer files through scp. I did not test enough to evaluate performance, but so far it seems to be working properly.
Dear tgarau, can you confirm that rev.K board (with Micrel/Microchip phy) works with Buildroot?
I have tested the performance of the rev.K board and noticed the performance issue with the uplink:
$ iperf3 -c 192.168.0.110
Connecting to host 192.168.0.110, port 5201
[ 4] local 192.168.0.104 port 45700 connected to 192.168.0.110 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 3.59 MBytes 30.1 Mbits/sec 708 4.24 KBytes
[ 4] 1.00-2.00 sec 4.14 MBytes 34.8 Mbits/sec 964 2.83 KBytes
[ 4] 2.00-3.00 sec 4.19 MBytes 35.1 Mbits/sec 956 2.83 KBytes
[ 4] 3.00-4.00 sec 4.16 MBytes 34.9 Mbits/sec 944 2.83 KBytes
[ 4] 4.00-5.00 sec 4.02 MBytes 33.7 Mbits/sec 925 5.66 KBytes
[ 4] 5.00-6.00 sec 3.03 MBytes 25.4 Mbits/sec 605 2.83 KBytes
[ 4] 6.00-7.00 sec 4.02 MBytes 33.7 Mbits/sec 904 2.83 KBytes
[ 4] 7.00-8.00 sec 3.87 MBytes 32.4 Mbits/sec 859 2.83 KBytes
[ 4] 8.00-9.00 sec 4.08 MBytes 34.2 Mbits/sec 928 2.83 KBytes
[ 4] 9.00-10.00 sec 4.14 MBytes 34.7 Mbits/sec 955 2.83 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 39.2 MBytes 32.9 Mbits/sec 8748 sender
[ 4] 0.00-10.00 sec 39.2 MBytes 32.9 Mbits/sec receiver
while the downlink is good:
$ iperf3 -c 192.168.0.110 -R
Connecting to host 192.168.0.110, port 5201
Reverse mode, remote host 192.168.0.110 is sending
[ 4] local 192.168.0.104 port 45704 connected to 192.168.0.110 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 106 MBytes 890 Mbits/sec
[ 4] 1.00-2.00 sec 109 MBytes 915 Mbits/sec
[ 4] 2.00-3.00 sec 111 MBytes 934 Mbits/sec
[ 4] 3.00-4.00 sec 111 MBytes 935 Mbits/sec
[ 4] 4.00-5.00 sec 111 MBytes 934 Mbits/sec
[ 4] 5.00-6.00 sec 111 MBytes 935 Mbits/sec
[ 4] 6.00-7.00 sec 111 MBytes 934 Mbits/sec
[ 4] 7.00-8.00 sec 111 MBytes 934 Mbits/sec
[ 4] 8.00-9.00 sec 111 MBytes 935 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.08 GBytes 931 Mbits/sec 37 sender
[ 4] 0.00-10.00 sec 1.08 GBytes 928 Mbits/sec
The same behavior is repeatable with the official firmware release #115, with the Armbian Stretch and with Buildroot (fixed u-boot 2018.09, CONFIG_GMAC_TX_DELAY=4). Does anyone have the same issue?
Regards,
Alexey
Solved.
The problem was TP-Link router in between. For some reason it limits the uplink bandwidth.
Worth knowing - thanks for the update - as it is quite likely someone else will wonder about it sooner or later.
John